mysqlのHAがらみのトラブルの思い出 - smallpalace's blog
いーつのことーだかー思い出してごーらん、あんなことーそんなことーあーったでしょー。 というわけでこんにちは。smallpalaceです。 ちょっと前にテクニカルセミナー的な機会があって思い出してくれということになり思い出したのでかける範囲で書いときます。 mysqlの運用時のトラブルまとめ。HAがらみのところほか順不同です。 ・高負荷後の「max_connect_errors」がらみでホストによっては拒否されてアクセスできなかったりなど。対策としては、flush hosts;とmax_connect_errors=999999999でエラーカウント無効になるようです。 ・主にクラウド上でI/OスパイクでF/Oしやすい。（I/O共有なのでしょうがないです）ベンダによってはDBだけ物理で提供（納期はかかる）というのもメニューにあったりして人気があるようです。予算が許せばioDriveとかステキ
Automating master failover is possible but needs care
I was asked from a few people about my opinion of the Github's recent service outage. As a creator of MHA, I have lots of MySQL failover experiences. Here are my points about failover design. Most of them duplicate with Robert's points. - "Too Many Connections" is not a reason to start automated failover - Do not repeat failover I know some unsuccessful failover stories that "1. failover happens b
最強のMySQL HA化手法 - Semi-Synchronous Replication
MySQL 6.0で搭載される予定の機能の一つに、Semi-Synchronous Replicationというものがある。コイツを使うととんでもなく凄いHA化ができるので、今日はその方法を紹介しよう。 まずはSemi-Synchronous Replicationの機能説明から。そもそもSemi-Synchrounousってナニ？どうして完全な同期でもなく非同期でもなくSemi-Synchronousなの？という疑問をまずは解消したいと思う。さっそく次の図を見て欲しい。 これはSemi-Synchronous Replicationの動作を図で表したものである。図だけではなんだかよく分からないと思うので、以下に各ステップの詳細を説明する。 アプリケーション（クライアント）からトランザクションをCOMMIT要求を出す。 バイナリログを更新する。 ストレージエンジン（テーブル）を更新する。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社TAP
株式会社TAP
