レプリケーションが追いつかないときに試すこと - Hatak::Techlog

“MySQL Casual Advent Calendar 2011” 7 日目を担当させていただく、hatak (@hisashi) です。 普段はモバイルゲームのインフラをメインにみているのですが、今回はそんな業務で経験したことを基に記事を書かせていただきます。 カジュアルすぎる内容かもしれませんが、お付き合いいただければと思います。 MySQL のレプリケーション MySQL のレプリケーションは、安定稼働やバックアップ、負荷分散などの目的に利用できる優れた機能です。 bin-log (バイナリログ) を利用して Master サーバから Slave サーバに更新を伝播させ、データの複製を行います。Slave サーバでは、2 つのスレッドが動作しています。 IO_THREAD – Master から送られてきたデータを受け取り、relay-log (リレーログ) として書き出す SQ

[kamipo]

innodb_flush_log_at_trx_commitオンラインで変更できるの知らんかった…

[Mint0A0yama]

“Master の更新をブロックする” ”Slave のパフォーマンスを調整する”

[micdonalds]

レプリケーション遅延の確認について

[windscape]

"レプリケーションで送られてくるクエリの流量が多すぎる場合、つまり Master の更新が激しすぎて追いつかないケースでは、そもそも Master での更新を止めてしまうという方法があります。"

[barlog]

7 replication

[editnuki]

メモメモ

[dekatotoro]

レプリケーションが追いつかないときに試すこと

[kitokitoki]

レプ遅延

[hiroyukim]

明日は@kamipoさん

[kazeburo]

innodb_flush_log_at_trx_commit ってオンラインで変更できたんだ