アカウント名:
パスワード:
両データセンターのMySQLデータベースクラスターには一方だけに存在する書き込みが含まれることになるってそんな状態を許すOrchestratorってなに？二重化したつもりが出来てなかったってこと？
別の解説 [atmarkit.co.jp]とそのはてブ [hatena.ne.jp]
説明と改善策にもあるけど、距離があること、データがデカいことの両方が影響するので、リーダー選出は動作として正しかったがリカバリー策として不十分(になっていた)ということかな?
ただ綺麗に同期できればいいけど、そこはNGなとこか
引用対策
GitHubは今回のサービス障害を受け、次のような対策を講じるとしている。地理的に離れた2つのデータセンターにまたがってマスターセレクションを行う設定をやめるサービスステータス表示の方法を改める。「緑」「黄」「赤」だけでなく、サービスの種類に応じ、より詳細な情報を表示するようにするGitHubは障害発生の数週間前から、データセンタ
GitHubは今回のサービス障害を受け、次のような対策を講じるとしている。
地理的に離れた2つのデータセンターにまたがってマスターセレクションを行う設定をやめるサービスステータス表示の方法を改める。「緑」「黄」「赤」だけでなく、サービスの種類に応じ、より詳細な情報を表示するようにするGitHubは障害発生の数週間前から、データセンタ
う～ん、そこは別にNGでもなんでもないのでは。アクティブ・アクティブ構成で片方を異常とみなしてもう一方を主に切り変える事象が発生したに過ぎない。正常に通信出来るようになったからといって再び戻さなくともデータに異常なんて起きない。普通はね。
問題は
米国西部のMySQLが新たなマスターになるまでに複製ができなかった少量のデータが残っていた。
じゃね？切り替えが期待通り行われていなかったことじゃないか、これ。通信が遅いとかって、そもそもRDBのレプリケーションってそんな環境下でも動作するものだと思ってたが。mysqlのレプリケーションってそんなダメダメなんか。いやレプリケーションでなく切り替えタイミングを誤るオーケストラの問題か。
今回は43秒の不断が原因というけれど、障害発生したら正常に切り替えられないってこと示してない、これ？なんか発表が煙に巻くような内容で嫌。
一貫性が保てないなら、プライマリから外れたなら書き込み禁止になるか、ロールバックして不完全な書き込みを無かったことにするか、そうしてほしいかな。
プライマリの選出でネットワーク遅延が問題になるなら、同時に全部落ちた方が復旧は楽そう。サービスの継続性は、他で帳尻合わせて。
遠距離だと同期レプリケーション（全サーバに書き込むまで待つ）なんてやると遅延凄いから非同期レプリケーションだと思うけど。MySQLだと準同期レプリケーションの方かな？
Githubによると500msタイムアウトの準同期レプリケーションですね。この構成ならDCレベルのNetwork partitionが起きたらだめだろうなあ。というかデザインの段階で諦めている様子
> Lossless failover on a complete DC failure is costly and we do not expect it.https://githubengineering.com/mysql-high-availability-at-github/#semi-... [githubengineering.com]
そんな資料あったんですね。ありがとう。GitHub規模だとRDBMSの機能範囲でとどめるべきだと思うし妥当ですね。
#DAO層で同じ処理を複数DBに投げてデータ値のみ同期なんてのはやった事あるのでGitHub規模でやってみたい気はするｗ当時のプロジェクト（SI系）で内容を理解できる人は皆無ｗ
> #DAO層で同じ処理を複数DBに投げてデータ値のみ同期なんてのはやった事あるのでGitHub規模でやってみたい気はするｗ
グローバル分散環境でそれやると、遅すぎて業務にならなくなったりしない？MySQLの準同期レプリケーションだと、スレイブ側に書き込んじゃいかんよな……
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
要するに (スコア:0)
両データセンターのMySQLデータベースクラスターには一方だけに存在する書き込みが含まれることになるってそんな状態を許すOrchestratorってなに？
二重化したつもりが出来てなかったってこと？
Re: (スコア:2, 参考になる)
別の解説 [atmarkit.co.jp]とそのはてブ [hatena.ne.jp]
説明と改善策にもあるけど、距離があること、データがデカいことの両方が影響するので、リーダー選出は動作として正しかったがリカバリー策として不十分(になっていた)ということかな?
ただ綺麗に同期できればいいけど、そこはNGなとこか
引用
対策
Re:要するに (スコア:0)
う～ん、そこは別にNGでもなんでもないのでは。
アクティブ・アクティブ構成で片方を異常とみなしてもう一方を主に切り変える事象が発生したに過ぎない。
正常に通信出来るようになったからといって再び戻さなくともデータに異常なんて起きない。普通はね。
問題は
米国西部のMySQLが新たなマスターになるまでに複製ができなかった少量のデータが残っていた。
じゃね？切り替えが期待通り行われていなかったことじゃないか、これ。
通信が遅いとかって、そもそもRDBのレプリケーションってそんな環境下でも動作するものだと思ってたが。
mysqlのレプリケーションってそんなダメダメなんか。
いやレプリケーションでなく切り替えタイミングを誤るオーケストラの問題か。
今回は43秒の不断が原因というけれど、障害発生したら正常に切り替えられないってこと示してない、これ？
なんか発表が煙に巻くような内容で嫌。
Re:要するに (スコア:2)
一貫性が保てないなら、プライマリから外れたなら書き込み禁止になるか、
ロールバックして不完全な書き込みを無かったことにするか、そうしてほしいかな。
プライマリの選出でネットワーク遅延が問題になるなら、
同時に全部落ちた方が復旧は楽そう。
サービスの継続性は、他で帳尻合わせて。
Re: (スコア:0)
遠距離だと同期レプリケーション（全サーバに書き込むまで待つ）なんてやると遅延凄いから
非同期レプリケーションだと思うけど。
MySQLだと準同期レプリケーションの方かな？
Re:要するに (スコア:3, 参考になる)
Githubによると500msタイムアウトの準同期レプリケーションですね。
この構成ならDCレベルのNetwork partitionが起きたらだめだろうなあ。というかデザインの段階で諦めている様子
> Lossless failover on a complete DC failure is costly and we do not expect it.
https://githubengineering.com/mysql-high-availability-at-github/#semi-... [githubengineering.com]
Re: (スコア:0)
そんな資料あったんですね。ありがとう。
GitHub規模だとRDBMSの機能範囲でとどめるべきだと思うし妥当ですね。
#DAO層で同じ処理を複数DBに投げてデータ値のみ同期なんてのはやった事あるのでGitHub規模でやってみたい気はするｗ
当時のプロジェクト（SI系）で内容を理解できる人は皆無ｗRe:要するに (スコア:2)
> #DAO層で同じ処理を複数DBに投げてデータ値のみ同期なんてのはやった事あるのでGitHub規模でやってみたい気はするｗ
グローバル分散環境でそれやると、遅すぎて業務にならなくなったりしない？
MySQLの準同期レプリケーションだと、スレイブ側に書き込んじゃいかんよな……