タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
データベースのロックの基礎からデッドロックまで
データベースのロックについて、資料を読んだり実際に試してみたので、学んだことを整理してみようと思います。はじめにロックについての基本的な知識を整理して、最終的にはデッドロックとその対策について説明します。 使用したソフトウェアのバージョン MySQL 8.0.31 この記事ではMySQLを使用しています。その他のデータベースについては、基本的な部分は共通していると思いますが、異なる点があることをご了承ください。 ロックとは何か（概要） ロックはデータの更新を正しく行うための仕組みの一つで、あるデータに対する更新処理を制御するためのものです。ここで、データを正しく更新するとはどういうことかを説明するために、口座への振込を例に考えてみます。 例えば、口座Aから口座Bに1万円の振込を行うとします。このとき、口座Aの出金処理と口座Bの入金処理は、必ず両方が成功しなければなりません。このための仕組み
はじめに この記事は実際の業務で発生した MySQL のデッドロックとそのいくつかの回避方法や対応方法を（テーマは変えて）手元で実行できるコードを用いて解説する記事です。具体的には「トランザクション張っておけば大丈夫」と思ってませんか？ バグの温床になる、よくある実装パターンの記事で紹介されている「1on1 チャットサービス」で紹介されているデッドロックとデータベースレイヤでは同じ状況だったのですが、記事で紹介されている方法とは別の方法でデッドロックを回避する必要があったため、同じ状況に遭遇した人の助けになればという思いで記事を書きました。また、こちらの記事が無ければ私自身も現象を理解するのにもっと苦労したと思うので、この場を借りてお礼申し上げます！ 出金サービス履歴登録サービスを例に考える コードと説明が https://github.com/shuntagami/withdrawal_
状態機械を合成してデッドロックを検出できる Go 言語パッケージを作ってみました - チェシャ猫の消滅定理
はじめに マルチスレッドで動作するプログラムの設計は難しい問題です。個々のスレッドの動作は単純に見えても、複数が並行して動作する場合の動作は組み合わせ論的に複雑になります。また、タイミングに依存する不具合は狙って再現することが難しく、通常の単体テストによる検出にも限界があります。 そんなとき、有効な手法がモデル検査です。システムの取りうる状態をあらかじめ網羅的に探索することで、「実際に動作させた際にごく低い確率で踏むバグ」であっても、動作させることなく設計段階で発見することが可能になります。 ところでちょうど先日、デッドロック発見器を自作するハンズオンに参加する機会がありました。内容は非常にシンプルなモデル検査器を実装するというもので、せっかくなのでそのときの成果物を Go のパッケージとしてまとめたものを以下に公開しました。 github.com 以下、このパッケージで何ができるのかを具
リンク Wikipedia デッドロック デッドロック (英: deadlock) とは、特に計算機科学において、2つ以上のスレッドあるいはプロセスなどの処理単位が互いの処理終了を待ち、結果としてどの処理も先に進めなくなってしまうことを言う。 また、合弁契約書などにおいてパートナーと利害関係がぶつかるような問題が生じた場合の解決方法を定めた条項を「デッドロック条項（Deadlock Clause）」と言う。 英語ではもともと行き詰まりの意味である。 古い文献では、デッドロックのことをチェス用語と同様のステイルメイトと呼称して説明をしている場合があ 42 users 1
はじめに2023年3月2日午後10時ごろ、驚愕のニュースが飛び込んできました。単線区間である川越線指扇～南古谷駅間で、上下列車が鉢合わせしたというのです。現地からは南古谷駅の場内信号機をはさんで向かい合わせに停車している上下列車の画像や映像が飛び込んできて、大変な話題になりました。 本記事では、なぜこのような事態となったのか解説するとともに、事象発生当初からインターネット上で広がり、現在も多くの投稿や動画で広がり続けている「異線進入説」についても言及します。なお、本記事では極力確認された事実や労組資料の記述をもとに解説しており、やむを得ず補足等のために作者の勝手な想像や推測を述べる場合はそれと分かるように記載しています。 単線区間の運転保安についてそもそも、単線区間に上下列車が同時に入線しないよう、どのような対策が取られているのでしょうか？ 川越線の当該区間は「単線自動閉そく式」という閉そ
こんにちは。アルダグラムでエンジニアしている森下霞です。 弊社では、MySQL のデータベース と Ruby on Rails を使用しています。 先日、モニタリングで UPDATE IN SELECT のクエリでデッドロックの発生に気づき、調査し、修正ができたため、デッドロックのデバッグ方法と解決策を紹介したいと思います。 背景 今回の問題は、アニメサービスを例に使って説明します。アニメは以下のテーブルで保存します。 CREATE TABLE anime ( id INT PRIMARY KEY NOT NULL AUTO_INCREMENT, title VARCHAR(255) NOT NULL, genre VARCHAR(100) NOT NULL, sort_order INT NOT NULL DEFAULT 0 ); CREATE INDEX index_anime_on_
近所にできた信号のない環状交差点『ラウンドアバウト』を見てきたが踏切と隣接しているため混雑したらデッドロックが発生しそう「どうしてこうなった？」
B作 @Btoretsukuru 近所にできたラウンドアバウト(信号のない環状交差点)を見てきました。踏切と隣接しています。踏切待ちの車列が交差点内まで伸び、混雑時にはデッドロックしそうです。20秒あたりから電車が来ます。 ※6倍速 pic.twitter.com/0qFkIqcHMD 2023-02-04 18:00:22
Mercari Advent Calendar 2017 の18日目です。 こんにちは。メルカリJPのサーバーサイドエンジニアの@Hirakuです。最近はメルカリNOWの立ち上げに関わっておりGoとPHPを行ったり来たりしています。 今回はネタとしては地味ですが、2017年に遭遇した、MySQLのデッドロックの話をしようと思います。 これまでも何度か話されている通り、メルカリのコア部分は今でもPHP + MySQLで構成されており、複雑なトランザクションを含む処理が各所に存在しています。そのため、意図せずしてデッドロックを作ってしまうことがあり、場合によっては重大な問題につながります。 今年は本当にデッドロックに関するトラブルに多く遭遇し、すっかり「デッドロック絶対に許さないおじさん」みたいになっていました。 事例1)出品者と購入者 デッドロックと言われてもピンと来ない方もいらっしゃるでし
デッドロック発見器を作って学ぶマルチスレッドプログラミング ★共有変数編★ (2019/10/19 12:30〜)
キャンセル・参加費用の払い戻しについて主催者からの説明: お申込み後のキャンセルはできません．セミナーについての説明をよくお読みいただき，十分ご検討の上お申し込みください．セミナー当日に不参加であったとしても参加費用は返却されません． セミナーの内容 参加者が自分の好きなプログラミング言語でデッドロック発見器を作り，それを使ってマルチスレッドプログラミングを学ぶハンズオンセミナーです． 作っていただくデッドロック発見器はマルチスレッドプログラムの動き全体を状態遷移図として可視化し，その過程でデッドロック状態を発見するというものです．以下にデッドロック発見器の出力例を示しました． 水色の状態は初期状態で，赤い状態がデッドロック状態です．デッドロック状態からは遷移が1つも出ていないので，この状態に達するとプログラムは停止してしまうことがわかります．動作し続けるパスもあり，必ず再現するわけではな
はじめに タイトル通り、MySQL5.x系だとデッドロックになるんだけど、 MySQL8.0だとロック機構が変わってデッドロックにならないよ という組み合わせのお話。 僕はこの話をどっかで見た記憶が無かった（忘れた？）ので 教えてもらったとき結構驚いたんだけど、GA（8.0.11）では 既にこれがあったんで、まあ古い話なんだと思うし、 何をイマサラなのかもしれないので、ご存じの方は笑ってやってください。 ちなみに、REPEATABLE READでのお話なので、 READ COMMITTEDの場合は5系でもデッドロックにはなりまへん。 検証 今回やるのはこういうこと 最初のトランザクション（以下Tx1）でトランザクション開始、共有（S）ロックで全レコードを参照。 別のトランザクション（以下Tx2）でトランザクション開始、INSERTによる排他（X）ロック Tx1でINSERTによる排他（X）
SELECT ... FOR UPDATEとUPDATEでデッドロックが出る人へ - 41から始めました
はじめに 最近は主に花粉症に悩まされており、目が痒くてたまりません。 また、娘の生活がガラッと変わったせいで、毎日貧乏ヒマ無しです。 そんな中、たまたま早起きできたので奮起して久々に書いてみました。 問題が起きる環境 MySQL8.0.17以前 transaction_isolationがREAD-COMMITTED WHERE句の条件が一意ではない。（フルテーブルスキャンだと発生しやすくなる） キーの値がたすきがけになってる トランザクション開始＋SELECT ...FOR UPDATE→UPDATEのようにロックを取っている 先に実行されたトランザクションが、たすきがけになっているキー値の若い（っていうのかな？）方のロックを取る 何が起きるかと言うと、SELECT ...FOR UPDATEのWHERE句で抽出した行に対してロックを取ってるのに、 後から別セッションで実行されたSELE
MySQLのデッドロック対処 おまけでギャップロック
タグ 保湿CentOS7linux 入門VagrantVirtualBoxAnsibleLarabelClamAVRTX1210atomSWX2200RTX1100MySQLPlesk12おりょりょんNFSPostfixゆるいハッキング大会windows10SSHFSGitWindows AzureVisual Studio 2017RabbitMQMVCAsteriskベンチマークBINDDrupalH2OMastodonGeoIPApacheAWS S3AWS CLIFuelPHPVuls基板修理ゆるいハッキングYAMAHA RTXCybozu Office10ALBELBロードバランサsshバックアップ負荷分散AWS EBSRDPDNSElasticsearchLogstashKibanaLaravelKubernetes仕事猫現場猫SWX2300RTX1200AWS EFSPerc
楽天モバイルは1月17日、2019年12月10日に発生したMNOサービスにおける通信障害の詳細な影響範囲と原因と、それを受けた対応策を公表した。 障害の発生日時と影響範囲 今回の障害は、2019年12月10日午前8時34分に発生し、午前11時15分に回復した。障害の影響を受けた回線数は以下の通り。 音声通話：147回線 データ通信：約1000回線 障害の原因 同社の「西日本Central Data Center」に設置している課金制御機器において、データベース処理の不具合に起因するデッドロック（※）が発生したことが障害の発生原因だという。また、同社のネットワークの特徴でもある「仮想化技術」の導入は原因ではないとのことだ。 （※）デッドロック：2つ以上のソフトウェアが互いの処理完了を待ち合い、結果として処理が進まなくなる状態 再発防止策 今回の障害を受けて、同社では原因となった機器のソフトウ
Photo by Kat Stokes on Unsplashこんにちは。仮想通貨の損益計算ツール「Gtax」、仮想通貨の確定申告サポート「Guaridan」を提供するAerial Partnersのエンジニアインターンの伊藤です。 今回は、Aerial Partnersのチームが実際にどのような技術を用いてブロックチェーンの社会実装を進めているかをお伝えするために、僕が最近取り組んでいた、大量のレコードを捌くDB処理の実装において直面した問題についてお話させていただきます。 InnoDBのロックアーキテクチャはややこしい！例題です。以下のような操作において、一体どのような原因でデッドロックが発生してしまうのでしょうか。 テーブル内容 > SHOW COLUMNS FROM t1;+-------+---------+------+-----+---------+-------+| Fie
『デッドロック』とは。。。 今回、ある人との話し中に 『デッドロック』という言葉が出たのですが、 今回は、 『交渉などの行き詰まり。 うまく話がまとまらなかった』という意味で、 『デッドロック』とあの方は言ったんだろうな。 初耳だったので、 『え？デッドロック？？？』と 一瞬脳がストップしてしまいましたよ(・_・;) それとも、皆、 当たり前のように言っている言葉だったのでしょうか？？？？ ASUS エイスース E203MA-4000W ノートパソコン パールホワイト [11.6型 /intel Celeron /eMMC：64GB /メモリ：4GB /2018年6月モデル][11.6インチ E203MA4000W] ------------------------------------------------------------- ■韓国語単語 피시：パソコン、PC 아이패드：ip
Aurora(MySQL互換)で、外部キーが絡んだINSERT/UPDATEによるデッドロックが検知されない問題 - Qiita
各環境は上記の状態だったため Aurora独自の何かがあるのでは？と思い検証をしてみることに デッドロック発生後の対処 デッドロック発生時、mysqlコマンドでDBにつないで 原因となるクエリをKILLしてみたが解決せず リードレプリカをフェイルオーバーさせることで対応した 検証開始 デッドロックが起きていたテーブル群 offers offer_child_1 offer_child_2 documents document_offer_child_2 ※わかりやすいようにテーブル名は実際とは変えています スキーマ CREATE TABLE offers ( id bigint(8) AUTO_INCREMENT PRIMARY KEY, title text ); CREATE TABLE offer_child_1 ( id bigint(8) AUTO_INCREMENT PRIMA
代官山 蔦屋書店にて開催された、『だから僕たちは、組織を変えていける』著者・斉藤徹氏と『DX CX SX』著者・八子知礼氏による対談の模様を公開します。テーマは「『愛のある組織変革』は実現可能か？ 〜『人間性』と『デジタル化』を両立する組織トランスフォーメーション〜」。DX推進をする上での問題点を「人」の視点でひもといていきます。本記事では、八子氏の講演パートをお届けします。 旧知の友が語る「愛のある組織変革は実現可能か」 八子知礼氏（以下、八子）：みなさん、こんばんは。斉藤さん、ご無沙汰しております。 斉藤徹氏（以下、斉藤）：そうなんです、かなり久しぶりですよね。リアルで会うのはどのくらいぶりですか？ 八子：10年……そんなことないですかね。8年？ 相当久しぶりですよね。かれこれお付き合いは15年近くになりますけどね。 斉藤：『ソーシャルシフト』の頃ですよね。 八子：その時よりももうちょ
楽天モバイルは2020年1月17日、自営回線で2019年12月10日に生じた通信障害の原因を公表した。課金を制御する機器が内蔵するデータベース管理システム（DBMS）において、複数の処理が互いの終了を待ち合う、いわゆるデッドロックが発生して機能が停止した。同社は同日付で、再発防止策などを含む報告書を総務省に提出した。 システム障害は12月10日午前8時34分から午前11時15分まで約2時間半続いた。この間、約1000回線のデータ通信と147回線の音声通話が利用できないかつながりにくい状況となった。同社の自営回線は現在「無料サポータープログラム」として5000人限定で試験サービスを展開している。 原因となったDBMSはフィンランド・ノキア（Nokia）製の課金制御機器に内蔵されていた。同機器は同社の西日本セントラルデータセンター内にあった。 課金制御機器は音声通話やデータ通信について、通信単
どうしたの？スタディストwebアプリグループでは、毎朝「エラーを見る会」というものを実施しています。「エラーを見る会」は、日々発生しているサーバーエラーを把握し、顧客影響(被害)を最小限にする目的の元、webアプリグループメンバーで行われている会です。そこでは、サーバー上で出たエラーを見て、「このエラーは早めになおしたいね」とか「このエラーはバックログに積んであとでなおそう」といった話し合いを行っています。 「エラーを見る会」で、以前より「ActiveRecord::Deadlocked」の発生を確認していましたが、詳細な原因を特定できていませんでした。そこで原因特定のために、ログ出力を行った事例について今回ご紹介します。 デッドロック情報を出力する弊社では、Amazon RDS Aurora MySQLを使用しております。 原因を調べるにあたり、ストレージエンジン(InnoDB)に関する
楽天モバイルは1月17日、同社が試験的に提供している携帯キャリア（MNO）サービス「無料サポータープログラム」で2019年12月に発生した通信障害について、契約回線の約2割で正常な利用ができない状況だったと発表した。 通信障害は12月10日午前8時30分ごろから11時15分ごろまで約3時間続いた。報告書によると、音声通話がつながりにくかったのは147回線、データ通信が不安定になったのは約1000回線に上るという。無料サポータープログラムは抽選で選んだ5000人に対して提供しているため、全体の約2割の回線に影響が及んだことになる。 原因について同社は、ユーザーの通信状況から通信料金を割り出す課金制御機器で、データベース処理に「デッドロック」が発生し、処理が停止してしまったとしている。 総務省はこの障害を受け、12月13日に同社に行政指導を行い、安定的で円滑なサービスの提供を求めていた。楽天モ
「あれ? どうして列車が動けなくなったのだろう」 JR東日本長野支社のCTC(列車集中制御装置)センターで列車の運転を監督する運転指令員はこうつぶやいたに違いない。このとき、列車の運転状況を示すCTC表示盤では、単線区間の篠ノ井線に設けられた行き違い場所である桑ノ原信号場(姨捨-稲荷山間に設けられた信号場。なお、篠ノ井線の正式な起点は篠ノ井駅、終点は塩尻駅だが、本項では起点を塩尻駅、終点を篠ノ井駅として扱う)付近で3本の列車が立ち往生していると表示し、列車の進路を自動的に設定するPRC(自動進路制御装置)が3本の列車に対して進路を構成できないと警報を発してきたはずだからだ。 摩訶不思議なトラブルは2012年7月2日の午前9時ごろに発生した。翌7月3日付けの読売新聞の「列車ダイヤ作成ミス…立ち往生、単線に3本進入」(※リンク切れの際はご容赦いただきたい)という記事がわかりやすいので、記事をも
この記事は個人ブログと同じ内容です zenn.dev はじめに 業務でデッドロックが発生し、原因がわからずに時間を費やしてしまいました。そこで、今回はその原因と解決方法について調査した結果を備忘録としてまとめたいと思います。 状況 実際のテーブルやアプリケーションコードを直接お見せするわけにはいかないので、簡易テーブルを用意して、SQLにて当時の状況を再現してみたいと思います。 テーブル内容 CREATE TABLE users ( id INTEGER PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255) ); CREATE TABLE rooms ( id INTEGER PRIMARY KEY AUTO_INCREMENT ); CREATE TABLE entries ( id INTEGER PRIMARY KEY AUTO_INCREMEN
2023年3月11日2023年5月7日 所詮はセルフ事故調査委員会しぐさではございますが、先日発生した「川越線デッドロック事件」について考察してみたいと思います。 あらまし 事件は2023年3月2日、川越線の指扇駅-南古谷駅間で発生した。当日は強風の影響で川越線及び直通する埼京線では遅れや運休が発生していた。 当該の下り2081S（新木場発通勤快速川越行き。所定指扇21:43発、南古谷21:50発。E233系7000番台ハエ134編成）及び上り2188K（川越発各駅停車新木場行き。所定南古谷21:50発、指扇21:55発。東京臨海高速鉄道70-000形Z3編成）は所定では南古谷駅で交換するダイヤとなっている。両列車は（おそらく）ほぼ遅延なく、それぞれ指扇駅、南古谷駅に到着したとみられる。 その後、指扇駅下り出発信号機及び南古谷駅上り第一出発信号機が進行現示となった。そのため2081S及
外部キー制約でデッドロックに引っかかった話
今回は仕事で直面したデッドロックのケースについて話したいと思います。 今回ハマったケース 今回ハマったケースは、複数プロダクトが共有するデータベースにあるデータを単体プロダクト専用のデータベースに持ち帰る開発を行っていたときでした。かなり簡略化しておりますが現状と分離後の理想型は下記の通りです。 現状 担当プロダクトと別プロダクトは同じ従業員データを参照している 従業員データの中には、担当プロダクト専用のカラムもあれば、別プロダクト専用の項目もある マイクロサービスがもつマスタ従業員データと旧従業員データがそれぞれ持つ名前カラムは同期している 理想系 担当プロダクトは新しい専用の従業員データをもち、専用のカラムはそのテーブルにもつ マイクロサービスがもつマスタ従業員データと各プロダクトの従業員データの名前カラムは同期させる この対応を段階的に進めている途中で、 担当プロダクトによる旧従業員
MySQL 外部キー制約のデッドロック | 優技録
外部キー(FOREIGN KEY)制約を利用している場合、 子テーブルに追加、更新や削除を行う時は、必ず親テーブルの対象のidに対して排他ロックを行ってから、更新や削除、追加を行う。 親テーブルの該当idに対して排他ロックを取る 子テーブルの該当行に対して追加、更新、削除等を行う これならロックは起こらない。 外部キー制約を利用していると、 子テーブルにINSERT, UPDATE, DELETEを行うと親に共有ロックがかかる 外部キー制約を利用している子テーブルにINSERT, UPDATE, DELETEを行う場合は、 排他ロック「FOR UPDATE」をかけてからINSERT, UPDATE, DELETEを行う 共有ロック→排他ロックはデッドロックが起こる原因になる。外部キー制約を利用しているテーブルをSELECT以外で操作する場合は、必ず排他ロックを行ってから、更新や削除、追加を
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLで発生し得る思わぬデッドロックと対応方法
お互い『邪魔だニャー』と言って譲り合おうとしない配膳猫たちがいた「デッドロックだ！」「難しいんよねこれの解決」
【真相】川越線デッドロックの原因と「異線進入」騒動の顛末
UPDATE IN SELECT によるデッドロックが発生しなくなった件
デッドロックおじさん戦記 | メルカリエンジニアリング
MySQL5.xではデッドロックだけど8.0では死なないよ - 41から始めました
楽天モバイルのMNOサービス障害、原因は課金制御機器の「デッドロック」
「Firefox 85.0.2」がリリース ～起動時にデッドロックが発生し、フリーズする問題が発覚／ここ1週間で2回目のアップデート
MySQL InnoDBのギャップロックによるデッドロックを解明する
『デッドロック』って何？？？ - あきっぽいけど、なにかやりたい。。。
システムが古い、仕事が属人化、ITリテラシーが低い… DX推進を止める「魔のデッドロック」が生まれる背景
楽天モバイルが2019年12月通信障害の原因公表、DBMSの潜在バグでデッドロックに
Amazon RDS Aurora MySQLでデッドロックのログを出力して読む方法
12月の楽天モバイル通信障害、全回線の2割に影響 原因は「デッドロック」
2012年7月4日 篠ノ井線で発生したデッドロックについて | 鉄道ジャーナリスト 梅原 淳
【MySQL(InnoDB)】ギャップロックによるデッドロックの調査 - ROXX開発者ブログ
川越線デッドロック事件について（5月7日追記） | みちのくラボ
musasabilife.hatenablog.com
anond.hatelabo.jp
domi.blog.jp
advisors-freee.jp
daily-gadget.net
www.google.com