MVCCとInnoDBでの実装について - shallowな暮らし
こんにちは。id:shallow1729です。先日はredo logを中心にストレージエンジンについて解説を行いましたが、今回は同時実行制御、特にMySQLなど多くのデータベースで採用されているMultiversion Concurrency Control(MVCC)という技術にフォーカスしようと思います。 今回の記事ではまず前半でMVCCというものがどういうものかについて解説をして、次にMVCCの実装方法についてInnoDBの実装を参考にしながら見ていこうと思います。前提知識はあまりいらないと思いますが、リレーショナルデータベースの操作経験はあったほうがいいかなと思います。また、前回のストレージエンジンの解説で述べた内容はあまり説明しないので、軽く目を通してもらえると頭に入りやすいかなと思います。 shallow1729.hatenablog.com トランザクションの原子性 まずトラ
SELECT文で本番環境を落としたお話 - Qiita
（この記事は 地平線に行く とのマルチポストです） 本番環境でやらかしちゃった人 Advent Calendarで、このパターンのやらかしはなかったのでキーボードを叩くことにしました。 番外編のつもりでお楽しみください。 この記事が、新たな障害発生を防ぐことにつながれば幸いです。 何をやったのか ある日、ちょっとした調査のために本番データベースのデータを確認することになりました。 （個人情報が格納されているようなシステムではなかったので、必要であれば本番データベースへのアクセスが許されていました） もしメンテナンスがあればそのタイミングでやればよかったのですが、直近では特に予定はないとのことでした。そのため、システムが動いている状態のまま作業をすることにしました。 ごく単純な SELECT を実行するだけのつもりだったので、システムに影響がないと判断したためです。 その際、万が一コピペをミ
【Laravel】 MySQL がマスタスレーブ構成のとき，リクエストを超えて sticky 効果を適用する - Qiita
【Laravel】 MySQL がマスタスレーブ構成のとき，リクエストを超えて sticky 効果を適用するPHPMySQLLaravel 2019-12-31 追記: ライブラリ化しました！インストール＆サービスプロバイダに1個登録するだけで簡単に使えるようになっています！ mpyw/laravel-cached-database-stickiness: Guarantee database stickiness over the same user's consecutive requests 概要 MySQL や Aurora などで，マスタスレーブ構成にして SELECT はスレーブに対して実行 INSERT UPDATE DELETE はマスタに対して実行 という設定にすることはよくある。 Laravel はフレームワークレベルでこの設定をサポートしており，自動的に振り分けを行な
Laravelを拡張して、使用したコネクションに対して自動的にトランザクションを張るようにする | GMO MEDIA CREATOR BLOG
日々のWebサイトやアプリの制作を通じて、役に立ちそうな技術情報や楽しい話を発信しています。私たちはGMOメディア株式会社のクリエイターです。 この記事は この記事は GMOペパボ Advent Calendar 2018 の12月26日の記事です。 私はペパボのひとではありませんが、26日目なら名乗ってもOKとのことだったので、これは26日目の記事(非公式)です！ こんにちは。PHPエンジニアの千葉です。すっかり寒くなって毎朝おふとんからなかなか出られません。。 さて。先日、Laravelフレームワークが使われている開発中のとある機能を動かしていたとき、例外が発生したのにロールバックされていないデータがあることに気が付きました。コードを見ると、トランザクション処理は入っていました。 なぜロールバックされなかったのか、そしてそれにどのように対処したのかをまとめた記事です。 Laravelの
MySQLでSELECT FOR UPDATEと行ロックの挙動を検証してみた - Continue(s)
どうも、今日も今日とて野毛で飲みながらブログを書いている@0kawaraです。 今日は、普段あまり意識してこなかったMySQLのInnoDBでのロックの振る舞いについて色々実験してみました。（もちろん、きっかは自分がドツボにはまったから） ちゃんと理解するためには「共有・排他的ロックとは」って話や、「行ロックってつまりインデックスレコードロックだよね」などの話とか理解する必要があるんですが、それは github.com をちゃんと一読してもらえれば十分かと思います。 （というか、これが問題なく読めて理解できる人はこの記事読む必要ない….） 以下は上のドキュメント含め関連する記事などを読んで自分でInnoDBの行ロック周りについて、というかSELECT FOR UPDATEについて理解を深めるために手元で実験したことのまとめです。 技術的にちゃんとした理解を深めたい人は最後にまとめた参考サイ
DynamoDBでのポイントまとめ - Qiita
2018/05/24追記: AWS公式ドキュメントに Best Practices for DynamoDB が公開されているので、コチラをチェックしましょう。 0.前提 このドキュメントは、先に下記の参考資料を読み、後で振り返りやすいようポイントをまとめることを目的としています。そのため、用語などの解説は行いません。 参考資料 Must AWS Black Belt Techシリーズ Amazon DynamoDB - Slideshare Amazon DynamoDB（初心者向け 超速マスター編）JAWSUG大阪 - Slideshare DynamoDBによるソーシャルゲーム実装 How To - Slideshare Optional DynamoDB ベストプラクティス - Qiita AWS Summit 2014 Tokyo「Amazon DynamoDB テーブル設計と実
InnoDBのオプティマイザとロックの範囲の関係 - addsict's blog
MySQLのInnoDBのロックの挙動を色々調べていたのですが、レコードの数によってロックの範囲が変わる現象に頭を悩まされたので、メモがてら少しまとめてみます。 どこまでロックする？ 以下のようなテーブルがあるとします。 id列に1〜6までの数値が入っています。 CREATE TABLE t ( `id` int unsigned NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB; INSERT INTO t VALUES (1),(2),(3),(4),(5),(6); ではidが3より小さなレコードを取得するクエリを投げると、どのレコードをロックするでしょうか。 BEGIN; SELECT id FROM t WHERE id < 3 LOCK IN SHARE MODE; 1〜2のレコードでしょうか。それとも1〜3までロックするでしょうか。 実
InnoDB の行レベルロックについて解説してみる
自分の浅はかな理解だと、Deadlock が起こる理由が説明できないケースに遭遇したので、InnoDB の行レベルロックについて調べてまとめてみました。 「行レベルロックだと、同じ行を更新する場合にしか Deadlock が起こらないんでしょ」と思っているような人が対象です。 また、主に InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる を参考にさせていただいたので、そちらの内容がすんなり理解できる方には冗長な内容だと思います。 MySQL のバージョンは 5.6.33 です。 サンプルデータ 次の SQL で作成したデータを扱うことにします。 CREATE TABLE `orders` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `product_id` int(10) unsigned NOT NULL, `us
MySQL のデッドロックを調査した - エムティーアイ エンジニアリングブログ
こんにちは。アーキテクト見習いエンジニアの小池です。 年の瀬ですね。弊社は今日が最終業務日です。 掃除がてら今年あったことを何か記事にしておこうと思います。 とあるシステムでデータベースのデッドロックが原因のエラー調査をすることになり、普段データベースをガッツリ触らない僕にとって、この調査をすること自体が非常に勉強になったので記事にします。 そのシステムのデータベースは Amazon Aurora MySQL (InnoDB) なのですが、これまで SQL Server を使ったシステムに関わることが多かったので両者の違いも感じられました。 テストテーブル 実際のテーブルはお見せできないので、再現用にミニマムなテストテーブルを用意します。 CREATE TABLE `test_table` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id`
トランザクション分離レベルの勉強記録(2) MySQLのinnodb_lock_monitor（検証） - Qiita
前回の検証はかなり基本的で大雑把だったので、もっと詳しく調べる。 色々と検証していたらとんでもなく長くなり、結論だけ別記事にしたので、この記事は飛ばしていいと思う。 おさらい トランザクション分離レベルは、同時実行で起こる問題をどれだけ排除できるか＝どれだけの正確性や一貫性が保証できるか、を段階的に定義したもの 現実的には、同時実行で起こる問題と性能の間で妥協点を見つける＝システムの仕様に応じてトランザクション分離レベルを選ぶ必要がある 同時実行で起こる問題をどのように排除するかは複数考えられる 操作をエラーにする 前のバージョンの値を使う 「どのように排除するか」まで解っていないと、適切なトランザクション分離レベルを選択できないと思う 検証したいこと 前回の検証は現象の起きる・起きないを眺めるだけだったので、実際にMySQLがどのように現象を排除しているかを調べたい。 分離レベルごとに、
MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.10.8 InnoDB 内で各種 SQL ステートメントによって設定されるロック
一般に、ロック読み取り、UPDATE、または DELETE では、SQL ステートメントの処理時にスキャンされるすべてのインデックスレコード上に、レコードロックが設定されます。 行を除外する WHERE 条件がステートメント内に存在するかどうかは、関係ありません。 InnoDB には正確な WHERE 条件が記憶されませんが、スキャンされたインデックスの範囲は認識されます。 通常、ロックはレコードの直前にある「ギャップ」への挿入もブロックするネクストキーロックです。 ただし、ギャップロックは明示的に無効にすることができます。これにより、ネクストキーロックが使用されなくなります。 詳細は、セクション15.7.1「InnoDB ロック」を参照してください。 トランザクション分離レベルによって、どのロックが設定されるのかも影響を受けます。セクション15.7.2.1「トランザクション分離レベル」を
InnoDBのロックに関する用語の確認 - Qiita
ロックの分類 InnoDBのロックは「タイプ1」「モード」「精密なモード2」で分類できる。 ロックのタイプ1（lock type） テーブルロック（table lock） 行ロック（row lock） ロックのタイプは2種類ある。InnoDBに限った概念ではない。 InnoDBではなるべくテーブルロックを使わず、行ロックを使うようにしているそうだ。実際、明示的にテーブルロックを利用しようという場面はほとんどないと思う。 たまに勘違いしている人をみかけるが、「行ロックの範囲がテーブル全体である」ことと「テーブルロック」は異なる。前者はあくまでも行ロックである。 システムによっては、メモリ節約のために「大量の行ロック」を「テーブルロック」に自動的に変更することもあるらしいが、InnoDBでは不要だそうだ。（参考：ロックのエスカレーション） また、InnoDBでは、行ロックだけを使っているつもり
tree-tips: MySQLのトランザクション分離レベル | MySQL
トランザクション分離レベルの種類 ANSI/ISO SQLでは、以下のように定義されています。 ロストアップデートについては特に策定されていないと思いますが、一覧に加えておきます。 分離レベル 性能 ダーティーリード ファジーリード ファントムリード ロストアップデート read uncommitted 高 起きる。 起きる。 起きる。 起きる。 read committed ｜ 起きない。 起きる。 起きる。 起きる。 repeatable read ｜ 起きない。 起きない。 起きる。 起きる。 serializable 低 起きない。 起きない。 起きない。 起きない。 ただし、ANSI/ISO SQLはあくまで仕様であって、実装・動作は各データベース毎に異なります。 MySQLの場合は以下のようになります。 分離レベル 性能 ダーティーリード ファジーリード ファントムリード ロス
良く分かるMySQL Innodbのギャップロック - Qiita
MySQLのロック ロックとはトランザクションの並列度を上げる為の並列スケジューリング方法の一つ トランザクションをサポートしているデータベースにおいては、トランザクションの並列数を上げる事が性能アップの一つの方法。 他のトランザクションに更新して欲しくないデータだけにロックをかけて、ロックされたデータ以外を更新するトランザクションは並列で実行される。 Innodbは行ロック？ Innodbは更新対象の行だけをロックする。と思っていると、意外な落とし穴にハマる。 その一つがギャップロック。 ギャップロックを実際に起こしてみる サンプルテーブル idとstrがあるだけのシンプルなテーブル。idがPKで1~5までは順番に、その後、10,20と飛んで行が入っている。 通常の行ロック トランザクション１ select for updateでid=2の行を明示的にロック トランザクション２ id=1
MySQL InnoDBの行ロック - There's an echo in my head
ロックがわからない。MySQL InnoDBの行レベルロックを読んだけど、イマイチわからない。というわけで、社内の勉強会で知ったことをまとめてみる。 FOR UPDATEかLOCK IN SHARE MODEによって、そのトランザクション中に走る別画面でのクエリの処理のタイミングが異なる。 FOR UPDATEによるロック まずは画面Aで接続が行われ、トランザクションが開始され、SELECT文が発行されたとする。 [画面A] BEGIN; // トランザクションA開始 SELECT * FROM users WHERE id = 1 FOR UPDATE; COMMIT; // トランザクションA終了 そしてトランザクションAの開始後〜終了前に画面B〜Dがクエリを発行したとする。 ちなみにトランザクションを開始しておかないとFOR UPDATEを書いても画面Aでのロックが始まらないので要注
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
tree-tips: MySQLのlock in share mode | MySQL
lock in share modeとは？ lock in share modeは、共有ロック・shared lock・slock、と言われているロックです。 for updateは、排他ロック・xlock、と言われています。 参照(select)する時にロックをする機能です。 lock in share modeはどんな時に使う？ 主な使い道は、ファジーリード・ロストアップデートを防ぐ、です。 ファジーリードはトランザクション分離レベルがread committed以下の場合の発生します。repeatable readの場合はそもそもANSI/ISO SQLの仕様上発生しません。 具体的な使い所としては、一覧画面の表示時のSQLや、不正データ検出、等で使うかと思います。 for updateとの違いは？ 最大の違いはslockによる参照をブロックしない・されない点です。つまり、参照同士の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDBMS in Action
スレッドIDを利用したMySQLのデッドロック解析手法
https://blog.sojiro.me/blog/2015/10/25/kinds-of-locks-of-innodb/