プライマリクラスターとセカンダリクラスターに基づく災害復旧ソリューション
プライマリデータベースとセカンダリデータベースに基づく災害リカバリ（DR）は、一般的なソリューションです。このソリューションでは、DRシステムはプライマリクラスターとセカンダリクラスターで構成されます。プライマリクラスターはユーザーからのリクエストを処理し、セカンダリクラスターはプライマリクラスターからデータをバックアップします。プライマリクラスターに障害が発生した場合、セカンダリクラスターがサービスを引き継ぎ、バックアップデータを使用してサービスの提供を継続します。これにより、障害による中断なく、ビジネスシステムが正常に稼働し続けることが保証されます。
プライマリセカンダリ型災害復旧ソリューションには、以下の利点があります。
- 高可用性：プライマリセカンダリアーキテクチャによりシステムの可用性が向上し、あらゆる障害からの迅速なリカバリが保証されます。
- 高速切り替え：プライマリクラスターに障害が発生した場合、システムはセカンダリクラスターに迅速に切り替えてサービスの提供を継続できます。
- データの一貫性：セカンダリクラスターは、プライマリクラスターのデータをほぼリアルタイムでバックアップします。これにより、システムが障害発生時にセカンダリクラスターに切り替わった場合でも、データは基本的に最新の状態に保たれます。
この文書には以下の内容が含まれています。
- プライマリクラスターとセカンダリクラスターを設定します。
- プライマリクラスターからセカンダリクラスターへデータを複製します。
- クラスターを監視する。
- DR（災害復旧）システムの切り替えを実行します。
一方、このドキュメントでは、セカンダリクラスター上のビジネスデータを照会する方法、およびプライマリクラスターとセカンダリクラスター間で双方向レプリケーションを実行する方法についても説明します。
TiCDCに基づいてプライマリおよびセカンダリクラスターをセットアップする
アーキテクチャ
前述のアーキテクチャは、プライマリクラスターとセカンダリクラスターという2つのTiDBクラスターで構成されています。
- プライマリクラスター：リージョン1で稼働するアクティブなクラスターで、3つのレプリカを持ちます。このクラスターは読み取りおよび書き込みリクエストを処理します。
- セカンダリクラスター：リージョン2で稼働し、TiCDCを介してプライマリクラスターからデータを複製するスタンバイクラスター。
このDRアーキテクチャはシンプルで使いやすいです。リージョン障害に対応できるため、プライマリクラスターの書き込みパフォーマンスが低下しないことが保証され、セカンダリクラスターはレイテンシーに影響されない読み取り専用処理を処理できます。このソリューションのリカバリポイント目標（RPO）は秒単位、リカバリ時間目標（RTO）は数分、あるいはそれ以下となります。多くのデータベースベンダーが重要な本番システム向けに推奨しているソリューションです。
プライマリクラスターとセカンダリクラスターを設定する
このドキュメントでは、TiDBのプライマリクラスターとセカンダリクラスターは2つの異なるリージョン（リージョン1とリージョン2）にデプロイされています。プライマリクラスターとセカンダリクラスターの間には一定のネットワークレイテンシーがあるため、TiCDCはセカンダリクラスターと共にデプロイされます。TiCDCをセカンダリクラスターと共にデプロイすることで、ネットワークレイテンシーの影響を回避し、最適なレプリケーションパフォーマンスを実現できます。このドキュメントで提供する例の展開トポロジーは以下のとおりです（1つのコンポーネントノードが1つのサーバーにデプロイされます）。
サーバーの設定については、以下のドキュメントを参照してください。
TiDBプライマリクラスターとセカンダリクラスターのデプロイ方法の詳細については、 TiDBクラスターをデプロイを参照してください。
TiCDCを導入する際は、セカンダリクラスターとTiCDCを一緒に導入・管理する必要があり、両者間のネットワークが接続されている必要があることに注意してください。
既存のプライマリクラスターに TiCDC をデプロイするには、 TiCDCをデプロイを参照してください。
新しいプライマリクラスターとTiCDCをデプロイするには、以下のデプロイテンプレートを使用し、必要に応じて設定パラメーターを変更してください。
global: user: "tidb" ssh_port: 22 deploy_dir: "/tidb-deploy" data_dir: "/tidb-data" server_configs: {} pd_servers: - host: 10.0.1.1 - host: 10.0.1.2 - host: 10.0.1.3 tidb_servers: - host: 10.0.1.4 - host: 10.0.1.5 tikv_servers: - host: 10.0.1.6 - host: 10.0.1.7 - host: 10.0.1.8 monitoring_servers: - host: 10.0.1.9 grafana_servers: - host: 10.0.1.9 alertmanager_servers: - host: 10.0.1.9 cdc_servers: - host: 10.1.1.9 gc-ttl: 86400 data_dir: "/cdc-data" ticdc_cluster_id: "DR_TiCDC" - host: 10.1.1.10 gc-ttl: 86400 data_dir: "/cdc-data" ticdc_cluster_id: "DR_TiCDC"
プライマリクラスターからセカンダリクラスターへデータを複製する
TiDBのプライマリクラスターとセカンダリクラスターを設定した後、まずプライマリクラスターからセカンダリクラスターへデータを移行し、次にプライマリクラスターからセカンダリクラスターへリアルタイムの変更データを複製するためのレプリケーションタスクを作成します。
外部ストレージを選択してください
データの移行やリアルタイム変更データの複製には、外部ストレージを使用します。Amazon S3 が推奨されます。TiDB クラスターを自社構築のデータセンターにデプロイする場合は、以下の方法が推奨されます。
- バックアップストレージシステムとして構築MinIOを使用し、S3プロトコルを使用してデータをMinIOにバックアップします。
- ネットワークファイルシステム（NFS、NASなど）ディスクをbrコマンドラインツール、TiKV、およびTiCDCインスタンスにマウントし、POSIXファイルシステムインターフェースを使用してバックアップデータを対応するNFSディレクトリに書き込みます。
以下の例では、ストレージシステムとしてMinIOを使用していますが、これはあくまで参考例です。リージョン1またはリージョン2にMinIOをデプロイするには、別途サーバーを用意する必要があることに注意してください。
wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio
# Configure access-key and access-secret-id to access MinIO
export HOST_IP='10.0.1.10' # Replace it with the IP address of MinIO
export MINIO_ROOT_USER='minio'
export MINIO_ROOT_PASSWORD='miniostorage'
# Create the redo and backup directories. `backup` and `redo` are bucket names.
mkdir -p data/redo
mkdir -p data/backup
# Start minio at port 6060
nohup ./minio server ./data --address :6060 &
上記のコマンドは、Amazon S3サービスをシミュレートするために、1つのノード上でMinIOサーバーを起動します。コマンドのパラメーターは次のように設定されます。
endpoint:http://10.0.1.10:6060/access-key:miniosecret-access-key:miniostoragebucket:redo/backup
リンクは以下のとおりです。
s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true
データの移行
バックアップと復元機能を使用して、プライマリクラスターからセカンダリクラスターにデータを移行します。
GCを無効にします。増分移行中に新しく書き込まれたデータが削除されないようにするには、バックアップ前にアップストリームクラスターのGCを無効にする必要があります。こうすることで、履歴データが削除されるのを防げます。
GCを無効にするには、次のステートメントを実行してください。
SET GLOBAL tidb_gc_enable=FALSE;変更が有効になっていることを確認するには、
tidb_gc_enableの値を照会します。SELECT @@global.tidb_gc_enable;値が
0の場合は、GCが無効になっていることを意味します。+-------------------------+ | @@global.tidb_gc_enable | +-------------------------+ | 0 | +-------------------------+ 1 row in set (0.00 sec)データのバックアップ。アップストリームクラスターで以下のステートメント
BACKUPを実行してデータをバックアップします。BACKUP DATABASE * TO '`s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true`';+----------------------+----------+--------------------+---------------------+---------------------+ | Destination | Size | BackupTS | Queue Time | Execution Time | +----------------------+----------+--------------------+---------------------+---------------------+ | s3://backup | 10315858 | 431434047157698561 | 2022-02-25 19:57:59 | 2022-02-25 19:57:59 | +----------------------+----------+--------------------+---------------------+---------------------+ 1 row in set (2.11 sec)BACKUPのステートメントが実行されると、TiDBはバックアップデータに関するメタデータを返します。BackupTSのステートメントには注意してください。これは、バックアップ前に生成されたデータが含まれているためです。このドキュメントでは、BackupTSを増分マイグレーションの開始として使用します。データの復元。セカンダリクラスターで以下のステートメント
RESTOREを実行してデータを復元します。RESTORE DATABASE * FROM '`s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true`';+----------------------+----------+----------+---------------------+---------------------+ | Destination | Size | BackupTS | Queue Time | Execution Time | +----------------------+----------+----------+---------------------+---------------------+ | s3://backup | 10315858 | 0 | 2022-02-25 20:03:59 | 2022-02-25 20:03:59 | +----------------------+----------+----------+---------------------+---------------------+ 1 row in set (41.85 sec)
増分データを複製する
前のセクションで説明したようにデータを移行した後、 BackupTSからプライマリクラスターからセカンダリクラスターに増分データを複製できます。
変更フィードを作成します。
変更フィード設定ファイル
changefeed.tomlを作成します。[consistent] # eventual consistency: redo logs are used to ensure eventual consistency in disaster scenarios. level = "eventual" # The size of a single redo log, in MiB. The default value is 64, and the recommended value is less than 128. max-log-size = 64 # The interval for refreshing or uploading redo logs to Amazon S3, in milliseconds. The default value is 1000, and the recommended value range is 500-2000. flush-interval = 2000 # The path where redo logs are saved. storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true"プライマリクラスターで、次のコマンドを実行して、プライマリクラスターからセカンダリクラスターへの変更フィードを作成します。
tiup cdc cli changefeed create --server=http://10.1.1.9:8300 --sink-uri="mysql://{username}:{password}@10.1.1.4:4000" --changefeed-id="dr-primary-to-secondary" --start-ts="431434047157698561" --config changefeed.toml変更フィードの設定の詳細については、 TiCDC Changefeed設定を参照してください。
変更フィードタスクが正しく実行されているかどうかを確認するには、コマンド
changefeed queryを実行します。クエリ結果には、タスク情報とタスクの状態が含まれます。引数--simpleまたは-sを指定すると、基本的なレプリケーション状態とチェックポイント情報のみが表示されます。この引数を指定しない場合、出力には詳細なタスク構成、レプリケーション状態、およびレプリケーションテーブル情報が含まれます。tiup cdc cli changefeed query -s --server=http://10.1.1.9:8300 --changefeed-id="dr-primary-to-secondary"{ "state": "normal", "tso": 431434047157998561, # The TSO to which the changefeed has been replicated "checkpoint": "2020-08-27 10:12:19.579", # The physical time corresponding to the TSO "error": null }GCを有効にする。
TiCDCは、履歴データがレプリケートされる前にガベージコレクションされないようにします。そのため、プライマリクラスターからセカンダリクラスターに変更フィードを作成した後、次のステートメントを実行してGCを再度有効にできます。
GCを有効にするには、次のステートメントを実行してください。
SET GLOBAL tidb_gc_enable=TRUE;変更が有効になっていることを確認するには、
tidb_gc_enableの値を照会します。SELECT @@global.tidb_gc_enable;値が
1の場合は、GCが有効になっていることを意味します。+-------------------------+ | @@global.tidb_gc_enable | +-------------------------+ | 1 | +-------------------------+ 1 row in set (0.00 sec)
プライマリクラスターとセカンダリクラスターを監視する
現在、TiDBにはDRダッシュボードは用意されていません。以下のダッシュボードを使用してTiDBのプライマリクラスターとセカンダリクラスターの状態を確認し、DR切り替えを実行するかどうかを判断してください。
DR切り替えを実行する
このセクションでは、計画的な災害復旧（DR）切り替え、災害発生時のDR切り替え、およびセカンダリクラスターを再構築する手順について説明します。
計画されたプライマリおよびセカンダリ切り替え
重要な業務システムの信頼性をテストするためには、定期的な災害復旧（DR）訓練を実施することが重要です。以下に、DR訓練の推奨手順を示します。なお、シミュレーションによる業務データの書き込みや、データベースへのアクセスにプロキシサービスを使用することは考慮されていないため、実際のアプリケーションシナリオとは手順が異なる場合があります。必要に応じて設定を変更してください。
プライマリクラスターへの業務書き込みを停止します。
書き込みがなくなったら、TiDBクラスターの最新のTSO（
Position）を照会します。BEGIN; SELECT TIDB_CURRENT_TSO(); ROLLBACK;Query OK, 0 rows affected (0.00 sec) +--------------------+ | TIDB_CURRENT_TSO() | +--------------------+ | 452654700157468673 | +--------------------+ 1 row in set (0.00 sec) Query OK, 0 rows affected (0.00 sec)条件
TSO >= Position満たすまで、changefeeddr-primary-to-secondaryをポーリングします。tiup cdc cli changefeed query -s --server=http://10.1.1.9:8300 --changefeed-id="dr-primary-to-secondary" { "state": "normal", "tso": 438224029039198209, # The TSO to which the changefeed has been replicated "checkpoint": "2022-12-22 14:53:25.307", # The physical time corresponding to the TSO "error": null }変更フィード
dr-primary-to-secondaryを停止します。変更フィードを削除すると、一時停止できます。tiup cdc cli changefeed remove --server=http://10.1.1.9:8300 --changefeed-id="dr-primary-to-secondary"パラメーター
start-tsを指定せずにチェンジフィードdr-secondary-to-primaryを作成します。このチェンジフィードは現在時刻からデータの複製を開始します。ビジネスアプリケーションのデータベースアクセス設定を変更します。セカンダリクラスターにアクセスできるように、ビジネスアプリケーションを再起動します。
業務アプリケーションが正常に動作しているかどうかを確認してください。
上記の手順を繰り返すことで、以前のプライマリおよびセカンダリクラスター構成を復元できます。
災害発生時のプライマリおよびセカンダリ切り替え
例えば、プライマリクラスターが設置されている地域で停電などの災害が発生した場合、プライマリクラスターとセカンダリクラスター間のレプリケーションが突然中断される可能性があります。その結果、セカンダリクラスター内のデータがプライマリクラスター内のデータと矛盾することになります。
セカンダリクラスターをトランザクション整合性のある状態に復元します。具体的には、リージョン2内の任意のTiCDCノードで次のコマンドを実行して、リドゥログをセカンダリクラスターに適用します。
tiup cdc redo apply --storage "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true" --tmp-dir /tmp/redo --sink-uri "mysql://{username}:{password}@10.1.1.4:4000"このコマンドにおけるパラメーターの説明は以下のとおりです。
--storage：Amazon S3にリドゥログが保存されるパス--tmp-dir: Amazon S3 からリドゥログをダウンロードするためのキャッシュディレクトリ--sink-uri：セカンダリクラスターのアドレス
ビジネスアプリケーションのデータベースアクセス設定を変更します。セカンダリクラスターにアクセスできるように、ビジネスアプリケーションを再起動します。
業務アプリケーションが正常に動作しているかどうかを確認してください。
プライマリクラスターとセカンダリクラスターを再構築する
プライマリクラスターで発生した障害が解決した場合、またはプライマリクラスターが一時的に復旧できない場合、セカンダリクラスターのみがプライマリクラスターとして稼働するため、TiDBクラスターは脆弱な状態になります。システムの信頼性を維持するには、DRクラスターを再構築する必要があります。
TiDBのプライマリクラスターとセカンダリクラスターを再構築するには、新しいクラスターをデプロイして新しいDRシステムを構築できます。詳細については、以下のドキュメントを参照してください。
- プライマリクラスターとセカンダリクラスターを設定する
- プライマリクラスターからセカンダリクラスターへデータを複製する
- 上記の手順が完了したら、新しいプライマリクラスターを作成するには、 プライマリおよびセカンダリの切り替えを参照してください。
セカンダリクラスターでビジネスデータを照会する
プライマリ/セカンダリDRシナリオでは、セカンダリクラスターを読み取り専用クラスターとして使用し、レイテンシーに影響されないクエリを実行するのが一般的です。TiDBも、プライマリ/セカンダリDRソリューションにおいてこの機能を提供しています。
変更フィードを作成する際に、変更フィード設定ファイルで同期ポイント機能を有効にします。すると、変更フィードは定期的に（ sync-point-intervalの間隔で）、セカンダリクラスター上でSET GLOBAL tidb_external_ts = @@tidb_current_tsを実行することにより、セカンダリクラスターに複製された一貫性のあるスナップショットポイントを設定します。
セカンダリクラスターからデータを照会するには、ビジネスアプリケーションでSET GLOBAL|SESSION tidb_enable_external_ts_read = ON;を設定します。そうすることで、プライマリクラスターとトランザクション的に整合性のあるデータを取得できます。
# Starting from v6.4.0, only the changefeed with the SYSTEM_VARIABLES_ADMIN or SUPER privilege can use the TiCDC Syncpoint feature.
enable-sync-point = true
# Specifies the interval at which Syncpoint aligns the primary and secondary snapshots. It also indicates the maximum latency at which you can read the complete transaction, for example, read the transaction data generated on the primary cluster two minutes ago from the secondary cluster.
# The format is in h m s. For example, "1h30m30s". The default value is "10m" and the minimum value is "30s".
sync-point-interval = "10m"
# Specifies how long the data is retained by Syncpoint in the downstream table. When this duration is exceeded, the data is cleaned up.
# The format is in h m s. For example, "24h30m30s". The default value is "24h".
sync-point-retention = "1h"
[consistent]
# eventual consistency: redo logs are used to ensure eventual consistency in disaster scenarios.
level = "eventual"
# The size of a single redo log, in MiB. The default value is 64, and the recommended value is less than 128.
max-log-size = 64
# Interval for refreshing or uploading redo logs to Amazon S3, in milliseconds. The default value is 1000, and the recommended value range is 500-2000.
flush-interval = 2000
# The path where redo logs are saved.
storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true"
プライマリクラスターとセカンダリクラスター間で双方向レプリケーションを実行する
このDRシナリオでは、2つのリージョンにあるTiDBクラスターが互いのディザスターリカバリクラスターとして機能します。リージョン構成に基づいて、ビジネストラフィックは対応するTiDBクラスターに書き込まれ、2つのTiDBクラスターは互いのデータをバックアップします。
双方向レプリケーション機能により、2つのリージョンにあるTiDBクラスター間でデータのレプリケーションが可能になります。このDRソリューションは、データのセキュリティと信頼性を保証するとともに、データベースの書き込みパフォーマンスも確保します。計画的なDR切り替えでは、新しいチェンジフィードを開始する前に実行中のチェンジフィードを停止する必要がないため、運用とメンテナンスが簡素化されます。
双方向DRクラスターを構築するには、 TiCDCの双方向複製を参照してください。
トラブルシューティング
前の手順で問題が発生した場合は、まずTiDBに関するよくある質問で問題の解決策を見つけてください。問題が解決しない場合は、 バグを報告してください。