こんにちは。id:shallow1729です。先日はredo logを中心にストレージエンジンについて解説を行いましたが、今回は同時実行制御、特にMySQLなど多くのデータベースで採用されているMultiversion Concurrency Control(MVCC)という技術にフォーカスしようと思います。 今回の記事ではまず前半でMVCCというものがどういうものかについて解説をして、次にMVCCの実装方法についてInnoDBの実装を参考にしながら見ていこうと思います。前提知識はあまりいらないと思いますが、リレーショナルデータベースの操作経験はあったほうがいいかなと思います。また、前回のストレージエンジンの解説で述べた内容はあまり説明しないので、軽く目を通してもらえると頭に入りやすいかなと思います。 shallow1729.hatenablog.com トランザクションの原子性 まずトラ

MySQLでは、オプティマイザーヒントを使用してオプティマイザーを制御することで、実行計画を変更することができます。このオプティマイザーヒントはステートメントに適用できるため、ステートメント単位で最適化が可能になります。MySQL 5.7とそれ以降から使用可能です。 今回は、MySQL 8.0から追加されたオプティマイザーのヒントを主に紹介したいと思います。 オプティマイザーヒント構文 オプティマイザーのヒントは/*+ ... */をステートメント内に記述します。SELECT、UPDATEやDELETEなどのDMLのキーワードの後にヒントを記述します。ヒントの内容をパーサーが認識して処理します。以下のように記載します。 mysql> SELECT /*+ hint */ ... mysql> UPDATE /*+ hint */ ... 指定したヒントが有効か確認するには、EXPLAIN後

今回から3回に渡って、GitHub社がOSSとして公開しているオンラインスキーママイグレーションツール gh-ostについて紹介したいと思います。 はじめに、MySQLのオンラインスキーママイグレーションというとMySQL 5.6からオンラインDDLがあります。これにより、並列でDMLが実行されてもロックすることなくスキーマ変更が可能です。特に、MySQL 8.0からのInstance Add Columnは、テーブルをリビルドすることなく即時でカラム追加が完了するといううれしい機能です。 しかし、int型からbigint型へなどの型変更を伴うALTERステートメントなど、いくつかの操作は並列のDMLが許可されない、つまりそのテーブルが全体ロックされるような動作になります。加えて、レプリケーションの遅延が発生する可能性もあります。このように、操作の種類によってAlter中にできる動作が異な

皆さんはカラムにNULLが入らないようにするNOT NULL制約を積極的に使っていますか？ もし使うにしても、どうしてもカラムにNULLを入れる必要があったり、過去からのしがらみなどから、どうしても付けられていないという場合もあると思います。そんな時に、厄介に感じるのはNULL値の値です。NULL値の比較に通常の=による比較演算子を使用すると、想定した結果が得られないためバグにつながる可能性もあります。 今回は、NULL値が入る可能性がある場合に便利な<=>演算子について紹介していきます。 検証環境 今回は第125回　phpMyAdminでDockerで建てたMySQLにアクセスするで記載したdocker-composeを利用して作成します。手元で簡単に試せるように、GitHubのわたしのレポジトリにサンプルコードとして置いてあるので、気軽に試したい方はgit cloneして試してみてくだ

どうも、シローです。 今回は、特定の文字列に限定した列を定義する方法について、アンチパターン「サーティワンフレーバー」も一緒に紹介します。 特定の値を持ちうる列とは 例えばユーザ(Users)の権限（管理者かメンバーか）を表したい場合、Usersテーブルにメンバーの権限を表すuser_roleという列を定義するとします。 このuser_roleには管理者の場合はadmin、メンバーの場合はmemberという値を持ちそれ以外の値は格納しない（できない）ようにするにはどうすれば良いのか アンチパターン「サーティワンフレーバー」について 先にアンチパターンについて紹介します。 サーティワンフレーバーと呼ばれる設計方法では特定の値を入れるために 列にCHECK制約を入れる(MySQL8.0以降) 列をENUM型にする という手法を取りうることです。 僕の環境はMySQL5.7なのでENUM型のカラ

zenn.dev を読んでの感想です。「シーケンスナンバーをPKにする」以外の項目については言及しませんが、言及しないことは正当性や妥当性を保証していることにはならないです。 InnoDB(MySQL)を想定してます。が、原理は割と一般的なので他のDBでも適用できることが多いと思います。 追記:一般的とは分散でないような"普通の"RDBMSを想定してましたが、分散システム(distributed systemないしreplicated system)のような場合では話が違います。 なぜシーケンシャルな値がよいか 端的にいうと書き込み操作時にバッファープール(baffuer pool)に読み混む必要のあるページが少なくて済むからです。その結果書き込み操作時にバッファープールにページが存在する可能性が高くレイテンシー的に有利になる可能性が高いです。 バッファープール、ページ、btreeなど具体

技術本部 サービスリライアビリティグループ（SRG）の長谷川 @rarirureluis です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 また Amazon Aurora MySQL（以下：Aurora MySQL）の話です。何でこんなに Aurora MySQL に関する記事ばっか書いてるのか僕も分かりません。 前回の Aurora MySQL のアップグレード方法のベストプラクティスはこちらです。 RDS Graviton2 に少ないリスクで切り替える方法を考えてみる【アップグレード編】 | CyberAgent Developers Blog 今回はバックアップについてです。 そのクラスター、間違ったクエリ流したときに

