So you talk to a database, doing transactions. What happens actually, behind the scenes? Let’s have a look. There is a test table, and we write data into it inside a transaction: CREATE TABLE t ( id serial, data varbinary(255) ) START TRANSACTION READ WRITE INSERT INTO t ( id, data ) VALUES (NULL, RANDOM_BYTES(255)) COMMIT The MySQL test instance we are talking to is running on a Linux machine, an
Epoch-based {Logging, Checkpointing, Index} - nikezono
#長編 皆さん，初めまして．NTT SICの中園 (nikezono) です． この記事は 自作DBMS Advent Calender 2020 の 18 日目の記事です． この記事では，前日にご紹介したLineairDBを実装するうえで用いたインメモリDBの最適化手法について解説します． ３つの最適化があり，それぞれ{Logging, Checkpointing, Index}についての話になります．3日に分けようかと一瞬思いましたが，どれも小粒なのでまとめました． 未執筆のリンク先 が多く含まれる記事になるかと思いますが，随時書いていきます． 記事の構成 1. インメモリDBの性能上の問題 1. a Logging 1. b Checkpointing 1. c Index 2. 銀の弾丸? Epoch Framework 3. Epoch Frameworkを使った最適化手法3種
2020/03/25 MySQL Casual Talks Online(beta) Vol.1 https://mysql-casual.connpass.com/event/171277/
Dockerを使ってPHP+MySQLの試験環境を作るために、どうしようもなく転びまくった記録です。 ほかの時期だったり、使えるもののバージョンが変われば、また違った展開になると思います。 2020年5月時点で利用可能なDockerの最新版を使うべくアノ手コノ手でインストールに至るまでの一例です。 最終的にどうなったか AWSのEC2にあるFaro Sourceというところが提供するOptimized AWS CentOS 7.6.2 (X86, 64bit)を使いました。 このインスタンスはインスタンス料金とは別にソフトウェアライセンス料金がかかるようですのでご注意くださいまし。 本当にタマタマこの組み合わせでうまくいっただけで、それ以上何も感想はないです。 いろいろ使ったもの 開発端末OS Windows10 Pro 64bit Docker for Windows 2.2.0.5 V
Google SpannerとMySQLのトランザクションの違い - GMOインターネットグループ グループ研究開発本部
こんにちは，S.T.です。今回はGoogle Spannerを検証します。Spannerは関係データベースのデータ構造を持ちトランザクション処理に対応した分散データベースです。リアルタイムにトランザクション処理を行うようなアプリケーションのデータストアとしての利用も考慮されています。また，PostgreSQLのインタフェースの実装も進められており，アプリケーションから一般的なRDBと同様に使えるようになる日も近そうです。 そこで，今回はSpannerのトランザクションの挙動をMySQLのInnoDBと比較し，挙動の違いによる落とし穴がないかどうかを確かめます。具体的には，トランザクション分離レベルやロックの範囲について検証します。結論から言うと，何も考えずに単にRDB置き換えるだけでは大怪我をしそうだが，特性を理解していればそう大差ない実装でいけると言えそうです。また，Spannerの肝で
OSSデータベース取り取り時報 第51回「企業ITシステムのモダナイゼーションとデータベース最新状況」報告、MySQL 8.0.18リリース、PostgreSQL 12リリース この連載では、OSSコンソーシアム データベース部会のメンバーが、さまざまなオープンソースデータベースの毎月の出来事をお伝えしています。今回、OSC.Enterpriseでの特別セミナーの報告をします。また、MySQL 8.0.18がリリースされ、PostgreSQLはメジャーバージョン12が正式にリリースしました。 OSC 2019 .Enterpriseでの特別セミナーの報告（発表資料公開あり） 前回お知らせのとおり、私たちOSSコンソーシアムは、10月10日（木）に東京の渋谷で開催されたオープンソースカンファレンス（OSC）2019.Enterpriseに出展しました。今回は、オープンCOBOLソリューション
AWS re:Invent 2022 で発表の Torn Write Prevention と Optimized Write とは - サーバーワークスエンジニアブログ
カスタマーサクセス部 佐竹です。 本ブログでは、AWS re:Invent 2022 で発表されたアップデートである「Torn Write Prevention」と RDS における「Optimized Write」について記載します。 はじめに AWS Announces Torn Write Prevention for EC2 I4i instances, EBS, and Amazon RDS Amazon RDS Optimized Writes enables up to 2x higher write throughput at no additional cost New – Amazon RDS Optimized Reads and Optimized Writes Doublewrite Buffer Doublewrite Buffer の問題 Torn Write
コスト削減のため Redis の sorted sets で実装していたランキング処理を MySQL に移行しました - Mobile Factory Tech Blog
駅メモ！チームエンジニアの id:yumlonne です。 この記事では Redis の sorted sets で実装していたランキング処理を MySQL に移行した仕組みを紹介します。 背景 駅メモ！には複数のランキングがあり、Redis の sorted sets を使うことでパフォーマンスの高いランキング処理を実現していました。 中にはリリースからの全期間に渡るデータを利用するランキングもあり、Redis のメモリ使用率は日に日に増えていく一方でした。 何度か Redis をスケールアップしてメモリを増やすことで対応していましたが、根本的に対応しなければ今後も Redis をスケールアップもしくはスケールアウトさせ続けるしか選択肢がなく、コストが増え続けてしまう状況でした。 調査したところ、一部のランキングがメモリ使用率の 2/3 程度を占めていることが判明しました。 そこで、その
あけましておめでとうございます。この連載はOSSコンソーシアム データベース部会のメンバーがオープンソースデータベースの毎月の出来事をお伝えしています。2023年もOSSデータベース取り取り時報をよろしくお願いいたします。 ［MySQL］2022年12月の主な出来事 2022年11月のMySQLの製品リリースはありませんでした。 クラウド版のMySQLであるMySQL HeatWave Database Serviceでは、レプリケーション機能の強化が行われ、お客様のご要望の多かったリードレプリカが追加されました。参照処理の負荷分散用のMySQLサーバーを18台まで追加でき、ロードバランサーとして機能するエンドポイントを利用可能となっています。 またAmazon RDSなどMySQLサーバーと完全互換ではないクラウド・データベースからのレプリケーションの際は、これまでは中間サーバーにて非互
SQL文はLocal by FlywheelのAdminerから慣れよう（WordPressのDB操作：その1） - クモのようにコツコツと
DB、すなわちデータベース*1。普段あまり触れることがないDB。黒い画面（ターミナル）でコマンド打ってゴニョゴニョ操作するイメージのDB。おそらく一番身近な入り口である「Local by Flywheel」の「Adminer」から、WordPressのDBをSQL文でコチョコチョ操作したい！ ※目次： WordPressとMySQL WordPressのローカル環境「Local by Flywheel」 DBにアクセスするAdminer WordPressのDBのダンプ（sql）ファイル SQL文の三種類（DDL、DML、DCL） まとめと次回予告 WordPressとMySQL 「サーバサイドの中でのWordPressの位置付け」でも解説しましたがサーバサイドにはプログラミング言語とデータベース言語があります。 ※参考：サーバサイドの中でのWordPressの位置付け - クモのようにコ
Aurora Serverless v2: The Good, the Better, and the Possibly Amazing - Jeremy Daly
Aurora Serverless v2: The Good, the Better, and the Possibly Amazing Aurora Serverless v2 Preview is here, and it looks very promising. I share my initial thoughts and results of some experiments I ran on this major upgrade. Three years ago at re:Invent 2017, AWS announced the original Amazon Aurora Serverless preview. I spent quite a bit of time with it, and when it went GA 9 months later, I publ
Improve query performance using Optimized Reads on Amazon RDS for MySQL and Amazon RDS for MariaDB | Amazon Web Services
AWS Database Blog Improve query performance using Optimized Reads on Amazon RDS for MySQL and Amazon RDS for MariaDB Amazon Relational Database Service (Amazon RDS) makes it easy to set up, operate, and scale MySQL and MariaDB deployments in the cloud. Developers are often required to run complex queries in MySQL and MariaDB environments to create a dashboard or run simple ad hoc reports. Furtherm
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)NTT DATA Technology & Innovation
Table of Contents cat head tail wc grep cut paste sort uniq awk tr fold sed Real-life examples Going further: for loops and xargs Summary Going further Text processing in the shell One of the things that makes the shell an invaluable tool is the amount of available text processing commands, and the ability to easily pipe them into each other to build complex text processing workflows. These comman
◆ Live配信スケジュール ◆ サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。 ⇒ 詳細スケジュールはこちらから ⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください 【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました 生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!! https://tech-lab.connpass.com/event/315703/ こんにちは。サイオステクノロジー OSS サポート担当 山本 です。 今回は以前紹介した監視ツール Prometheus が収集するためのデータを出力するツール Exporter について、いくつかの Exporte
本記事の目的 本記事では MySQL(InnoDB) の SQL 性能調査・改善のために、実行計画の主要な確認ポイントを整理します。 また、SQL の重要な要素であるインデックスについても基本を簡単におさらいします。 なお、MySQL 実行計画の各種項目の意味は公式サイトに記載があるが、ぱっと見た時にどれが SQL の性能において重要度が高いのか少しわかりずらかったりしたので、今後のためにも記事に残すことにしました。 SQL パフォーマンスまわりで参考になった書籍や記事も最後に紹介していますので、ぜひそちらも合わせて参考にしてみてください。 インデックスとは インデックスはデータベースの中で特有の構造を持ち、CREATE INDEX 文で作成可能です。 SQL の性能に関わる重要な要素です。 データベースのインデックスは、分厚い紙の辞書から特定の用語を検索することに似ています。あらかじめ順
InnoDBのすゝめ（仮）を読んで或いはAppendix（前半） - hiroki-uemuraのブログ
注意 この記事の内容は完全に一部のエンジニアむけ、それもかなりニッチで高度な話題を取り上げます。エンジニア以外の人が読んでも意味が分からないだろうし、理解に必要な労力に対し、得られるものは多くはありません。 はじめに InnoDBのすゝめ（仮） from Takanori Sejima www.slideshare.netｚ 私の尊敬するエンジニアである瀬島さんが力作スライドを公開されました。 前述の資料はDBAである瀬島さんの目線で書かれており、また内容としても比較的MySQLへの理解がある人向けであるため、アプリケーションエンジニアである私の目線から特に重要な点について解説・考察を補足いたします。 そもそものはなし よほど激しい更新や、よほど大きいデータ量を扱わない限り、MySQLはデフォルトの設定で、常識の範囲内のコストで動作します。特にAWSなどのパブリッククラウドではかなり柔軟に
2022年7月13日にカラーミーショップで提供開始した「副管理者機能」のアップデートにあたって、従前の挙動を変えずにデータベーススキーマの構造を変える必要がありました。また、サービスの提供を停止することなく、スキーマの構造の変更を進める必要がありました。 この記事では、サービスを停止せずにデータベースの構造を徐々に変更するデータベースリファクタリングをどのように進めたかについて紹介します。 「データベースリファクタリング」とは データベースリファクタリングについて体系的に述べた書籍として"Refactoring Databases"があります。この本では、データベースリファクタリングのさまざまなパターンにおいて、スキーマの変更、データマイグレーション（既存データの移行）、アプリケーションの変更それぞれをどのように進めるべきかについて解説しています。ここでは、"Refactoring Dat
こんにちは、インフラエンジニア の 加藤(@kuromitsu_ka)です。 この記事は Enigmo Advent Calendar 2021 の 24 日目の記事です。 今回は、オンプレミスのMySQLを、Auroraへ移行する際、困ったことと対応したことを記載します。 移行方式をざっくりいうと、オンプレミスのMySQLより取得した、論理バックアップ(mysqldump)とバイナリログを使用してAuroraへ移行しました。移行のため、リストア環境と、リストア後のデータのチェック環境を構築したので先にその説明を記載して、困ったところと対応を記載していきます。 リストア環境 オンプレミスMySQLサーバから取得した、バックアップファイルをAuroraへ適用する環境を作りました。EC2のMySQLと、Auroraとでレプリケーションを貼り、EC2のMySQLにデータを投入してリストアしました
概要 関わる機会があって必要だったのでメモ。 ただしこの操作については公式ドキュメントで、推奨していない操作であるため、本当はするべきではない。 mysql データベース内の MySQL システムテーブルを MyISAM から InnoDB テーブルに変換しないでください。これはサポートされていない操作です。これを行うと、mysql_install_db プログラムを使用してバックアップから古いシステムテーブルをリストアするか、再生成するまで、MySQL は再起動されません。 該当ドキュメント またこれを行う際にログをNFSマウントを使って共有するのはよくないことらしい。 NFS ボリューム上でデータファイルやログファイルが使用されるように InnoDB を構成することは、適切ではありません。それ以外の場合は、ファイルがほかのプロセスによってロックされ、MySQL で使用できなくなる可能性
いよいよ、昨年11月から、Amazon Aurora 8.0がリリースされ、8.0への移行の日が差し迫ってきました。 Spacelyでは、現在、Aurora MySQL5.7を利用していますが、8.0移行の前準備として、最近の最適化の仕組みを学びはじめました。 筆者が知っている時代よりも、最適化プロセス(オプティマイザの機能)がかなり高機能なものになっており、今まで思い込んでいた、勝手に作られるTemporary Tableが遅いとか、サブクエリが遅いとか、INよりEXISTSが早いとか・・・・・そういった固定観念を一気に拭うときがやってきたようです。インデックスが貼られていないと遅すぎてサーバーがマシンごとヒートアップする・・・というのも近い将来には見なくなる光景かもしれません・・・ 今回は、Optimizer関連の変数を確認しながら最適化について学びます。 MySQL初心者や忘れてしま
Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databasesを読む(その4 THE LOG MARCHES FORWARD) - CubicLouve
4 THE LOG MARCHES FORWARD ここでは、永続状態、実行状態、レプリカ状態で常に一貫しているように、データベースエンジンからどのようにログが生成されるかを説明する。(3つの状態があるってことか) 特に、コストが高い2PC(2 phase commit)のプロトコルを使わずに、効率的に一貫性を保つ実装方法を述べる。 (データ指向アプリケーションデザイン p 386あたりを参照する) まず、クラッシュリカバリー時におけるコストの高いredo処理を回避する方法を示す。 次に、通常の運用時と、実行状態とレプリカ状態の維持の方法を説明する。 最後に. リカバリー処理の詳細を示す。 補足の資料を用意してあります。 spring-mt.hatenablog.com 4.1 解決策の全体像 : 非同期処理 セクション3で説明したように、Auroraではデータベースをredoログストリー
MySQLでは、さまざまなアプローチでのクエリチューニングが存在します。WHERE条件のカラムにインデックスが存在しない場合にインデックスを追加するなど、簡単なチューニングでも大きな改善は見込めます。 今回は、LIMIT OFFSETにて問題になるクエリについて、以下の2つのチューニング方法を紹介します。 読み取り行数を減らすアプローチ 読み取りページ数を減らすアプローチ サンプルのテーブルとデータ、クエリを元に、具体例にて説明します。 前準備 以下のようなテーブルを用意します。 mysql> SHOW CREATE TABLE test\G Table: test Create Table: CREATE TABLE `test` ( `id` int NOT NULL AUTO_INCREMENT, `k` int NOT NULL DEFAULT '0', `c` text, PRI
INSERT...SELETC でauto_increment値が飛ぶ話 - amamanamam
環境 CREATE TABLE `t2` ( `id` int NOT NULL, `id2` int NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`), KEY `id2` (`id2`) ) mysql> select version(); +--------------+ | version() | +--------------+ | 8.0.28-debug | +--------------+ 1 row in set (0.00 sec) mysql> select @@auto_increment_increment; +----------------------------+ | @@auto_increment_increment | +----------------------------+ | 1 | +----------
今起きた事を話すMySQL5.6の timestamp型で、こんな感じの default指定のない timestamp型の create tableを書いた場合 create table xxxxx ( id bigint(20) unsigned auto_increment not null comment 'ID' , created_at timestamp comment '作成日時' , updated_at timestamp comment '更新日時' ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
今回は Munin グラフについて考えます インフラエンジニアの皆さんであればサーバーの状態を把握するために、Cacti, Munin, Zabbix 等のツールを使いロードアベレージ等の数値をグラフ化していることと思います。 今回はどういったグラフを見ておけばよいかを考えます。 私の場合は普段は Munin を使っているため、今回は Munin に特化した話です。 ただ、グラフに対する考え方についてはすべてのツールで共通ですね。 グラフ化する目的は下記の 2点だと思われます トラブル発生時の状態把握を迅速に行うため 中長期でのリソースの消費量増加具合を把握し、パフォーマンスチューニングやリソース増強の前提データとする グラフの用途その1 (トラブル発生時の状態把握を迅速に行うため) 何かサーバートラブルが発生した際には、どこかの箇所で何かの変化が起き、その結果としてサーバートラブルとなっ
多対一リレーションの設計手法によるパフォーマンスの違いを確認した - Mobile Factory Tech Blog
この記事はモバイルファクトリー Advent Calendar 2020 15日目の記事です。 エンジニアの yokoi0803 です。DB設計をしていて多対一のリレーションを見たり、設計したりする機会が何度かあって、その度にどう設計するかで悩んでます。 多対一のリレーションはいくつかの設計で実現できますが、その選定の際の指標を得るため、今回はパフォーマンスの観点から設計の比較をしてみたいと思います。 多対一のリレーションを表現する3つの設計 あるテーブルが複数のテーブルに対して多対一で紐付くケースについて、ここではくじ引きとその景品を表現するためのDB設計を想定します。 箱の中のくじそれぞれに景品が設定されており、景品には旅行券や果物など、様々な種類のものがあります。 こういった仕様の設計手法にはいくつか種類がありますが、今回は「ポリモーフィック関連」、「交差テーブルを用いた設計」、「親
Reduce downtime with Amazon Aurora MySQL database restart time optimizations | Amazon Web Services
AWS Database Blog Reduce downtime with Amazon Aurora MySQL database restart time optimizations When using Amazon Aurora MySQL-Compatible Edition for operating your relational databases in the AWS cloud, one of the key requirements is to verify that it is highly available during planned and unplanned outages. As database administrators, you should perform occasional database maintenance. This can b
Create Authentication Login and Registration in CodeIgniter 4
As a web developer, you understand that implementing secure and efficient authentication is essential for protecting user data and enabling personalized experiences on your applications. This feature is integral to modern web development, as it supports the security and privacy of user accounts. In this tutorial, we’ll walk you through setting up a registration system and a login system using the
はじめに 自分用にテーブルが断片化してるか否かを確認する方法を書いてみました。 もし他にこんなのあるよー、って話あれば教えてください。 SHOW TABLE STATUS Data_freeを見ると良い innodb_file_per_tableオプションが有効であるべき mysql> SHOW TABLE STATUS FROM test\G *************************** 1. row *************************** Name: t1 Engine: InnoDB Version: 10 Row_format: Dynamic Rows: 0 Avg_row_length: 0 Data_length: 98304 Max_data_length: 0 Index_length: 16384 Data_free: 0 Auto_incre
Tweet 今年も大盛り上がりな ISUCON 7 でしたが、わたしも†空中庭園†《ガーデンプレイス》というチームで、同僚の @ryot_a_rai さんと @eagletmt さんと一緒に予選 (2 日目) に出場しました。 ISUCON7 本選出場者決定のお知らせ : ISUCON公式Blog にある通り、最終スコアは 588,107 でなんと両日合わせてのトップでした。身に余る光栄..! 自分用の記録も兼ねて、チームでどのように考えて動いたのかをメモしておきたいと思います。 📃 リポジトリ リポジトリは @ryot_a_rai さんが公開してくれていますので、以下の GitHub リポジトリを覗いてみてください。 ryotarai/isucon7q 参考実装は Golang を選択したので、主な変更は Golang の参考実装に対して行っています。また、MySQL の設定などもいじ
ProxySQL入門、ProxySQLでDBサーバーの負荷分散とAuroraの高速フェイルオーバーに対応してみる - アクトインディ開発者ブログ
こんにちは、キエンです。 最近、DBサーバーの負荷分散とAuroraの高速フェイルオーバーの対策を調査した時、ProxySQLを検証しましたので、ご紹介します。 ProxySQLとは? ProxySQLはMySQLおよびfork（Percona ServerやMariaDBなど）用の高性能で高可用性のプロトコル対応プロキシです。ライセンスはGPLv3となっています。以下の主な特徴はあります。 クエリーキャッシュ クエリールーティング フェイルオーバーサポート ファイアーウォール ProxySQLの公開サイト ホームページ GitHub ウィキ ProxySQLの構成 ProxySQLの構成は複雑ですが、以下のニーズを満たすため使いやすい構成システムがあります。 設定を簡単に動的更新を許可する ゼロダウンタイムプロビジョニングが必要な大規模なインフラストラクチャでProxySQLを使用できる
今回は、第214回 MySQL ShellでMySQLに接続してみるで紹介させていただいたMySQL Shellを使ってJavaScriptで操作する方法を紹介したいと思います。 検証環境 今回はDockerで建てたMySQLを使用します。以下のコマンドでDockerを建てて、ローカルからアクセスをします。 % docker run --platform linux/x86_64 -p 127.0.0.1:3307:3306 -e MYSQL_ROOT_PASSWORD=my-secret-pw -e MYSQL_USER=kk2170 -e MYSQL_PASSWORD=my-secret-pw -d mysql:8.0.36 今回はMySQL Shellをインストールして実行していきますが、一旦従来のmysqlクライアントでアクセスが可能であることを確認しましょう。方法は以下の通りにな
Queries for Finding Poorly-Designed MySQL Schemas and How to Fix Them
If you watched Finding Poorly Designed Schemas and How to Fix Them you witnessed Marcos Albe use some very interesting queries. These queries let you find tables without primary keys, tables with non-integer primary keys, tables that do not use InnoDB, tables and indexes with the most latency, indexes that are 50% larger than the table, find duplicate indexes, and find unused indexes. As promised,
■設定ファイル(/etc/my.cnf , /etc/mysql/mariadb.conf.d/50-server.cnf) [mysqld] # ——————————————– # InnoDBのデータとインデックスをキャッシュするバッファのサイズ(推奨は物理メモリの7割) innodb_buffer_pool_size=2G # InnoDBの更新ログを記録するディスク上のファイルサイズ(innodb_buffer_pool_sizeの25%程度) # innodb_log_fileがいっぱいになると、メモリ上のinnodb_buffer_poolの中の更新された部分のデータをデータファイルに書き出す仕組み。 # innodb_buffer_pool_sizeを大きくしたら、innodb_log_file_sizeもあわせて調整しないとパフォーマンスが向上しない。 innodb_log
Debugging MySQL/MariaDB (4): Debugging with rr - nayuta-yanagisawa's blog
重い腰を上げて Debugging MySQL/MariaDB シリーズの第4弾を書いている。今回は rr debugger を使用したデバッグについて説明する。Intel または AMD の CPU を搭載した物理マシンに Linux (kernel 3.11+) をネイティブインストールした環境を前提とする。 rr debugger rr は Pernoscoによって開発されているデバッガーである。rr は gdb と同じ感覚で使えるが、次に挙げる gdb にはないすばらしい特徴を備えている。 プログラムの実行を記録し、バグを何度でも決定的に再現することができる。 ブレークポイントやウォッチポイントまで逆実行 (reverse execution) できる。 これらの特徴の何がすばらしいのか？想像してほしい。散発的なバグ（再現したりしなかったりするバグ）を GDB でデバッグするのは苦
「MySQLで外部キー制約を設定する方法」「外部キー制約のオプション設定(RESTRICTCASCADESET NULLNO ACTION)による動作の違い」について解説します。 外部キー制約の実現方法 外部キー制約を実現する方法は2つあります。 データベース上で外部キー制約を設定 アプリケーションで外部キー制約の制限のもと動作するように開発 MySQLのデータベースエンジンであるMyISAMは、外部キー制約をサポートしていません。そのため、アプリケーションで外部キー制約を考慮する必要がありました。しかし、機能拡張などしていくうちに、制限のことが忘れ去られることが多く、データの整合性が崩れるといったことが起こりえます。 アプリケーションだけでデータの整合性を維持しようとすると、後々、 何かしらのトラブルが発生する可能性が高まること データの整合性が維持されているかを確認するための作業が必要
8.x マイグレーション Laravel
イントロダクションIntroduction マイグレーションはデータベースのバージョン管理のようなもので、チームがアプリケーションのデータベーススキーマを定義および共有できるようにします。ソース管理から変更を取得した後に、ローカルデータベーススキーマにカラムを手動で追加するようにチームメートに指示する必要があったことを経験していれば、データベースのマイグレーションにより解決される問題に直面していたのです。Migrations are like version control for your database, allowing your team to define and share the application's database schema definition. If you have ever had to tell a teammate to manually add
概要 InnoDB では、追加・更新・削除操作を繰り返していると、断片化（フラグメンテーション）という現象が発生します。 これはいわば、ゴミみたいなもので、テーブルのデータを削除してもディスク容量が減りません。 このゴミが増えてくると、クエリ処理が遅くなる可能性があリます。 例えばレコードが100万件あるテーブルの内、99万9999件を削除し1件の状態にしても、テーブルが占有している領域は100万件分使っているということになります。 今回は実際にテストデータを作成し、フラグメンテーションの発生とその解消法について確認していきたいと思います。 フラグメンテーションの詳細については本記事では述べないので、気になる方は下記記事が分かりやすかったのでご参照ください。 前提 MySQL 5.7.31 InnoDB テストデータの挿入 まずテスト用のDBとテーブルを作り、約100万件テストデータを挿入
運用中のMySQLに対して書き込み（DML）を制限したいことがあると思います。たとえば、読み取り専用のMySQLを作成したり、バージョンアップのため新しいバージョンのスレーブを用意してマスターと切り替えるときに、マスターに対して書き込みを制限したいなどです。 また、もしあなたがMySQLのHAを提供する仕組みを作ることになったとすると、さまざまなMySQLの機能を使い実装すると思います。 そして、フェールオーバーに失敗し、スプリットブレインが発生する可能性を考慮しなくてはいけません。それを防ぐために、ユーザーからMySQLへの書き込みを禁止する仕組みが必要です。 MySQLには書き込みを禁止するためのいろんなオプションや手段があります。今回はMySQLへの書き込みを制限するさまざまな方法を紹介したいと思います。 1. READ_ONLY オプション 最初に紹介するのはREAD_ONLYオプ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL Transactions - the physical side
InnoDB Clusterよ、お前は何者なんだ
Dockerを使ってLAMP開発環境を整えるまでの奮闘記 - Qiita
第51回 「企業ITシステムのモダナイゼーションとデータベース最新状況」報告、MySQL 8.0.18リリース、PostgreSQL 12リリース | gihyo.jp
第89回 MySQL ＆ PostgreSQLの2022年の主なニュース | gihyo.jp
NAND Flash から InnoDB にかけての話（仮）
Balthazar – Text processing in the shell
Prometheus の Exporter について | SIOS Tech. Lab
MySQL SQLパフォーマンス改善 -実行計画の確認ポイント-
サービスを停止せずにデータベースリファクタリングする - Pepabo Tech Portal
オンプレミスMySQLをAuroraへ移行する際に、困ったこととその対応 - エニグモ開発者ブログ
MyISAM から InnoDB への移行の注意点 - Qiita
MySQL 5.7で学ぶMySQLの最適化 (環境設定とパラメータ理解) - spacelyのブログ
第200回 LIMIT OFFSETに関するMySQLクエリチューニング | gihyo.jp
MySQL5.7のtimestamp型でInvalid default valueが出るエラーの対処メモ | 7me
サーバーの負荷状態を把握するために見ておくべき Munin グラフとは - Neinvalli
【MySQL】テーブルの断片化を確認しよう - 41から始めました
ISUCON 7 の予選を突破した (†空中庭園†《ガーデンプレイス》)
第216回 MySQL ShellでJavaScriptを使ってMySQLを操作してみよう［その1］ | gihyo.jp
MariaDB/MySQL性能チューニング（パラメータ設定見直し）｜ITの魔力
MySQL | 外部キー制約の設定と動作確認 - わくわくBank
MySQLのInnoDB テーブルの断片化(フラグメンテーション)を解消する - Qiita
第126回 MySQLへの書き込みを制限するさまざまな方法 | gihyo.jp