■MySQLデッドロック関連

 

DBの初期設計がむちゃくちゃなシステムを後から修正をするのは難しい。トランザクションする場合のテーブルロックの順番を意識して開発していないとどんどん増えるよ！

○移行の注意

ストレージエンジンをMyISAMからInnoDBへ切り替える際の注意
http://gihyo.jp/dev/clip/01/groonga/0006?page=3

 

○開発の上で

 

【MySQL】最低限の??デッドロック対策メモ

• 複数テーブルへの更新処理は処理するテーブルの順番をそろえること

• ロックをかける(かかる可能性がある)場合は、検索結果が0件となるwhereは避けること

• 外部キーが貼ってあるレコードをinsertすると親レコードにもロックがかかることを意識すること

http://kimagureneet.hatenablog.com/entry/2016/05/10/025820
【MySQL】外部キー制約とロックとデッドロックについて
http://kimagureneet.hatenablog.com/entry/2016/03/19/110336
トランザクション分離レベルを理解するために実際に試してみる
http://sawara.me/mysql/1341/

 

不整合が起きてはならない場合、トランザクションはシリアライザブル
https://blog.ohgaki.net/use-serializable-transaction-isolation-level

 

世界の何処かで MySQL（InnoDB）の REPEATABLE READ に嵌る人を1人でも減らすために
>今の MySQL はデフォルトで REPEATABLE READ という設定になっている

>トランザクション開始後の最初の読み取りによってスナップショットが確立されるため、同一トランザクション内では他のトランザクションによる更新の影響を受けずに、最初に確立したスナップショットのデータを参照することができる（一貫性読み取り）

>「SELECT ~ FOR UPDATE を用いた locking read」と「non-locking read」で結果が異なる（完全な一貫性読み取りではない）

>後者についてもう少し詳細に説明すると、以下のようになります。

「SELECT ~ FOR UPDATE を用いた locking read」は、一貫性読み取り とは違い、スナップショットが確立されていたとしても、他のトランザクションによる更新の影響を受ける（ファントムリード）
http://techblog.kayac.com/repeatable_read.html

 

 

○他

 

InnoDB のロック待ち過多でデッドロックするやつ
>InnoDB は同じロックを待つクライアントが 200 を超えるとデッドロック扱いになる、というやつがある。
>同じロックを待つクライアント数が一定ライン(ソース上の定数LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK:200固定)を超えると、
>デッドロック扱いにして強制的にロールバックさせる、というInnoDBの実装に起因します。
http://takatoshiono.hatenablog.com/entry/2015/02/21/014218

 

MySQLのInnoDBストレージエンジンを使用したテーブルで意図的にデッドロックを発生させる
http://linuxserver.jp/%E3%82%B5%E3%83%BC%E3%83%90%E6%A7%8B%E7%AF%89/db/mysql/%E3%83%87%E3%83%83%E3%83%89%E3%83%AD%E3%83%83%E3%82%AF%E3%83%86%E3%82%B9%E3%83%88
MySQLのInnoDBでのデッドロック
http://alpha.mixi.co.jp/entry/2007/10681/
[MySQL]ロックタイムアウト時間を変更する
(ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction)
http://nanoappli.com/blog/archives/6395
ロック待ちでハマる前に知りたかったMySQL InnoDBの行ロックとテーブルロックの挙動
http://blog.katty.in/3082
MySQL (InnoDB) でデッドロック検知される条件について
http://qa.atmarkit.co.jp/q/2361

 

MySQLのサブクエリは危険？――深まる謎
>MySQLでネストするクエリ（サブクエリ）は絶対に使ってはいけません。
http://el.jibun.atmarkit.co.jp/garyotensei/2012/07/mysql-465d.html
開発スピードアクセル全開ぶっちぎり！日本よ、これがMySQL 5.6だッ！！
http://nippondanji.blogspot.jp/2012/10/mysql-56.html

 

 

■Q4M

CentOS6にQ4Mを入れて、Q4Mを使って他サーバPHPプログラムとの連携
http://qiita.com/yoshiaki_0245/items/3a00fcc3bc9d1cd99251

 

 

■技評スペシャル

インフラエンジニア情報局
http://gihyo.jp/ad/01/infra

 

大規模ソーシャルサービス mixiを支える技術
http://gihyo.jp/ad/01/mixi_infra

 

帰ってきた大規模Webサービスの裏側
http://gihyo.jp/admin/serial/01/mixi_wdb
人気ソーシャルアプリを支えるグループスのインフラ環境／開発現場に迫る!!
http://gihyo.jp/ad/01/gloops
エンジニアパワーアップ講座 ～システム基盤を活用するための基礎知識～
http://gihyo.jp/ad/01/power_up

 

