TiDBがJepsenに出会った時
2823 ワード
この記事では、TiDBが分散型コンシステンシ検証フレームワークJepsenを使用してコンシステンシ検証を行う方法について説明します.
JepsenはKyle Kingsburyが関数式プログラミング言語Clojureを用いて作成した分布式システムの整合性を検証するテストフレームワークであり,著者らはそれを用いて多くの有名な分布式システム(etcd,cockroachdb...)「攻撃」(コンシステンシ検証)が行われ、一部のシステムでバグが見つかりました.ここで一連のブログは,著者の検証過程と一貫性検証に対する多くの思考を示している.
Jepsen検証システムは6つのノードからなり、1つの制御ノード(control node)、5つの制御ノード(デフォルトはn 1,n 2,n 3,n 4,n 5)であり、制御ノードはすべての命令をいくつかまたはすべての制御ノードに送信し、これらの命令には下位のshell命令から上位のSQL文などが含まれる.Jepsenは、分散システムを検証するためのいくつかのコアAPIを提供しています. DB DB DBは検証された分散システムのダウンロード、導入、起動、クローズコマンドをカプセル化し、コア関数はsetupとteardownから構成され、TiDBのJepsenテストではsetupがTiDBのダウンロードを担当し、Placement Driver、TiKV、TiDBを順次起動する.teardownは、TiDBシステム全体を閉じ、ログを削除する責任を負います. Client Clientは各テストに必要なお客様をカプセル化し、各clientは2つのインタフェースを提供します:setupとinvoke、setupはTiDBの接続を担当し、invokeはテスト中にclientがTiDBに呼び出したsql文を含み、具体的な文はテストによって異なります. Checker Checkerは、テスト生成の履歴を検証するために使用され、テスト結果が予想通りであるか否かを判断する.履歴のフォーマットは、下図のように、 である. Nemesis Nemesisは、一般的なネットワークパーティション、ネットワーク遅延、ノードダウンタイムなど、システムに障害を導入するために使用されます.TiDBのテストでは、parts nemesis導入テストの一部の文が実行されたときにtime-outのエラーが発生したことを示しています. Generator Generatorは、ClientとNemesisの操作をインターリーブし、テスト全体に対して特定の実行文を生成するJepsenのイベントジェネレータです.
TiDBのJepsenテストは3つあり,それぞれbank,set,registerテストである.
銀行テストは、スナップショットの分離を検証するために使用されます.このテストは、銀行システム内の様々な振り替えをシミュレートし、各銀行システムの初期はこのようにすることができます.
1〜5はそれぞれ口座名を表し、10は口座残高を表す.テストでは、振込情報がランダムに生成されます.
代表は金額5を口座1から口座2に振り込む操作を行う.同時に、テストはすべての口座の預金情報をランダムに読み取ります.たとえば、ある時点の口座の預金情報は次のようになります.
次は、テストの進行中のスクリーンショットです.
スナップショット・アイソレーションの下で、すべての振り替えは、すべてのアカウントの合計金額が同じであることを保証する必要があります.TiDBは,種々のnemesisを導入しても順調に試験に合格した.
このテストは、異なるノードから異なる数を1つのテーブルに同時に挿入し、最終的なテーブル読み取り操作を行い、すべての戻り成功した挿入値が必ずテーブルに現れることを検証し、その後、すべての戻り失敗した挿入値がテーブルにないことを検証します.また、nemesisの導入により、time-outを返す挿入値がテーブルに現れない可能性があります.これは通常の状況です.
次は、テストの進行中のスクリーンショットです.
同様に、TiDBはテストに合格した.
このテストはよく理解され、テーブルを構築し、値を挿入し、この値をレジスタと見なし、テストで各ノードからread、write、cas操作を同時に行います.
次に、Jepsenによって生成された一連の操作履歴(上記の図)を用いてLinearizability整合性の検証を行う.このアルゴリズムはJepsenの核心であり、Jepsenが業界でよく知られている理由の一つでもあるので、時間をかけて深く勉強して、別の文章でこのアルゴリズムを具体的に紹介します.
TiDBがコードを更新するたびに、内部でCIをトリガしてJepsenを実行し、JepsenによってTiDBのデータ整合性を保証します.分散テスト、コンシステンシ検証に興味がある場合は、開発への参加を歓迎します.
TiDB Jepsen:github.com/pingcap/jep…
徐鵬
Jepsenとは
JepsenはKyle Kingsburyが関数式プログラミング言語Clojureを用いて作成した分布式システムの整合性を検証するテストフレームワークであり,著者らはそれを用いて多くの有名な分布式システム(etcd,cockroachdb...)「攻撃」(コンシステンシ検証)が行われ、一部のシステムでバグが見つかりました.ここで一連のブログは,著者の検証過程と一貫性検証に対する多くの思考を示している.
Jepsenはどうやって?
Jepsen検証システムは6つのノードからなり、1つの制御ノード(control node)、5つの制御ノード(デフォルトはn 1,n 2,n 3,n 4,n 5)であり、制御ノードはすべての命令をいくつかまたはすべての制御ノードに送信し、これらの命令には下位のshell命令から上位のSQL文などが含まれる.Jepsenは、分散システムを検証するためのいくつかのコアAPIを提供しています.
TiDBでのJepsenテスト
TiDBのJepsenテストは3つあり,それぞれbank,set,registerテストである.
Bank Test
銀行テストは、スナップショットの分離を検証するために使用されます.このテストは、銀行システム内の様々な振り替えをシミュレートし、各銀行システムの初期はこのようにすることができます.
parts：
majority-ring： majority
start-stop： SIGSTOP
start-kill： SIGKILL1〜5はそれぞれ口座名を表し、10は口座残高を表す.テストでは、振込情報がランダムに生成されます.
[1 10]
[2 10]
[3 10]
[4 10]
[5 10]代表は金額5を口座1から口座2に振り込む操作を行う.同時に、テストはすべての口座の預金情報をランダムに読み取ります.たとえば、ある時点の口座の預金情報は次のようになります.
[1 2 5]次は、テストの進行中のスクリーンショットです.
スナップショット・アイソレーションの下で、すべての振り替えは、すべてのアカウントの合計金額が同じであることを保証する必要があります.TiDBは,種々のnemesisを導入しても順調に試験に合格した.
Set Test
このテストは、異なるノードから異なる数を1つのテーブルに同時に挿入し、最終的なテーブル読み取り操作を行い、すべての戻り成功した挿入値が必ずテーブルに現れることを検証し、その後、すべての戻り失敗した挿入値がテーブルにないことを検証します.また、nemesisの導入により、time-outを返す挿入値がテーブルに現れない可能性があります.これは通常の状況です.
次は、テストの進行中のスクリーンショットです.
同様に、TiDBはテストに合格した.
Register Test
このテストはよく理解され、テーブルを構築し、値を挿入し、この値をレジスタと見なし、テストで各ノードからread、write、cas操作を同時に行います.
次に、Jepsenによって生成された一連の操作履歴(上記の図)を用いてLinearizability整合性の検証を行う.このアルゴリズムはJepsenの核心であり、Jepsenが業界でよく知られている理由の一つでもあるので、時間をかけて深く勉強して、別の文章でこのアルゴリズムを具体的に紹介します.
最後に書く
TiDBがコードを更新するたびに、内部でCIをトリガしてJepsenを実行し、JepsenによってTiDBのデータ整合性を保証します.分散テスト、コンシステンシ検証に興味がある場合は、開発への参加を歓迎します.
TiDB Jepsen:github.com/pingcap/jep…
徐鵬