アカウント名:
パスワード:
GitHubのその辺って複数DBに対応してるんかね？確かにSQLServerもLinux対応したしなぁ。どっちかというとアプリ書き換えるよりデータ移行のほうが楽な気がする。ってことでTFSに置き換えられたら笑うぞw(因みにTFSのバックエンドはSQLServerな)
勿論本気で言ってはいない。
ついでに基盤もAzureに…いやいま何でやってるか知らんのやけど、それで解決するならそれでもええんちゃう？
後学のために教えてほしいのですが、今回のような障害に対して SQL Server を採用するとなにかアドバンテージがあるということでしょうか？
MSがGitHub買収したからのネタだよ。言わせんな、恥ず(ry
両データセンターのMySQLデータベースクラスターには一方だけに存在する書き込みが含まれることになるってそんな状態を許すOrchestratorってなに？二重化したつもりが出来てなかったってこと？
別の解説 [atmarkit.co.jp]とそのはてブ [hatena.ne.jp]
説明と改善策にもあるけど、距離があること、データがデカいことの両方が影響するので、リーダー選出は動作として正しかったがリカバリー策として不十分(になっていた)ということかな?
ただ綺麗に同期できればいいけど、そこはNGなとこか
引用対策
GitHubは今回のサービス障害を受け、次のような対策を講じるとしている。地理的に離れた2つのデータセンターにまたがってマスターセレクションを行う設定をやめるサービスステータス表示の方法を改める。「緑」「黄」「赤」だけでなく、サービスの種類に応じ、より詳細な情報を表示するようにするGitHubは障害発生の数週間前から、データセンターを1カ所失っても問題がないように、N+1の新たなサービスデリバリアーキテクチャを構築する取り組みを始めている。この取り組みを加速するサービスに関する同社の数々の前提をあらためて検証すべく、自律的に動いていく
GitHubは今回のサービス障害を受け、次のような対策を講じるとしている。
地理的に離れた2つのデータセンターにまたがってマスターセレクションを行う設定をやめるサービスステータス表示の方法を改める。「緑」「黄」「赤」だけでなく、サービスの種類に応じ、より詳細な情報を表示するようにするGitHubは障害発生の数週間前から、データセンターを1カ所失っても問題がないように、N+1の新たなサービスデリバリアーキテクチャを構築する取り組みを始めている。この取り組みを加速するサービスに関する同社の数々の前提をあらためて検証すべく、自律的に動いていく
NGなとこはここ?
また、オーケストレータ―機能は米国東部の接続が復旧しているにもかかわらず、同データセンターのMySQLデータベースインスタンスをスレーブ/リードレプリカとして認識せず、米国西部データセンターで完結したデータベーストポロジーを構成した。
う～ん、そこは別に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の準同期レプリケーションだと、スレイブ側に書き込んじゃいかんよな……
この手の瞬断みたいなケースって結構やっかいじゃない？よくあると言ってはなんだが、クラスター障害の原因などを調べると、これに行き着くことが多い。
なんか少ない印象。ソースばっかりだとそんなモンなのかな。
GitHub が Mysql に保存しているのは Issues やプルリクエストなどのメタデータだけ。ソースの保存先は別です。
言うようにNetflixがやってるようなカオスエンジニアリングしか手が無いんだろうか。運用前に確かめた仕組みと仕掛けが何時までも機能するなんて誰も思ってないが、何も起きないから許されてるか、起きても根性でみんな何とかしてるが。
確認したときは動いていたという証拠さえあればなんとかなる。
> カオスエンジニアリングしか手が無いんだろうか。 カオスプログラミングなら実践しているんですが...
これでMariaDBの信頼性が上がってくれるならありがたい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
SQLServer (スコア:2)
Re: (スコア:0)
GitHubのその辺って複数DBに対応してるんかね？
確かにSQLServerもLinux対応したしなぁ。
どっちかというとアプリ書き換えるよりデータ移行のほうが楽な気がする。
ってことでTFSに置き換えられたら笑うぞw
(因みにTFSのバックエンドはSQLServerな)
勿論本気で言ってはいない。
Re: (スコア:0)
ついでに基盤もAzureに…いやいま何でやってるか知らんのやけど、それで解決するならそれでもええんちゃう？
Re: (スコア:0)
後学のために教えてほしいのですが、今回のような障害に対して SQL Server を採用するとなにかアドバンテージがあるということでしょうか？
Re: (スコア:0)
MSがGitHub買収したからのネタだよ。言わせんな、恥ず(ry
要するに (スコア:0)
両データセンターのMySQLデータベースクラスターには一方だけに存在する書き込みが含まれることになるってそんな状態を許すOrchestratorってなに？
二重化したつもりが出来てなかったってこと？
Re:要するに (スコア:2, 参考になる)
別の解説 [atmarkit.co.jp]とそのはてブ [hatena.ne.jp]
説明と改善策にもあるけど、距離があること、データがデカいことの両方が影響するので、リーダー選出は動作として正しかったがリカバリー策として不十分(になっていた)ということかな?
ただ綺麗に同期できればいいけど、そこはNGなとこか
引用
対策
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の準同期レプリケーションだと、スレイブ側に書き込んじゃいかんよな……
Re: (スコア:0)
この手の瞬断みたいなケースって結構やっかいじゃない？
よくあると言ってはなんだが、クラスター障害の原因などを調べると、これに行き着くことが多い。
バックアップは数TBにおよび (スコア:0)
なんか少ない印象。ソースばっかりだとそんなモンなのかな。
Re:バックアップは数TBにおよび (スコア:1)
GitHub が Mysql に保存しているのは Issues やプルリクエストなどのメタデータだけ。
ソースの保存先は別です。
DRだの複数拠点跨る仕組みの定期的な試験 (スコア:0)
言うようにNetflixがやってるようなカオスエンジニアリングしか手が無いんだろうか。
運用前に確かめた仕組みと仕掛けが何時までも機能するなんて誰も思ってないが、
何も起きないから許されてるか、起きても根性でみんな何とかしてるが。
Re: (スコア:0)
確認したときは動いていたという証拠さえあればなんとかなる。
Re: (スコア:0)
> カオスエンジニアリングしか手が無いんだろうか。
カオスプログラミングなら実践しているんですが...
Re: (スコア:0)
これでMariaDBの信頼性が上がってくれるならありがたい。