こんにちは。id:shallow1729です。最近Database Reliability Engineerというお仕事を始めたのでデータベースの勉強をしたりMySQLのソースコードを読んだりしています。仕事でMySQLが標準で用いているInnoDBのソースコードを読む機会があったのでなんかアウトプットしたいなと思いつついきなりコアな話するのもなって思ったのでざっくりとストレージエンジンの話をしようかなと思います。とはいえストレージエンジンは本当にいろいろな仕事をしていて全部を書こうとするとものすごい事になりそうだった(+僕も分かってない部分が多い)ので、とりあえず第一回はredo logというやつを中心にストレージエンジンを追っていこうと思います。なるべく一般的なデータベースの設計の話を軸に置きつつInnoDBの場合の話もしていこうと思います。読者としてはMySQLのようなリレーショナル

Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M

こんにちは。 アイスタイル DBAのsugatです。 連休はいかがお過ごしですか？ データベースバカな私は良い天気にもかかわらず、 お家でDBの検証な日々です。 寂しくなんか…ないもん… そんなことより、以前私はこんな記事をQiitaに投稿したのですが、 今回はその続きのお話です。 とあるプロジェクトでMariaDBとSpiderを使おう、という話が挙がったため、 このタイミングでVP（Vertical Partitioning）も導入してみてはどうだろう、と 検証を再開しました。 今回のお題「Vertical Partitioning と Spider ストレージエンジン」 前置きはこれくらいにして、本題に入りましょう。 今回は前回の記事でも紹介した↓の記事を参考にしています。 「OSSのカラム型DBはここまで進化！ インサイトテクノロジー・小幡一郎氏」 また、今回初となるVPストレージ

この記事は DeNA 20 新卒 Advent Calendar 2020 19日目の記事です。 はじめに MySQLやPostgreSQLに代表されるRDBMSではトランザクションと呼ばれる仕組みが提供されています。多くのWebアプリケーションエンジニアはこのトランザクションを駆使してDBとやりとりをするロジックを組み立てることになります。 しかし不整合を起こしたくない処理があるからといって闇雲にトランザクションを張ったり、トランザクションが張られているからと安心してアプリケーション側で闇雲にロジックを組み立ててしまうと思わぬバグを生むことになってしまいます。 このエントリでは、「トランザクションを張っておけば大丈夫」という考え方は危険な場合もあるということを、ありがちな実装例を交えて紹介していきます。 並列に処理されるトランザクション そもそも、トランザクションは全て直列に処理されるわ

この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC

2019年4月19日に開催された「中国地方DB勉強会 in 沖縄」のLTでの発表資料です。 https://dbstudychugoku.connpass.com/event/127067/

mysqlfailoverとは？ mysqlfailover はOracle社が提供している MySQL Utilities というツール群の中の1つです。 下記の図のようにレプリケーション構成において、マスターに障害が発生した場合、スレーブをマスターに切り替えるフェイルオーバー処理を自動で行うツールです。 検証MySQL環境構築 今回の検証ではdockerを使って マスター1台（node1）、スレーブ2台（node2, node3）、mysqlfailoverを実行するマシン（admin）の4インスタンス構成で行います。 設定ファイル docker-compose.yml version: '3' services: node1: image: mysql/mysql-server:5.7 environment: - MYSQL_ROOT_PASSWORD=password volum

After intensive testing and hack, we started using Semi-Synchronous MySQL Replication at Facebook production environments. Semi-Synchronous Replication itself was ready since MySQL 5.5 (GA was released 3.5 years ago!), but I'm pretty sure not many people have used in production so far. Here are summary of our objective, enhancements and usage patterns. If you want to hear more in depth, please fee

MySQL 5.5での準同期レプリケーション 準同期レプリケーション自体はMySQL 5.5から導入されました。マスターー側およびスレーブ側にそれぞれ準同期レプリケーション用のプラグインをインストールし、マスターー側で rpl_semi_sync_master_enabled とスレーブ側で rpl_semi_sync_slave_enabled を有効にしておくと準同期レプリケーションが利用できるようになります。 rpl_semi_sync_master_enabled を有効にしたマスターに対して、非同期レプリケーションと準同期レプリケーションのスレーブを混在させることは可能です。 準同期レプリケーションの流れ アプリケーションからトランザクションをコミット バイナリログとストレージエンジンにトランザクション内容を記録 マスターからスレーブにトランザクション内容を転送 スレーブのリレー

Welcome to the Percona Community blog!If you're interested in contributing, you can submit a pull request on GitHub with either your own topic or pick one of our open topics. Percona Monitoring and Management 2.43.0 Tech Preview Release Hello everyone! Percona Monitoring and Management (PMM) 2.43.0 is now available as a Tech Preview Release....

Rails Developers Meetup 2018: Day 1 (https://techplay.jp/event/639872) の発表資料です。 See also Rails Developers Meetup 2018 で「MySQL/InnoDB の裏側」を発表しました - あらびき日記 https://abicky.net/2018/03/25/141353/