パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

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

  • by Anonymous Coward

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

    • Re:要するに (スコア:2, 参考になる)

      by Anonymous Coward on 2018年11月03日 18時31分 (#3509521)

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

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

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

      引用
      対策

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

      地理的に離れた2つのデータセンターにまたがってマスターセレクションを行う設定をやめる
      サービスステータス表示の方法を改める。「緑」「黄」「赤」だけでなく、サービスの種類に応じ、より詳細な情報を表示するようにする
      GitHubは障害発生の数週間前から、データセンターを1カ所失っても問題がないように、N+1の新たなサービスデリバリアーキテクチャを構築する取り組みを始めている。この取り組みを加速する
      サービスに関する同社の数々の前提をあらためて検証すべく、自律的に動いていく

      NGなとこはここ?

      また、オーケストレータ―機能は米国東部の接続が復旧しているにもかかわらず、同データセンターのMySQLデータベースインスタンスをスレーブ/リードレプリカとして認識せず、米国西部データセンターで完結したデータベーストポロジーを構成した。

      親コメント
      • by Anonymous Coward

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

        問題は

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

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

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

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

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

          親コメント
        • by Anonymous Coward

          遠距離だと同期レプリケーション(全サーバに書き込むまで待つ)なんてやると遅延凄いから
          非同期レプリケーションだと思うけど。
          MySQLだと準同期レプリケーションの方かな?

          • Re:要するに (スコア:3, 参考になる)

            by Anonymous Coward on 2018年11月04日 14時35分 (#3509782)

            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]

            親コメント
            • by Anonymous Coward

              そんな資料あったんですね。ありがとう。
              GitHub規模だとRDBMSの機能範囲でとどめるべきだと思うし妥当ですね。

              #DAO層で同じ処理を複数DBに投げてデータ値のみ同期なんてのはやった事あるのでGitHub規模でやってみたい気はするw
              当時のプロジェクト(SI系)で内容を理解できる人は皆無w

              • by nim (10479) on 2018年11月05日 14時03分 (#3510184)

                > #DAO層で同じ処理を複数DBに投げてデータ値のみ同期なんてのはやった事あるのでGitHub規模でやってみたい気はするw

                グローバル分散環境でそれやると、遅すぎて業務にならなくなったりしない?
                MySQLの準同期レプリケーションだと、スレイブ側に書き込んじゃいかんよな……

                親コメント

アレゲはアレゲを呼ぶ -- ある傍観者

処理中...