高可用性データベースには、このようなサービスの中断に起因するサーバーのダウンタイムを回避するために、障害など、ユーザーにサービスを提供するために、最大限に言及します。データベースの高可用性は、専用のデータベースに反映されていないサービスを提供し続けるだけでなく、データの一貫性を確保するための能力にすることができます。
SequoiaDBセコイアデータベース100％MySQLの国内オープンソースの分散データベースとして、互換性、およびどのように高可用性の観点でその性能？どのようにその高可用性を実現していますか？本明細書SequoiaDB高可用性データベース・レッドウッドを詳細に説明した原理は、検証および試験します。
コンピューティングおよびストレージ分離アーキテクチャを使用して01レッドウッドセコイアSequoiaDB分散データベースクラスタアーキテクチャは、SequoiaSQL-MySQLはSQL層、調整ノードによって記憶層、及びノード・カタログ・データ・ノードを算出します。
図1 SequoiaDB分散アーキテクチャ
図1に示すように、調整ノードによって図クラスタ、カタログ・ノード、ノード3及びSequoiaSQL-MySQLのデータ構成の最も単純なSequoiaDB分散データベース・アーキテクチャです。3台のサーバ上のデータノードは、データの複製が三組1、2、同期データとの間のデータからなるデータの3つのデータ複製同一コピーからなる各群を含む前記ログを通して一貫性をコピーします。
1から成る、A1、A2データ複製グループ、データの3つの同一のコピー。データ複製グループ1グループ2、図3は、データの複製に類似しています。SequoiaDB分散クラスタでは、各レプリケーション・グループは、データの7枚までサポートしています。
高可用性分散テスト環境は、マスタノードが読み取りおよび書き込み機能た前記図1に示され、本明細書にクラスタアーキテクチャを説明し、2つのバックアップ・コピーは、読み出し動作またはバックアップを実行することができます。
02セコイアは、ログの複数のコピー間でデータの一貫性を維持するために、同期SequoiaDBいかだアルゴリズムを使用して、高可用性データベースの可用性を実現します。
図2は、接続されている3つのノードの間に維持される
。図2に示すように、保持する3つのコピーのSequoiaDBクラスタ間のハートビート接続を。
共有状態を経てグループ間でデータをコピーするには、ハートビート共有ビートを共有しました。示されるように、共有ビート心臓は、情報構造は、ID 3、LSN自体が開始されると、LSN終了自体、タイムスタンプ、データグループのバージョン番号、及びその現在の同期状態の役割を含むビート。
図3ハートビートステータス情報構造
各ノードは、ノードの状態を記録するためのステータス共有テーブルのテーブルを維持します。N個の連続第二応答メッセージが受信されない場合、共有ビートが2秒に1回送信され、取得応答情報は、ノードがダウンであると考えられます。
マスタノードとしてクラスタ内の唯一のノード、他のノードにスタンバイノード。デュアルマスタまたはマルチマスタが発生した場合は、クラスタ内でその唯一のマスターノードを確保するために、コントラストを低下させるLSNに従って調製する必要があります。
注意： 1）マスターノードがダウンしたときに、新しいマスターノードとして新しいノードを選出する必要性からバックアップノードを。スタンバイ・ノードがダウンすると2）、マスタノードが復旧スタンバイノードの後に影響を受け、等されていない、マスタノードは、同期データログを維持し続けます。
プライマリノードが、選挙プロセスの新しいマスターを停止した場合、次が説明します。選出条件以下の2つの条件を満足するマスタノードとして選出することができるスタンバイノード2による多数決最大LSNノード選択プロセス 1）ダウン場合、マスターノードAは、Aが自動的にオフ、スタンバイ・ノードに、コーディネータ・ノード・トラフィックを減少させます接続。
図4クラスタのマスターノードがハング
2）A1及びA2をそれらが選挙要求を開始満たしている場合、すなわち、それはマスターノードLであるか否かを決定するために装備されています。条件内容：
-
これは、マスターノードではありません
-
半分以上を占め、残りのスタンバイ・ノード
-
他のノードLSN新しいよりLSN自身の機器
3）他のノードは、そのノードLSN LSNと投票して準備され、独自のより新しいLSN、それに対して、または投票の賛成で議決権を行使された場合、比較を行います。4）超える場合（N / 2 + 1）の賛成は、マスターノードのノード選挙の成功をサポートしています。それ以外の場合は、機器のノード、および選挙の敗北を保ちます。5）他のノードにハートビートデータグループ情報を共有成功選挙状態情報の後。
03高可用性災害時リカバリーの検証は、一般的に機能テスト、パフォーマンステスト、テスト分散トランザクション、高可用性災害時リカバリーのテストと互換性テストなどのデータベース・POCのテストを配布されています。以下はSequoiaDBセコイア高可用性データベースは、テストを検証します。
テスト環境の説明
SequoiaSQL-MySQLの、3つのデータノード、1社のノードのカタログ、コーディネータノードを備えた分散クラスタ環境試験物品は、クラスタ構造は、具体的な実施形態セコイアの公式サイトの仮想マシンイメージのビルドのチュートリアルを参照してください。後、我々は、高可用性を検証するために、分散型データベースクラスタ上で操作を読み書き、マスターノードのプロセスを殺します。
-
ビューサーバークラスタのステータス
＃サービスsdbcm状況 ..... メインPID：803（sdbcm） タスク：205（上限：2319） のcgroup：/system.slice/sdbcm.service ├─779 sdbcmd ├─803 sdbcm（11790） ├─1166sequoiadb（ 11840）D ├─1169sequoiadb（11810）S ├─1172sequoiadb（11830）D ├─1175sdbom（11780） ├─1178sequoiadb（11820）D ├─1181sequoiadb（11800）C 1369 / OPT / sequoiadb /プラグイン/ SequoiaSQL / binに/../../../のJava / JDK / binに/ javaの-jarは/ opt / sequoiadb /プラグイン/ SequoiaSQL .....
-
SequoiaDBは11820,11830,11840クラスタ・ポートのデータノードを分散、カタログ11800、11810コーディネータノードノード
sdbadmin @ sequoiadb：〜$ psの-ef | グレップのsequoiadbの sdbadmin 1166 1 0 Aug20？00：02：23 sequoiadb（11840 ）D sdbadmin 1169年 1 0 Aug20？00：01：43 sequoiadb（11810 ）S sdbadmin 1172年 1 0 Aug20？00：02：24 sequoiadb（11830 ）D sdbadmin 1178年 1 0 Aug20？00：02：33 sequoiadb（11820 ）Dの sdbadmin 1181年 1 0 Aug20？00：04：01 sequoiadb（11800）C
-
11820、マスターノードを殺すクエリを実行し、SQLを記述
sdbadminする@ sequoiadb：〜$キル1178 sdbadminする@ sequoiadb：〜$ psの-ef | グレップのsequoiadbの sdbadmin 1166 1 0 Aug20？00：02：24 sequoiadb（11840 ）D sdbadmin 1169年 1 0 Aug20？00：01：43 sequoiadb（11810 ）S sdbadmin 1172年 1 0 Aug20？00：02：24 sequoiadb（11830 ）Dの sdbadmin 1181 1 0 Aug20？00：04：01 sequoiadb（11800 ）C sdbadmin 1369年 1 0 Aug20？00：01：33 / OPT / sequoiadb ....
-
挿入操作の前に実行SQL、ビュー・データ121を参照してください
MySQLの> を選択 * からnews.user_info。 + ------ + ----------- + | ID | unickname | + ------ + ----------- + | 1 | TEST1 | ........ | 119 | test119 | | 120 | test120 | | 121 | test121 | + ------ + ----------- + 121行にセット（0.01秒）
-
書き込みSQLは、挿入が成功した参照します
MySQLの> news.user_info（ID、unickname）値（挿入122、" S uccess " ）。 クエリOK、1行が影響を受ける（0.00 秒） のMySQL > コミット。 クエリOK、0影響を受ける行（0.01 秒） のMySQL > セレクト * からnews.user_info。 + ------ + ----------- + | ID | unickname | + ------ + ----------- + | 1 | TEST1 | ......... | 120 | test120 | | 121 | test121 | |122 | 成功| + ------ + ----------- + 122行にセット（0.00秒）
データ（122、「成功」）、データ挿入の成功、マスタノードがハングアップする場合には、書き込みに影響されない、一貫性のあるデータの読み書き、高可用性を検証します。
千ワット今実行中にプライマリデータノードを殺すimprt.sh、スクリプトを書くインポートデータ、マスタノード障害シナリオのシミュレーション、ビュークラスタ書き込みセコイアグラフィカル監視データベースインタフェースSACの変更を行います。
注意： あなたが取得する必要がある場合は imprt.sh 「ジャイアントセコイアデータベース」公開番号返信「imprt」を懸念するスクリプトを、得ることができます。
-
インポートデータのスクリプト
./imprt.sh 协调节点主机 协调节点端⼝ 次数./imprt.sh 192.168.1.122 11810 100
-
、高可用性クラスタの復旧後5、インポート時のデータ、プライマリデータノードを殺す書き留めインサート
図5 SACクラスタ監視インターフェースは、概略的なリーダーを変更します
図6 SAC書き込みデータ量TPCCの模式図
SACは、視覚的なインターフェースから見ることができ、一次データノードの持続時間は、私たちの千ワットのデータ挿入操作の途中で失敗した場合、データの読み取りは非常に短いの影響を受けています。最後に、使用して imprt.sh 故障にデータを再インポートするためのスクリプトを、あなたは、データの一貫性を最終的に確保することができます。
04要約SequoiaDB
分散クラスタの複数のグループを提供することができる、より良い高可用性クラスタデータの複製を有し、各グループは、同期方法及びラフトアルゴリズムでログのコピーとの間のデータの一貫性を維持することによって、同一のコピーのデータ複製複数から構成される。最後に、クラスタ・マスタ・データ・ノードがダウンした場合、クラスタは通常データ読み出しに分散してデータを書き込むことができる、書き込みベリファイ動作千万を行い、データは、最終的な、高い可用性が確認されたと一致したままです。