スギTech|SequoiaDBスギデータベース高可用性災害対応テスト
5242 ワード
データベースの高可用性とは、サーバのダウンタイムなどの障害によるサービス中断を回避するために、ユーザーに最大限のサービスを提供することです.データベースの高可用性は、データベースが継続的にサービスを提供できるかどうかだけでなく、データの一貫性を保証できるかどうかにも現れます.SequoiaDBスギデータベースは、MySQLと100%互換性のある国産オープンソース分散データベースとして、高可用性の面でどのように表現されていますか?その高可用性はどのように実現されていますか?この文書では、SequoiaDBスギデータベースの高可用性の原理を詳細に説明し、テスト検証を行います.
01スギ分散クラスタアーキテクチャSequoiaDBスギデータベースはコンピューティングとストレージの分離アーキテクチャを採用し、SequoiaSQL-MySQLはSQLコンピューティング層であり、ストレージ層は協調ノード、目次ノード、データノードから構成されている.
図1 SequoiaDB分散アーキテクチャ
図1に示すように最も簡単なSequoiaDB分散型データベースクラスタアーキテクチャ図であり、1つの協調ノード、1つのエントリノード、3つのデータノード、およびSequoiaSQL-MySQLから構成されている.ここで、データノードは、3つのサーバに3つのデータ複製グループ1、2、3を含み、各データ複製グループは3つの完全に同じデータ複製からなり、データ複製間はログ同期によってデータが一致している.A,A 1,A 2はデータ複製グループ1を構成し,3つは全く同じデータ複製である.データ複製グループ2、3は、データ複製グループ1と同様である.SequoiaDB分散クラスタでは、レプリケーション・グループごとに最大7つのデータ・コピーがサポートされます.本明細書の高可用性テスト環境では、図1に示す分散クラスタアーキテクチャを採用し、プライマリノードには読み書き機能があり、2つのバックアップが読み書き操作またはバックアップを実行することができる.
02スギデータベース高可用性実装SequoiaDB高可用性Raftアルゴリズムにより実装され、マルチコピー間でログ同期によりデータ整合性を維持する.
図2の3つのノード間の接続を維持する
図2に示すように、SequoiaDBクラスタの3つのレプリカ間はハートビートにより接続されている.データ・グループ・レプリカ間でハートビート情報sharing-beatを共有することでステータス共有を行います.図3に示すように、sharing-beat心拍情報構造は、心拍ID、自己開始LSN、自己終了LSN、タイムスタンプ、データセットバージョン番号、自己現在のロール、および同期状態を含む.
図3の心拍状態情報構造各ノードは、ノード状態を記録するためのstatus-sharing tableテーブルを維持する.Sharing-beatは2秒ごとに送信し,応答情報を収集し,N秒連続で応答情報を受信しなければノードがダウンタイムとする.クラスタにはプライマリノードとして1つのノードしかなく、他のノードはスタンバイノードです.マルチプライマリまたはデュアルプライマリが発生した場合は、LSNの比較に従って、クラスタにプライマリノードが1つしかないことを保証する必要があります.
次に、プライマリノードがダウンタイムしたときに新しいプライマリノードを選択する手順を説明します.
選挙条件.
次の2つの条件を満たすと、プライマリノードに選択できます.多数の予備ノードの投票は を通過した.当該ノードLSN最大 選挙過程.
1)マスタノードAがダウンタイムした場合、Aは自動的にスタンバイノードにダウンし、協調ノードの業務接続を閉じる.
図4クラスタ内のプライマリノードのドロップダウン
2)A 1とA 2は,いずれも自身が主ノードに昇格する条件を備えているか否かを判断し,該当すれば選挙請求を開始する.
条件:
3)他のサブノードは,被投票ノードのLSNを自分のLSNと対比し,自分のLSNより新しい場合は賛成票,そうでない場合は反対票を投じる.
4)賛成票が(n/2+1)を超えると,そのノードを主ノードとして支持し,選挙に成功する.そうでなければ、予備ノードの役割を維持し、選挙に失敗します.
5)選挙に成功した後,心拍状態情報によりデータ群情報を他のノードに共有する.
03高可用性災害対応検証
一般的な分散型データベースPOCテストには、機能テスト、パフォーマンステスト、分散型トランザクションテスト、高可用性災害対応テスト、互換性テストなどが含まれます.以下、SequoiaDBスギデータベースの高可用性を検証します.
テスト環境の説明
本文のテスト環境は分布式クラスタを採用し、1つのSequoiaSQL-MySQL、3つのデータノード、1つの編目ノード、1つの協調ノードを含み、クラスタを構築する方式は具体的に巨杉公式サイトの仮想マシンミラー構築チュートリアルを参照することができる.killがプライマリノードプロセスを削除した後、分散型データベースクラスタの読み書き操作を行い、高可用性を検証します.
データ(122,「success」)のデータ挿入に成功し,そのうちの1つのプライマリノードがドロップされた場合,読み書きに影響を及ぼさず,データの読み書きが一致し,高可用性が検証された.
インポート1000 wのデータ書き込みスクリプトimprtが実行する.shは、実行中にkillがプライマリデータノードを削除し、プライマリノードの障害シーンをシミュレートし、スギデータベースのグラフィックス化監視インタフェースSAC上でクラスタの読み書きの変化を表示する.
図5 SACモニタインタフェースクラスタ読み書き変化模式図
図6 SAC tpcc書き込みデータ量の概略図を見る
SACの可視化インタフェースから,1000 wのデータ挿入操作中にプライマリ・データ・ノードに障害が発生すると,データの読み書きに影響を与える持続時間が短いことがわかる.最後にimprtを用いる.shスクリプトは挿入に失敗したデータを再インポートし、データの最終的な一貫性を保証します.
04まとめ
SequoiaDB分散クラスタは高い可用性を備えており、クラスタは複数のデータ複製グループを設定することができ、各データ複製グループは複数の全く同じコピーから構成され、コピー間はRaftアルゴリズムとログ同期方式でデータ整合性を維持する.最後に,本論文では,千万レベルのデータ書き込み操作を実行する際に,クラスタマスターデータノードがダウンタイムした場合,分散クラスタが正常にデータを読み書きでき,データが最終的に一致し,高可用性が検証されたことも検証した.
01スギ分散クラスタアーキテクチャSequoiaDBスギデータベースはコンピューティングとストレージの分離アーキテクチャを採用し、SequoiaSQL-MySQLはSQLコンピューティング層であり、ストレージ層は協調ノード、目次ノード、データノードから構成されている.
図1 SequoiaDB分散アーキテクチャ
図1に示すように最も簡単なSequoiaDB分散型データベースクラスタアーキテクチャ図であり、1つの協調ノード、1つのエントリノード、3つのデータノード、およびSequoiaSQL-MySQLから構成されている.ここで、データノードは、3つのサーバに3つのデータ複製グループ1、2、3を含み、各データ複製グループは3つの完全に同じデータ複製からなり、データ複製間はログ同期によってデータが一致している.A,A 1,A 2はデータ複製グループ1を構成し,3つは全く同じデータ複製である.データ複製グループ2、3は、データ複製グループ1と同様である.SequoiaDB分散クラスタでは、レプリケーション・グループごとに最大7つのデータ・コピーがサポートされます.本明細書の高可用性テスト環境では、図1に示す分散クラスタアーキテクチャを採用し、プライマリノードには読み書き機能があり、2つのバックアップが読み書き操作またはバックアップを実行することができる.
02スギデータベース高可用性実装SequoiaDB高可用性Raftアルゴリズムにより実装され、マルチコピー間でログ同期によりデータ整合性を維持する.
図2の3つのノード間の接続を維持する
図2に示すように、SequoiaDBクラスタの3つのレプリカ間はハートビートにより接続されている.データ・グループ・レプリカ間でハートビート情報sharing-beatを共有することでステータス共有を行います.図3に示すように、sharing-beat心拍情報構造は、心拍ID、自己開始LSN、自己終了LSN、タイムスタンプ、データセットバージョン番号、自己現在のロール、および同期状態を含む.
図3の心拍状態情報構造各ノードは、ノード状態を記録するためのstatus-sharing tableテーブルを維持する.Sharing-beatは2秒ごとに送信し,応答情報を収集し,N秒連続で応答情報を受信しなければノードがダウンタイムとする.クラスタにはプライマリノードとして1つのノードしかなく、他のノードはスタンバイノードです.マルチプライマリまたはデュアルプライマリが発生した場合は、LSNの比較に従って、クラスタにプライマリノードが1つしかないことを保証する必要があります.
Note:
1） ， 。
2） ， ， ， 。
次に、プライマリノードがダウンタイムしたときに新しいプライマリノードを選択する手順を説明します.
選挙条件.
次の2つの条件を満たすと、プライマリノードに選択できます.
1)マスタノードAがダウンタイムした場合、Aは自動的にスタンバイノードにダウンし、協調ノードの業務接続を閉じる.
図4クラスタ内のプライマリノードのドロップダウン
2)A 1とA 2は,いずれも自身が主ノードに昇格する条件を備えているか否かを判断し,該当すれば選挙請求を開始する.
条件:
LSN LSN
3)他のサブノードは,被投票ノードのLSNを自分のLSNと対比し,自分のLSNより新しい場合は賛成票,そうでない場合は反対票を投じる.
4)賛成票が(n/2+1)を超えると,そのノードを主ノードとして支持し,選挙に成功する.そうでなければ、予備ノードの役割を維持し、選挙に失敗します.
5)選挙に成功した後,心拍状態情報によりデータ群情報を他のノードに共有する.
03高可用性災害対応検証
一般的な分散型データベースPOCテストには、機能テスト、パフォーマンステスト、分散型トランザクションテスト、高可用性災害対応テスト、互換性テストなどが含まれます.以下、SequoiaDBスギデータベースの高可用性を検証します.
テスト環境の説明
本文のテスト環境は分布式クラスタを採用し、1つのSequoiaSQL-MySQL、3つのデータノード、1つの編目ノード、1つの協調ノードを含み、クラスタを構築する方式は具体的に巨杉公式サイトの仮想マシンミラー構築チュートリアルを参照することができる.killがプライマリノードプロセスを削除した後、分散型データベースクラスタの読み書き操作を行い、高可用性を検証します.
# service sdbcm status
.....
Main PID: 803 (sdbcm)
Tasks: 205 (limit: 2319)
CGroup: /system.slice/sdbcm.service
├─ 779 sdbcmd
├─ 803 sdbcm(11790)
├─1166 sequoiadb(11840) D
├─1169 sequoiadb(11810) S
├─1172 sequoiadb(11830) D
├─1175 sdbom(11780)
├─1178 sequoiadb(11820) D
├─1181 sequoiadb(11800) C
1369 /opt/sequoiadb/plugins/SequoiaSQL/bin/../../../java/jdk/bin/java -jar /opt/sequoiadb/plugins/SequoiaSQL
.....
SequoiaDB 11820，11830，11840； 11800， 11810
sdbadmin@sequoiadb:~$ ps -ef|grep 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
kill 11820 ， sql
sdbadmin@sequoiadb:~$ kill 1178
sdbadmin@sequoiadb:~$ ps -ef|grep 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> select * from news.user_info;
+------+-----------+
| id | unickname |
+------+-----------+
| 1 | test1 |
........
| 119 | test119 |
| 120 | test120 |
| 121 | test121 |
+------+-----------+
121 rows in set (0.01 sec)
sql，
mysql> insert into news.user_info(id,unickname)values(122,"s
uccess");
Query OK, 1 row affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.01 sec)
mysql> select * from news.user_info;
+------+-----------+
| id | unickname |
+------+-----------+
| 1 | test1 |
.........
| 120 | test120 |
| 121 | test121 |
| 122 | success |
+------+-----------+
122 rows in set (0.00 sec)
データ(122,「success」)のデータ挿入に成功し,そのうちの1つのプライマリノードがドロップされた場合,読み書きに影響を及ぼさず,データの読み書きが一致し,高可用性が検証された.
インポート1000 wのデータ書き込みスクリプトimprtが実行する.shは、実行中にkillがプライマリデータノードを削除し、プライマリノードの障害シーンをシミュレートし、スギデータベースのグラフィックス化監視インタフェースSAC上でクラスタの読み書きの変化を表示する.
Note:
imprt.sh ， “ ” “imprt” 。
./imprt.sh
./imprt.sh 192.168.1.122 11810 100
5 ， ，kill ，insert ，
図5 SACモニタインタフェースクラスタ読み書き変化模式図
図6 SAC tpcc書き込みデータ量の概略図を見る
SACの可視化インタフェースから,1000 wのデータ挿入操作中にプライマリ・データ・ノードに障害が発生すると,データの読み書きに影響を与える持続時間が短いことがわかる.最後にimprtを用いる.shスクリプトは挿入に失敗したデータを再インポートし、データの最終的な一貫性を保証します.
04まとめ
SequoiaDB分散クラスタは高い可用性を備えており、クラスタは複数のデータ複製グループを設定することができ、各データ複製グループは複数の全く同じコピーから構成され、コピー間はRaftアルゴリズムとログ同期方式でデータ整合性を維持する.最後に,本論文では,千万レベルのデータ書き込み操作を実行する際に,クラスタマスターデータノードがダウンタイムした場合,分散クラスタが正常にデータを読み書きでき,データが最終的に一致し,高可用性が検証されたことも検証した.