MySQLのロックについて - SH2の日記
JPOUG> SET EVENTS 20140907 | Japan Oracle User Group (JPOUG)に参加して発表をしてきました。IIJさまのセミナルームは窓からの眺めがすばらしいですね。JPOUGの運営メンバのみなさま、会場を提供してくださったIIJのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは「MySQLのロックについて」と題してネクストキーロックなどの説明をしました。プレゼンテーション資料と、調査のために作成したツールを公開します。 プレゼンテーション資料 (PDF) Lock Inspector 1.0 プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Lists: mysql: Re: InnoDB's inner workings + checkpoints 過去記事の訂正 @kami
MySQL - InnoDBのロック関連まとめ - Qiita
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 （追記：排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ） 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
MySQLのバックアップと"FLUSH TABLES WITH READ LOCK"について - jitsu102's blog
MySQLで整合性のあるバックアップを取得するのに、 "FLUSH TABLES WITH READ LOCK"でテーブルロック バックアップ処理(mysqldumpやスナップショット) "UNLOCK TABLES"でロック解除 みたいなスクリプトを実行していたが、"FLUSH TABLES WITH READ LOCK"って必ず数ミリ秒みたいなレベルでロックできるのかなと疑問に思った。 結構時間のかかるクエリが処理されていたりすると、すぐにロックできないんではないかと思った。 ちょっと調べてみると、やはりすぐにロックされない可能性もあるようだ。*1 FLUSH TABLES WITH READ LOCKの速度について ということで、"FLUSH TABLES WITH READ LOCK"後に、以下のような確認処理を追加した。 "SHOW PROCESSLIST"を実行して、"FLUS
ActiveRecordで行ロックをかける方法
行ロックとは 行ロックとは、テーブルの同一レコードに対して、複数同時に更新できないように制限する仕組みのことです。 Ruby on RailsのActiveRecordには２種類のロック方法があります。 楽観的ロック（Rails依存） 悲観的ロック（DBMS依存） それぞれの違いや使い方について解説していきたいと思います。 楽観的ロック 楽観的ロックとは、DBMSの機能に頼らずロックバージョンをレコードに保存しておくことで、取得時と変更時にロックバージョンに変更がないか確認し、変更があった場合は例外を発生させる方法です。 ロックするタイミング データ更新時 データを複数同時に取得することができるが、途中で更新されていた場合は、更新できない 仕組み テーブルにlock_versionフィールドを追加する lock_versionが書き換わっていたらActiveRecord::StaleObj
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