■メモ　Webサービスの規模とサーバ台数を調べてみた

Webサービスの規模とサーバ台数を調べてみた
http://takemikami.com/archives/1302/

『facebook』　（2008年4月頃）
アクティブユーザ：7,000万人
サーバ台数：13,000台程度
・Webサーバ台数…1万台
・memcachedサーバ台数…805台
・MySQLサーバ台数…1,800台
情報ソース：
・Facebookのデータセンターに見るMySQL活用事例 – MySQLカンファレンス | マイナビニュース (http://news.mynavi.jp/articles/2008/04/28/mysql/001.html)
→『アクティブユーザー数…7,000万人』『Webサーバ台数…1万台、memcachedサーバ台数…805台、MySQLサーバ台数…1,800台(マスター/スレーブ各900台ずつ)』と記載がある

『mixi』　（2005年9月頃）
月間PV数：20億PV
サーバ台数：150台
情報ソース：
・検索エンジンやブログ、ＳＮＳを管理している物は何？ | livedoor knowledge (http://knowledge.livedoor.com/19291)
→『大分古い情報になりますが、mixiの場合、2005年9月時点で約150台のサーバで運用されていたようです。』という記載があります
・mixiが2000万ユーザー突破– 6年間の軌跡を振り返る(http://japan.cnet.com/news/media/20412079/)
→mixiの会員数増加グラフでみると2005年9月は20億PV程度に読めます

『decolog』　（2010年12月頃）
月間PV数：60億PV
サーバ台数：400台
情報ソース：
・ZABBIX勉強会でDECOLOGのシステム監視運用のお話をしました。 | DECOLOG TECH BLOG (http://tech.dclog.jp/2010/12/zabbixdecolog.html)
→『60億PVとか400台とかいっても、上を見れば上がある。』という記載があります

『CockPad』　（2009年2月頃）
月間PV数：2.8億PV
サーバ台数：80台
・apache 8台 (ロードバランス用)
・アプリケーションサーバー 52台
・slave dbサーバー 18台
・その他 imagedbサーバー、master dbサーバーなどが複数
情報ソース：
・クックパッドの裏側を見てきました | RED-MOUNT.COM (http://www.red-mount.com/blogs/show/ruby_on_rails_cookpad)
→『月間PV約2.8億というのは、Railsサイト中世界3位なのだとか。』『apache 8台 (ロードバランス用)、アプリケーションサーバー 52台、slave dbサーバー 18台、その他 imagedbサーバー、master dbサーバーなどが複数、※VM上にサーバーを立ち上げているので、実際の数は30台程度？』と記載があります。

『2ch』　（2006年10月頃）
月間PV数：50億PV
サーバ台数：60台
情報ソース：
・はてなのサーバ台数は2chの5倍 : ひろゆき＠オープンSNS (http://hiro.asks.jp/12250.html)
→『う～ん、2chのサーバって60台ぐらいだと思うのですが、 』という記載があります。
・2010年の２ちゃんねるのページビュー (http://d.hatena.ne.jp/longlow/20110101/p1)
→『2005年3月15日から2010年12月31日までのPVの動向及び各種の数字』から2006年10月は『4,778,547,113』という値が読めます

『食べログ』　（2010年2月頃）
月間PV数：3億PV
サーバ台数：50台
情報ソース：
・メーカーの「信者」は本当にいるのか？成長著しい「価格.com」を運営するカカクコム社でいろいろ聞いてきた (http://gigazine.net/news/20100228_kakaku_com/)
→『2007年4月当時のサーバーの台数はグループ全体で200台くらいでしたが、今は355台になりました。アクセス数や他のドメインでのサービスが増えるに従って増えています。355台のうち価格.comが170台で、食べログが50台となっていますね。』と記載があります。
・広告掲載 食べログ
→『食べログ アクセス数 （2010年5月31日現在）　総ページビュー：約3億1,529万PV／月』と記載があります。

『4travel』　（2007年7月頃）
会員数：4万人
サーバ台数：40台
情報ソース：
・フォートラベルのサーバ台数の推移とこれから (http://blog.livedoor.jp/nyamaji/archives/51283965.html)
→『2007/07 40台(+18)←いまこの辺』と記述があります。
・フォートラベル – サービス概要 – 利用者数 (http://4travel.jp/aboutus/service/user/)
→『フォートラベルの利用者数・投稿件数の推移』のグラフから2007年7月時点のユーザ数が約4万人と読めます。