「完全復旧までに24時間を要したGitHubの障害は43秒のネットワーク切断がきっかけだった」記事へのコメント

要するに

[Anonymous Coward]

両データセンターのMySQLデータベースクラスターには一方だけに存在する書き込みが含まれることになるってそんな状態を許すOrchestratorってなに？
二重化したつもりが出来てなかったってこと？

Re:

[Anonymous Coward]

別の解説 [atmarkit.co.jp]とそのはてブ [hatena.ne.jp]

説明と改善策にもあるけど、距離があること、データがデカいことの両方が影響するので、リーダー選出は動作として正しかったがリカバリー策として不十分(になっていた)ということかな?

ただ綺麗に同期できればいいけど、そこはNGなとこか

引用
対策

GitHubは今回のサービス障害を受け、次のような対策を講じるとしている。

地理的に離れた2つのデータセンターにまたがってマスターセレクションを行う設定をやめる
サービスステータス表示の方法を改める。「緑」「黄」「赤」だけでなく、サービスの種類に応じ、より詳細な情報を表示するようにする
GitHubは障害発生の数週間前から、データセンタ

Re:

[Anonymous Coward]

う～ん、そこは別にNGでもなんでもないのでは。
アクティブ・アクティブ構成で片方を異常とみなしてもう一方を主に切り変える事象が発生したに過ぎない。
正常に通信出来るようになったからといって再び戻さなくともデータに異常なんて起きない。普通はね。

問題は

米国西部のMySQLが新たなマスターになるまでに複製ができなかった少量のデータが残っていた。

じゃね？切り替えが期待通り行われていなかったことじゃないか、これ。
通信が遅いとかって、そもそもRDBのレプリケーションってそんな環境下でも動作するものだと思ってたが。
mysqlのレプリケーションってそんなダメダメなんか。
いやレプリケーションでなく切り替えタイミングを誤るオーケストラの問題か。

今回は43秒の不断が原因というけれど、障害発生したら正常に切り替えられないってこと示してない、これ？
なんか発表が煙に巻くような内容で嫌。

Re:要するに

[leiqunni (8779)]

一貫性が保てないなら、プライマリから外れたなら書き込み禁止になるか、
ロールバックして不完全な書き込みを無かったことにするか、そうしてほしいかな。

プライマリの選出でネットワーク遅延が問題になるなら、
同時に全部落ちた方が復旧は楽そう。
サービスの継続性は、他で帳尻合わせて。