プライマリ クラスタとセカンダリ クラスタに基づく DR ソリューション
プライマリ データベースとセカンダリ データベースに基づく災害復旧 (DR) は、一般的なソリューションです。このソリューションでは、DR システムにはプライマリ クラスターとセカンダリ クラスターがあります。プライマリ クラスタはユーザーのリクエストを処理し、セカンダリ クラスタはプライマリ クラスタからのデータをバックアップします。プライマリ クラスタに障害が発生した場合、セカンダリ クラスタがサービスを引き継ぎ、バックアップ データを使用してサービスを提供し続けます。これにより、ビジネス システムは障害による中断なしに正常に動作し続けることが保証されます。
プライマリ-セカンダリ DR ソリューションには次の利点があります。
- 高可用性: プライマリ-セカンダリアーキテクチャによりシステムの可用性が向上し、障害からの迅速な回復が保証されます。
- 高速スイッチオーバー: プライマリ クラスタに障害が発生した場合、システムはすぐにセカンダリ クラスタに切り替えてサービスを提供し続けることができます。
- データの一貫性: セカンダリ クラスタは、プライマリ クラスタからほぼリアルタイムでデータをバックアップします。このようにして、障害によりシステムがセカンダリ クラスターに切り替わっても、データは基本的に最新の状態になります。
この文書には次の内容が含まれています。
- プライマリ クラスタとセカンダリ クラスタをセットアップします。
- プライマリ クラスタからセカンダリ クラスタにデータをレプリケートします。
- クラスターを監視します。
- DRスイッチオーバーを実行します。
一方、このドキュメントでは、セカンダリ クラスタでビジネス データをクエリする方法と、プライマリ クラスタとセカンダリ クラスタの間で双方向レプリケーションを実行する方法についても説明します。
TiCDC に基づいてプライマリ クラスタとセカンダリ クラスタをセットアップする
アーキテクチャ
前述のアーキテクチャには、プライマリ クラスタとセカンダリ クラスタの 2 つの TiDB クラスタが含まれています。
- プライマリ クラスター: リージョン 1 で実行され、3 つのレプリカを持つアクティブなクラスター。このクラスターは読み取りおよび書き込みリクエストを処理します。
- セカンダリ クラスター: リージョン 2 で実行され、TiCDC を介してプライマリ クラスターからデータをレプリケートするスタンバイ クラスター。
この DRアーキテクチャはシンプルで使いやすいです。 DR システムは地域的な障害に耐えることができるため、プライマリ クラスタの書き込みパフォーマンスが低下しないことが保証され、セカンダリ クラスタは遅延の影響を受けない一部の読み取り専用ビジネスを処理できます。このソリューションの目標復旧時点 (RPO) は秒単位であり、目標復旧時間 (RTO) は分またはそれより短い場合もあります。これは、多くのデータベース ベンダーが重要な本番システムに対して推奨しているソリューションです。
注記：
- TiKVの「リージョン」データの範囲を意味し、「領域」という用語は物理的な位置を意味します。この 2 つの用語は互換性がありません。
- セカンダリ クラスターにデータをレプリケートするために複数の変更フィードを実行したり、セカンダリ クラスターがすでに存在する状態で別のセカンダリ クラスターを実行したりしないでください。そうしないと、セカンダリ クラスターのデータ トランザクションの整合性が保証されません。
プライマリ クラスタとセカンダリ クラスタをセットアップする
このドキュメントでは、TiDB プライマリ クラスターとセカンダリ クラスターが 2 つの異なるリージョン (リージョン 1 とリージョン 2) にデプロイされています。プライマリ クラスタとセカンダリ クラスタの間には一定のネットワークレイテンシーが存在するため、TiCDC はセカンダリ クラスタと一緒にデプロイされます。 TiCDC をセカンダリ クラスターとともに展開すると、ネットワークレイテンシーの影響を回避でき、最適なレプリケーション パフォーマンスの実現に役立ちます。このドキュメントで提供される例のデプロイメント トポロジは次のとおりです (1 つのコンポーネントノードが 1 つのサーバーにデプロイされます)。
| リージョン | ホスト | クラスタ | 成分 |
|---|---|---|---|
| リージョン1 | 10.0.1.9 | 主要な | Monitor、Grafana、または AlterManager |
| リージョン2 | 10.0.1.11 | 二次 | Monitor、Grafana、または AlterManager |
| リージョン1 | 10.0.1.1/10.0.1.2/10.0.1.3 | 主要な | PD |
| リージョン2 | 10.1.1.1/10.1.1.2/10.1.1.3 | 二次 | PD |
| リージョン2 | 10.1.1.9/10.1.1.10 | 主要な | TiCDC |
| リージョン1 | 10.0.1.4/10.0.1.5 | 主要な | TiDB |
| リージョン2 | 10.1.1.4/10.1.1.5 | 二次 | TiDB |
| リージョン1 | 10.0.1.6/10.0.1.7/10.0.1.8 | 主要な | TiKV |
| リージョン2 | 10.1.1.6/10.1.1.7/10.1.1.8 | 二次 | TiKV |
サーバー構成については、次のドキュメントを参照してください。
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 プライマリ クラスターとセカンダリ クラスターをセットアップした後、まずプライマリ クラスターからセカンダリ クラスターにデータを移行し、次にレプリケーション タスクを作成して、リアルタイムの変更データをプライマリ クラスターからセカンダリ クラスターにレプリケートします。
外部storageを選択する
外部storageは、データの移行やリアルタイムの変更データのレプリケーション時に使用されます。 Amazon S3 をお勧めします。 TiDB クラスターが自社構築のデータセンターにデプロイされている場合は、次の方法をお勧めします。
- バックアップstorageシステムとしてMinIOを構築し、S3 プロトコルを使用してデータを MinIO にバックアップします。
- ネットワーク ファイル システム (NAS など) ディスクを br コマンド ライン ツール、TiKV、および TiCDC インスタンスにマウントし、POSIX ファイル システム インターフェイスを使用してバックアップ データを対応する NFS ディレクトリに書き込みます。
次の例では、storageシステムとして MinIO を使用していますが、これは参照のみを目的としています。 MinIO をリージョン 1 またはリージョン 2 にデプロイするには、別のサーバーを準備する必要があることに注意してください。
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 &
前述のコマンドは、1 つのノードで MinIOサーバーを起動し、Amazon S3 サービスをシミュレートします。コマンドのパラメータは次のように構成されます。
endpoint：http://10.0.1.10:6060/access-key：miniosecret-access-key：miniostoragebucketbackupredo
リンクは次のとおりです。
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)注記：
本番クラスターでは、GC を無効にしてバックアップを実行すると、クラスターのパフォーマンスに影響を与える可能性があります。パフォーマンスの低下を避けるために、オフピーク時間にデータをバックアップし、
RATE_LIMITを適切な値に設定することをお勧めします。バックアップデータ。アップストリーム クラスターで
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"変更フィード構成の詳細については、 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) をクエリします。mysql> show master status; +-------------+--------------------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +-------------+--------------------+--------------+------------------+-------------------+ | tidb-binlog | 438223974697009153 | | | | +-------------+--------------------+--------------+------------------+-------------------+ 1 row in set (0.33 sec)条件
TSO >= Positionを満たすまで変更フィードdr-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を作成します。チェンジフィードは現在時刻からデータのレプリケーションを開始します。ビジネスアプリケーションのデータベースアクセス構成を変更します。ビジネス アプリケーションを再起動して、セカンダリ クラスターにアクセスできるようにします。
業務アプリケーションが正常に動作しているか確認してください。
前述の手順を繰り返すことで、以前のプライマリ クラスタ構成とセカンダリ クラスタ構成を復元できます。
災害時の1次系と2次系の切り替え
プライマリ クラスタが配置されているリージョンで停電などの災害が発生すると、プライマリ クラスタとセカンダリ クラスタ間のレプリケーションが突然中断される可能性があります。その結果、セカンダリ クラスタのデータはプライマリ クラスタと不整合になります。
セカンダリ クラスタをトランザクション整合性のある状態に復元します。具体的には、リージョン 2 の任意の TiCDC ノードで次のコマンドを実行して、REDO ログをセカンダリ クラスターに適用します。
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 内の REDO ログが保存されるパス--tmp-dir: Amazon S3 から REDO ログをダウンロードするためのキャッシュ ディレクトリ--sink-uri: セカンダリクラスタのアドレス
ビジネスアプリケーションのデータベースアクセス構成を変更します。ビジネス アプリケーションを再起動して、セカンダリ クラスターにアクセスできるようにします。
業務アプリケーションが正常に動作しているか確認してください。
プライマリ クラスタとセカンダリ クラスタを再構築する
プライマリ クラスターで発生した災害が解決されるか、プライマリ クラスターが一時的に回復できない後は、セカンダリ クラスターのみがプライマリ クラスターとして機能するため、TiDB クラスターは脆弱になります。システムの信頼性を維持するには、DR クラスターを再構築する必要があります。
TiDB プライマリ クラスタとセカンダリ クラスタを再構築するには、新しいクラスタをデプロイして新しい DR システムを形成します。詳細については、次のドキュメントを参照してください。
- プライマリ クラスタとセカンダリ クラスタをセットアップする
- プライマリ クラスタからセカンダリ クラスタにデータをレプリケートする
- 前述の手順が完了したら、新しいプライマリ クラスターを作成するには、 プライマリとセカンダリの切り替えを参照してください。
注記：
プライマリ クラスタとセカンダリ クラスタ間のデータの不整合を解決できる場合は、新しいクラスタを展開する代わりに、修復したクラスタを使用して DR システムを再構築できます。
セカンダリ クラスター上のビジネス データをクエリする
プライマリ - セカンダリ DR シナリオでは、待機時間を気にしないクエリを実行するために、セカンダリ クラスターが読み取り専用クラスターとして使用されるのが一般的です。 TiDB は、プライマリ - セカンダリ DR ソリューションによってこの機能も提供します。
変更フィードを作成するときは、構成ファイルで同期ポイント機能を有効にします。次に、変更フィードは、セカンダリ クラスターでSET GLOBAL tidb_external_ts = @@tidb_current_ts実行することによって、セカンダリ クラスターにレプリケートされた一貫性のあるスナップショット ポイントを定期的に ( sync-point-intervalで) 設定します。
セカンダリ クラスターからデータをクエリするには、ビジネス アプリケーションで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アーキテクチャでは、セカンダリ クラスタは 1 つの変更フィードからのデータのみをレプリケートできます。そうしないと、セカンダリ クラスターのデータ トランザクションの整合性が保証されません。
プライマリクラスタとセカンダリクラスタの間で双方向レプリケーションを実行します。
この DR シナリオでは、2 つのリージョンの TiDB クラスターが互いの災害復旧クラスターとして機能できます。ビジネス トラフィックはリージョン構成に基づいて対応する TiDB クラスターに書き込まれ、2 つの TiDB クラスターは互いのデータをバックアップします。
双方向レプリケーション機能を使用すると、2 つのリージョンにある TiDB クラスターが相互にデータをレプリケートできます。この DR ソリューションは、データのセキュリティと信頼性を保証し、データベースの書き込みパフォーマンスも保証します。計画的な DR スイッチオーバーでは、新しい変更フィードを開始する前に実行中の変更フィードを停止する必要がないため、運用とメンテナンスが簡素化されます。
双方向 DR クラスターを構築するには、 TiCDC 双方向レプリケーションを参照してください。
トラブルシューティング
前の手順で問題が発生した場合は、まずTiDB よくある質問で問題の解決策を見つけることができます。問題が解決しない場合は、 バグを報告を実行できます。