MySQLロックについて〜基礎編〜 を開催しました！ - ANDPAD Tech Blog
こんにちは！エンジニアの福間（fkm_y）です。 先日、弊社でデータベースの技術顧問をして頂いてる三谷（mita2）さんに開発部向けのMySQLロックのデータベース勉強会を実施したのでそのレポートをお伝えします。 開催背景 弊社では三谷さんによるデータベース勉強会を定期的に開催しています。以前にもロックに関するMySQL勉強会を開催していたのですが、1年半経過しており参加していない開発メンバーのほうが多くなっていたことやプロダクトの成長によりデッドロックなどのロックに起因する問題が目立ち始めていたことから増強版のMySQLロックのデータベース勉強会を開催することになりました。 概要 データベースのロックについて ロックタイムアウトについて デッドロックについて まとめ データベースのロックについて なぜデータベースにロック機構があるのかから知ることが重要です。性能と安全性を両立するためにあ
makopi23のブログ 「外部キー Night」に参加しました
2015/2/13(金) 「外部キー Night」に参加してきました。 connpass http://connpass.com/event/11463/ 場所は千駄ヶ谷（代々木）のピクシブ株式会社さんです。 参加者は60人くらいでしょうか。 ・・・この勉強会のタイトル！そしてピンポイントなテーマｗ 惹きつけられずにはいられない！ そんな私も、SQLアンチパターン読書会で4章「キーレスエントリ」の紹介を担当したということもあり、外部キーには少し思い入れがある一人なのです。 外部キーNightのお供に、書籍「SQLアンチパターン」の４章、「キーレスエントリー」をお一つ、いかがですか～ / SQLアンチパターン読書会 「キーレスエントリー」 に参加しました http://t.co/Z116mYUDyI #sqlap #fk_night — makopi23 (@makopi23) 2015,
トランザクションについて(SELECT FOR UPDATE） | ケーワン・エンタープライズStaffブログ
今回は、SELECT FOR UPDATE時のトランザクションの挙動を確認したいと思います(｀･ω･´)ゞﾋﾞｼｯ!! その前に前回のトランザクションを読んでない人は読んでからの方が理解しやすいと思われます(； ･`д･´) こちらになります。 ・トランザクションについて ・ランザクションについて(その２） ■下準備 同じMySQLサーバーに別々のコンソールからログインして２つ開きます。 （以下、コンソールA、コンソールBとします。） データベースにはMySQLのデフォルトで作られているtestを利用して、 テーブルはuserというテーブルを作って利用します。； テーブル定義は次のものを利用しています。 CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `mail_address` varchar(255) DEFAUL
MySQLでSELECT FOR UPDATEと行ロックの挙動を検証してみた - Continue(s)
どうも、今日も今日とて野毛で飲みながらブログを書いている@0kawaraです。 今日は、普段あまり意識してこなかったMySQLのInnoDBでのロックの振る舞いについて色々実験してみました。（もちろん、きっかは自分がドツボにはまったから） ちゃんと理解するためには「共有・排他的ロックとは」って話や、「行ロックってつまりインデックスレコードロックだよね」などの話とか理解する必要があるんですが、それは github.com をちゃんと一読してもらえれば十分かと思います。 （というか、これが問題なく読めて理解できる人はこの記事読む必要ない….） 以下は上のドキュメント含め関連する記事などを読んで自分でInnoDBの行ロック周りについて、というかSELECT FOR UPDATEについて理解を深めるために手元で実験したことのまとめです。 技術的にちゃんとした理解を深めたい人は最後にまとめた参考サイ
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
Sidekiq による非同期処理を Redis の分散ロックで排他制御した話 - peroli Developer's Blog
MERY のサーバーサイドエンジニアの @saidie です。 MERY では画像アップロードや記事投稿による検索インデックス作成などなど、ユーザからのリクエスト起因で起こる時間のかかる処理の多くを非同期に行うことでレスポンスタイムの向上に努めています。また、重複した非同期処理が並行して走ることによる スループット の劣化を分散ロックを用いた 排他制御 で緩和する取り組みなども行っています。 MERY は Ruby on Rails を用いて開発されており、非同期処理には Ruby 製の フレームワーク である Sidekiq を採用しています。この記事では Sidekiq と Redis による分散ロックを使って、同一の非同期処理が(あまり)重複しないような MERY の非同期処理システムについてご紹介します。 Sidekiq Sidekiq はクライアントサー バモ デルのマルチスレッ
複数プロセス間での排他制御 - Qiita
require 'timeout' class AccessDenied < StandardError; end def lock(&block) # 10秒以内に終わらない場合はAccessDenied例外が発生 Timeout::timeout(10) do open(File.join(Dir.tmpdir, 'my-application.lock'), 'w') do |f| begin f.flock(File::LOCK_EX) block.call ensure f.flock(File::LOCK_UN) end end end rescue Exception => ex raise AccessDenied.new('timeout') end Register as a new user and use Qiita more conveniently You ge
gachinko.org - このウェブサイトは販売用です！ - gachinko リソースおよび情報
このウェブサイトは販売用です！ gachinko.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、gachinko.orgが全てとなります。あなたがお探しの内容が見つかることを願っています！
楽観的ロックと悲観的ロックについて。 Kaname's hackday
楽観的ロック、悲観的ロック。 更新時のロック手法として使われているもの。 悲観的ロックの場合。 悲観的ロックは「一つのリソースを同時に更新することが頻繁にありうる場合」に利用する。 具体的には、更新のための参照をした時点でロックをかける（SELECT FOR UPDATEとか） ロック中は別処理では更新できないため、整合性が保たれる。 ただし、処理件数が多いと、その分ロックの時間も増えるため注意も必要。 楽観的ロックの場合。 楽観的ロックは「一つのリソースを同時に更新することはほとんどない場合」に利用する。 具体的には、レコードに更新日時などを持たせておき、 １．参照時に更新日時もを取得 ２．更新時の条件句に更新日時を指定し、処理中に更新がないことを確認して更新実施。 悲観的ロックよりも簡単にロックができるが、名前のとおり安全性は悲観的のほうが高い。 楽観的とか悲観的とかなんか嫌だな。つっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データの同時更新を防ぐための排他制御