バックアップと復元に関するよくある質問

このドキュメントには、TiDB バックアップ & リストア (BR) に関するよくある質問 (FAQ) と解決策がリストされています。

誤ってデータを削除または更新した後、すぐにデータを復元するにはどうすればよいですか?

TiDB v6.4.0 にはフラッシュバック機能が導入されています。この機能を使用すると、GC 時間内で指定した時点までデータを迅速にリカバリできます。したがって、誤操作が発生した場合、この機能を使用してデータを回復できます。詳細はフラッシュバッククラスタおよびフラッシュバックデータベースを参照してください。

TiDB v5.4.0 以降のバージョンでは、負荷の高いクラスターでバックアップ タスクが実行されると、バックアップ タスクの速度が遅くなるのはなぜですか?

TiDB v5.4.0 以降、 BR にはバックアップ タスクの自動調整機能が導入されています。 v5.4.0 以降のバージョンのクラスターの場合、この機能はデフォルトで有効になっています。クラスターのワークロードが重い場合、この機能はバックアップ タスクで使用されるリソースを制限し、オンライン クラスターへの影響を軽減します。詳細については、 バックアップの自動調整を参照してください。

TiKV は自動調整動的構成をサポートしています。クラスターを再起動せずに、次の方法でこの機能を有効または無効にできます。

  • 自動調整を無効にする: TiKV 構成項目backup.enable-auto-tuneからfalseを設定します。
  • 自動調整を有効にする: backup.enable-auto-tunetrueを設定します。 v5.3.x から v5.4.0 以降のバージョンにアップグレードされたクラスターの場合、自動調整機能はデフォルトで無効になっています。手動で有効にする必要があります。

tikv-ctlを使用して自動調整を有効または無効にするには、 自動調整を使用するを参照してください。

さらに、自動調整により、バックアップ タスクで使用されるデフォルトのスレッド数が減少します。詳細については、 backup.num-threads ](/tikv-configuration-file.md#num-threads-1)」を参照してください。したがって、Grafana ダッシュボードでは、バックアップ タスクによって使用される速度、CPU 使用率、および I/O リソース使用率が v5.4.0 より前のバージョンよりも低くなります。 v5.4.0 より前では、デフォルト値backup.num-threadsCPU * 0.75でした。つまり、バックアップ タスクによって使用されるスレッドの数が論理 CPU コアの 75% を占めます。その最大値は32でした。 v5.4.0 以降、この構成項目のデフォルト値はCPU * 0.5 、最大値は8です。

オフライン クラスターでバックアップ タスクを実行する場合、バックアップを高速化するために、 tikv-ctlを使用してbackup.num-threadsの値をより大きな数値に変更できます。

PITRの問題

PITRクラスターフラッシュバックの違いは何ですか?

ユースケースの観点から見ると、PITR は通常、クラスターが完全にサービス停止になった場合、またはデータが破損して他のソリューションを使用して回復できない場合に、クラスターのデータを指定された時点に復元するために使用されます。 PITR を使用するには、データ回復用の新しいクラスターが必要です。クラスターのフラッシュバック機能は、ユーザーの誤操作やその他の要因によって引き起こされるデータ エラーのシナリオ向けに特別に設計されており、データ エラーが発生する前の最新のタイムスタンプにクラスターのデータをインプレースで復元できます。

ほとんどの場合、フラッシュバックは、RPO (ゼロに近い) と RTO がはるかに短いため、人的ミスによって引き起こされたデータ エラーに対しては、PITR よりも優れた回復ソリューションです。ただし、クラスターが完全に使用できない場合、現時点ではフラッシュバックを実行できないため、この場合クラスターを回復する唯一のソリューションは PITR です。したがって、PITR は、フラッシュバックよりも RPO (最大 5 分) と RTO が長いにもかかわらず、データベースのディザスタ リカバリ戦略を策定する際には常に必須のソリューションです。

アップストリーム データベースが物理インポート モードでTiDB Lightningを使用してデータをインポートすると、ログ バックアップ機能が使用できなくなります。なぜ?

現在、ログ バックアップ機能はTiDB Lightningに完全には適合していません。そのため、 TiDB Lightningの物理モードでインポートしたデータはログデータにバックアップできません。

ログ バックアップ タスクを作成するアップストリーム クラスターでは、データのインポートにTiDB Lightning物理モードを使用しないでください。代わりに、 TiDB Lightning論理モードを使用できます。物理モードを使用する必要がある場合は、インポートの完了後にスナップショット バックアップを実行して、PITR をスナップショット バックアップ後の時点に復元できるようにします。

クラスターはネットワーク パーティションの障害から回復しましたが、ログ バックアップ タスクの進行状況のチェックポイントはまだ再開されません。なぜ?

問題: #13126

クラスター内でネットワーク パーティションに障害が発生すると、バックアップ タスクはログのバックアップを続行できなくなります。一定の再試行時間が経過すると、タスクはERROR状態に設定されます。この時点で、バックアップ タスクは停止しました。

この問題を解決するには、 br log resumeコマンドを手動で実行してログ バックアップ タスクを再開する必要があります。

br restore pointコマンドを使用してダウンストリーム クラスターを復元した後、 TiFlashからデータにアクセスできなくなります。どうすればいいですか?

現在、PITR は復元フェーズ中にTiFlashにデータを直接書き込むことをサポートしていません。代わりに、br コマンドライン ツールはALTER TABLE table_name SET TIFLASH REPLICA *** DDL を実行してデータを複製します。したがって、 TiFlashレプリカは、PITR がデータの復元を完了した直後には使用できません。代わりに、TiKV ノードからデータがレプリケートされるまで一定期間待機する必要があります。レプリケーションの進行状況を確認するには、 INFORMATION_SCHEMA.tiflash_replica表のprogress情報を確認します。

ログ バックアップ タスクのstatus ERRORになった場合はどうすればよいですか?

ログ バックアップ タスク中に失敗し、再試行しても回復できない場合、タスク ステータスはERRORになります。以下は例です。

br log status --pd x.x.x.x:2379 ● Total 1 Tasks. > #1 < name: task1 status: ○ ERROR start: 2022-07-25 13:49:02.868 +0000 end: 2090-11-18 14:07:45.624 +0000 storage: s3://tmp/br-log-backup0ef49055-5198-4be3-beab-d382a2189efb/Log speed(est.): 0.00 ops/s checkpoint[global]: 2022-07-25 14:46:50.118 +0000; gap=11h31m29s error[store=1]: KV:LogBackup:RaftReq error-happen-at[store=1]: 2022-07-25 14:54:44.467 +0000; gap=11h23m35s error-message[store=1]: retry time exceeds: and error failed to get initial snapshot: failed to get the snapshot (region_id = 94812): Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region 94812" read_index_not_ready { reason: "can not read index due to merge" region_id: 94812 }: failed to get initial snapshot: failed to get the snapshot (region_id = 94812): Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region 94812" read_index_not_ready { reason: "can not read index due to merge" region_id: 94812 }: failed to get initial snapshot: failed to get the snapshot (region_id = 94812): Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region 94812" read_index_not_ready { reason: "can not read index due to merge" region_id: 94812 }

この問題を解決するには、エラー メッセージで原因を確認し、指示に従って実行してください。問題が解決されたら、次のコマンドを実行してタスクを再開します。

br log resume --task-name=task1 --pd x.x.x.x:2379

バックアップ タスクが再開された後、 br log status使用してステータスを確認できます。タスクのステータスがNORMALになっても、バックアップ タスクは続行されます。

● Total 1 Tasks. > #1 < name: task1 status: ● NORMAL start: 2022-07-25 13:49:02.868 +0000 end: 2090-11-18 14:07:45.624 +0000 storage: s3://tmp/br-log-backup0ef49055-5198-4be3-beab-d382a2189efb/Log speed(est.): 15509.75 ops/s checkpoint[global]: 2022-07-25 14:46:50.118 +0000; gap=6m28s

注記:

この機能は、複数のバージョンのデータをバックアップします。長時間バックアップ タスクが失敗し、ステータスがERRORになると、このタスクのチェックポイント データはsafe pointに設定され、 safe pointのデータは 24 時間以内にガベージ コレクションされません。したがって、バックアップ タスクは、エラーが再開された後、最後のチェックポイントから続行されます。タスクが 24 時間以上失敗し、最後のチェックポイント データがガベージ コレクションされている場合、タスクを再開するとエラーが報告されます。この場合、 br log stopコマンドを実行して最初にタスクを停止し、次に新しいバックアップ タスクを開始することしかできません。

br log resumeコマンドを使用して一時停止されたタスクを再開するときに、エラー メッセージErrBackupGCSafepointExceededが返された場合はどうすればよいですか?

Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepoint 433193092308795392 exceed TS 433177834291200000: [BR:Backup:ErrBackupGCSafepointExceeded]backup GC safepoint exceeded

ログ バックアップ タスクを一時停止した後、MVCC データがガベージ コレクションされるのを防ぐために、一時停止中のタスク プログラムは現在のチェックポイントをサービス セーフポイントとして自動的に設定します。これにより、24 時間以内に生成された MVCC データが確実に保持されます。バックアップ チェックポイントの MVCC データが生成されてから 24 時間以上経過している場合、チェックポイントのデータはガベージ コレクションされ、バックアップ タスクは再開できません。

この問題に対処するには、 br log stop使用して現在のタスクを削除し、 br log start使用してログ バックアップ タスクを作成します。同時に、後続の PITR 用に完全バックアップを実行できます。

機能の互換性の問題

br コマンドライン ツールを使用して復元されたデータが TiCDC またはDrainerの上流クラスターに複製できないのはなぜですか?

  • BRを使用して復元されたデータは、ダウンストリームに複製できません。これは、 BR がSST ファイルを直接インポートしますが、現在ダウンストリーム クラスターがアップストリームからこれらのファイルを取得できないためです。

  • v4.0.3 より前では、リストア中に生成された DDL ジョブにより、 TiCDC/ Drainerで予期しない DDL 実行が発生する可能性がありました。したがって、 TiCDC/ Drainerの上流クラスターでリストアを実行する必要がある場合は、 br コマンドライン ツールを使用してリストアされたすべてのテーブルを TiCDC/ Drainerブロック リストに追加します。

filter.rulesを使用して TiCDC のブロック リストを構成し、 syncer.ignore-tableを使用してDrainerのブロック リストを構成できます。

復元中にnew_collation_enabled不一致が報告されるのはなぜですか?

TiDB v6.0.0 以降、デフォルト値new_collations_enabled_on_first_bootstrapfalseからtrueに変更されました。 BR は、上流クラスタのmysql.tidbテーブル内のnew_collation_enabled設定をバックアップし、この設定の値が上流クラスタと下流クラスタ間で一貫しているかどうかを確認します。値が一貫している場合、 BR は上流クラスターにバックアップされたデータを下流クラスターに安全に復元します。値が矛盾している場合、 BR はデータの復元を実行せず、エラーを報告します。

以前のバージョンの v6.0.0 の TiDB クラスターにデータをバックアップしており、このデータを v6.0.0 以降のバージョンの TiDB クラスターに復元するとします。この状況では、値new_collations_enabled_on_first_bootstrapがアップストリーム クラスターとダウンストリーム クラスター間で一致しているかどうかを手動で確認する必要があります。

  • 値が一貫している場合は、restore コマンドに--check-requirements=falseを追加して、この構成チェックをスキップできます。
  • 値に一貫性がない場合、リストアを強制的に実行すると、 BR はデータ検証エラーを報告します。

配置ルールをクラスターに復元するとエラーが発生するのはなぜですか?

v6.0.0 より前では、 BR は配置ルールをサポートしていません。 v6.0.0 以降、 BR は配置ルールをサポートし、配置ルールのバックアップおよび復元モードを制御するコマンド ライン オプション--with-tidb-placement-mode=strict/ignoreを導入します。デフォルト値strictでは、 BR は配置ルールをインポートして検証しますが、値がignoreの場合はすべての配置ルールを無視します。

データ復元の問題

Io(Os...)エラーを処理するにはどうすればよいですか?

これらの問題のほとんどは、TiKV がディスクにデータを書き込むときに発生するシステム コール エラーです (たとえば、 Io(Os {code: 13, kind: PermissionDenied...})またはIo(Os {code: 2, kind: NotFound...}) )。

このような問題に対処するには、まずバックアップ ディレクトリのマウント方法とファイル システムを確認し、別のフォルダまたは別のハードディスクにデータをバックアップしてみてください。

たとえば、 sambaによって構築されたネットワーク ディスクにデータをバックアップするときに、 Code: 22(invalid argument)エラーが発生する可能性があります。

rpc error: code = Unavailable desc =...復元中にエラーが発生しました。

このエラーは、復元するクラスターの容量が不十分な場合に発生する可能性があります。このクラスターの監視メトリクスまたは TiKV ログを確認することで、原因をさらに確認できます。

この問題に対処するには、クラスター リソースをスケールアウトし、復元中の同時実行性を減らし、 RATE_LIMITオプションを有効にしてみてください。

リストアが失敗しthe entry too large, the max entry size is 6291456, the size of data is 7690800 」というエラー メッセージが表示された場合はどうすればよいですか?

--ddl-batch-size128 、またはそれより小さい値を設定すると、バッチで作成されるテーブルの数を減らすことができます。

BRを使用して1より大きい--ddl-batch-sizeの値を持つバックアップ データを復元すると、TiDB はテーブル作成の DDL ジョブを TiKV によって維持される DDL ジョブ キューに書き込みます。現時点では、ジョブ メッセージの最大値はデフォルトで6 MBであるため、TiDB によって一度に送信されるすべてのテーブル スキーマの合計サイズは 6 MB を超えてはなりません (この値を変更することはお勧めできません。詳細については、 txn-entry-size-limitと を参照してください)。 raft-entry-max-size )。したがって、 --ddl-batch-size過度に大きな値に設定すると、TiDB によって一度にバッチで送信されるテーブルのスキーマ サイズが指定値を超え、 BRでentry too large, the max entry size is 6291456, the size of data is 7690800エラーが報告されます。

localstorageを使用する場合、バックアップ ファイルはどこに保存されますか?

注記:

BRまたは TiKV ノードにネットワーク ファイル システム (NFS) がマウントされていない場合、または Amazon S3、GCS、または Azure Blob Storage プロトコルをサポートする外部storageを使用している場合、 BRによってバックアップされたデータは各 TiKV ノードで生成されます。バックアップ データは各ノードのローカル ファイル システムに分散しているため、これはBRを展開する推奨方法ではないことに注意してください。バックアップデータを採取すると、データの冗長化や運用保守上の問題が発生する可能性があります。一方、バックアップ データを収集する前にデータを直接復元すると、 SST file not foundエラーが発生します。

ローカルstorageを使用すると、 BRが実行されているノードにbackupmetaが生成され、各リージョンのLeaderノードにバックアップ ファイルが生成されます。

データの復元中にcould not read local://...:download sst failedエラー メッセージが返された場合はどうすればよいですか?

データを復元する場合、各ノードはすべてのバックアップ ファイル (SST ファイル) にアクセスできる必要があります。デフォルトでは、 localstorageが使用されている場合、バックアップ ファイルが異なるノードに分散しているため、データを復元できません。したがって、各 TiKV ノードのバックアップ ファイルを他の TiKV ノードにコピーする必要があります。バックアップ データは、Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage、または NFS に保存することをお勧めします

root を使用してbrを実行しようとしても無駄であった場合でも、 Permission denied 」またはNo such file or directoryエラーを処理するにはどうすればよいですか?

TiKV がバックアップ ディレクトリにアクセスできるかどうかを確認する必要があります。データをバックアップするには、TiKV に書き込み権限があるかどうかを確認してください。データを復元する場合は、読み取り権限があるかどうかを確認してください。

バックアップ操作中に、storageメディアがローカル ディスクまたはネットワーク ファイル システム (NFS) である場合、 brを起動するユーザーと TiKV を起動するユーザーが一致していることを確認してください ( brと TiKV が別のマシン上にある場合、ユーザーは' UID は一貫している必要があります)。そうしないと、 Permission denied問題が発生する可能性があります。

バックアップ ファイル (SST ファイル) は TiKV によって保存されるため、 rootユーザーとしてbrを実行すると、ディスク権限が原因で失敗する可能性があります。

注記:

データの復元中に同じ問題が発生する可能性があります。 SST ファイルを初めて読み取るときに、読み取り権限が検証されます。 DDL の実行時間は、アクセス許可の確認とbrの実行の間に長い間隔がある可能性があることを示唆しています。長時間待機すると、エラー メッセージPermission denied表示される場合があります。

したがって、データを復元する前に、次の手順に従って権限を確認することをお勧めします。

  1. プロセス クエリの Linux コマンドを実行します。

    ps aux | grep tikv-server

    出力は次のとおりです。

    tidb_ouo 9235 10.9 3.8 2019248 622776 ? Ssl 08:28 1:12 bin/tikv-server --addr 0.0.0.0:20162 --advertise-addr 172.16.6.118:20162 --status-addr 0.0.0.0:20188 --advertise-status-addr 172.16.6.118:20188 --pd 172.16.6.118:2379 --data-dir /home/user1/tidb-data/tikv-20162 --config conf/tikv.toml --log-file /home/user1/tidb-deploy/tikv-20162/log/tikv.log tidb_ouo 9236 9.8 3.8 2048940 631136 ? Ssl 08:28 1:05 bin/tikv-server --addr 0.0.0.0:20161 --advertise-addr 172.16.6.118:20161 --status-addr 0.0.0.0:20189 --advertise-status-addr 172.16.6.118:20189 --pd 172.16.6.118:2379 --data-dir /home/user1/tidb-data/tikv-20161 --config conf/tikv.toml --log-file /home/user1/tidb-deploy/tikv-20161/log/tikv.log

    または、次のコマンドを実行することもできます。

    ps aux | grep tikv-server | awk '{print $1}'

    出力は次のとおりです。

    tidb_ouo tidb_ouo
  2. tiupコマンドを使用して、クラスターの起動情報を照会します。

    tiup cluster list

    出力は次のとおりです。

    [root@Copy-of-VM-EE-CentOS76-v1 br]# tiup cluster list Starting component `cluster`: /root/.tiup/components/cluster/v1.5.2/tiup-cluster list Name User Version Path PrivateKey ---- ---- ------- ---- ---------- tidb_cluster tidb_ouo v5.0.2 /root/.tiup/storage/cluster/clusters/tidb_cluster /root/.tiup/storage/cluster/clusters/tidb_cluster/ssh/id_rsa
  3. バックアップディレクトリの権限を確認してください。たとえば、 backupはバックアップ データstorageの場合です。

    ls -al backup

    出力は次のとおりです。

    [root@Copy-of-VM-EE-CentOS76-v1 user1]# ls -al backup total 0 drwxr-xr-x 2 root root 6 Jun 28 17:48 . drwxr-xr-x 11 root root 310 Jul 4 10:35 ..

    ステップ 2 の出力から、 tikv-serverインスタンスがユーザーtidb_ouoによって開始されたことがわかります。しかし、ユーザーtidb_ouobackupに対する書き込み権限がありません。したがって、バックアップは失敗します。

mysqlスキーマ内のテーブルが復元されないのはなぜですか?

BR v5.1.0 以降、完全バックアップを実行すると、 BR はmysqlスキーマ内のテーブルをバックアップします。 BR v6.2.0 より前のデフォルト設定では、 BR はユーザー データのみを復元し、 mysqlスキーマ内のテーブルは復元しません。

ユーザーがmysqlスキーマ (システム テーブルではない) で作成したテーブルを復元するには、 テーブルフィルター使用してテーブルを明示的に含めます。次の例は、 BR が通常の復元を実行するときにmysql.usertableテーブルを復元する方法を示しています。

br restore full -f '*.*' -f '!mysql.*' -f 'mysql.usertable' -s $external_storage_url --with-sys-table

前述のコマンドでは、

  • -f '*.*'はデフォルトのルールを上書きするために使用されます
  • -f '!mysql.*'特に指定がない限り、 BR にmysqlテーブルを復元しないよう指示します。
  • -f 'mysql.usertable' mysql.usertableを復元する必要があることを示します。

mysql.usertableのみを復元する必要がある場合は、次のコマンドを実行します。

br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table

テーブルフィルターを設定した場合でも、 BR は次のシステム テーブルを復元しないことに注意してください。

復元中にcannot find rewrite ruleエラーに対処するにはどうすればよいですか?

バックアップ データ内の他のテーブルと同じ名前を共有しているものの、構造が一貫していないテーブルが復元クラスタ内に存在するかどうかを調べます。ほとんどの場合、この問題は、復元クラスターのテーブルにインデックスがないことが原因で発生します。推奨されるアプローチは、最初に復元クラスター内のそのようなテーブルを削除してから、復元を再試行することです。

バックアップと復元についてその他知っておきたいこと

バックアップデータのサイズはどのくらいですか?バックアップのレプリカはありますか?

データのバックアップ中に、各リージョンのLeaderノード上にバックアップ ファイルが生成されます。バックアップのサイズはデータ サイズと等しく、冗長レプリカはありません。したがって、合計データ サイズは、TiKV データの合計数をレプリカの数で割ったものとほぼなります。

ただし、ローカルstorageからデータを復元する場合は、各 TiKV がすべてのバックアップ ファイルにアクセスできる必要があるため、レプリカの数は TiKV ノードの数と同じになります。

BRを使用したバックアップまたは復元後、監視ノードに表示されるディスク使用量が一貫していないのはなぜですか?

この不一致は、バックアップで使用されるデータ圧縮率がリストアで使用されるデフォルトの圧縮率と異なることが原因で発生します。チェックサムが成功した場合は、この問題を無視してかまいません。

BR がバックアップ データを復元した後、テーブルに対してANALYZEステートメントを実行して、テーブルとインデックス上の TiDB の統計を更新する必要がありますか?

BR は統計をバックアップしません (v4.0.9 を除く)。したがって、バックアップ データを復元した後、手動でANALYZE TABLEを実行するか、TiDB が自動的に実行するANALYZEを待つ必要があります。

v4.0.9 では、 BR はデフォルトで統計をバックアップするため、メモリを大量に消費します。バックアップ プロセスが確実に正常に完了するように、v4.0.10 以降、統計のバックアップはデフォルトで無効になっています。

テーブルでANALYZE実行しない場合、統計が不正確であるため、TiDB は最適な実行プランを選択できません。クエリのパフォーマンスが重要な問題ではない場合は、 ANALYZE無視してかまいません。

単一クラスターのデータを復元するために、複数の復元タスクを同時に開始できますか?

以下の理由により、単一クラスターのデータを復元するために複数の復元タスクを同時に開始することは強く推奨されません

  • BR がデータを復元すると、PD の一部のグローバル構成が変更されます。したがって、データの復元のために複数の復元タスクを同時に開始すると、これらの構成が誤って上書きされ、クラスターの状態が異常になる可能性があります。
  • BR はデータの復元に大量のクラスター リソースを消費するため、実際には、復元タスクを並行して実行しても、復元速度は限られた範囲でしか向上しません。
  • データの復元のために複数の復元タスクを並行して実行するテストは行われていないため、成功するかどうかは保証されません。

BR はテーブルのSHARD_ROW_ID_BITSおよびPRE_SPLIT_REGIONS情報をバックアップしますか?復元されたテーブルには複数のリージョンがありますか?

はい。 BRはテーブルのSHARD_ROW_ID_BITSおよびPRE_SPLIT_REGIONS情報をバックアップします。復元されたテーブルのデータも複数のリージョンに分割されます。

リカバリプロセスが中断された場合、すでにリカバリされたデータを削除して、リカバリを再度開始する必要がありますか?

いいえ、その必要はありません。 v7.1.0 以降、 BR はブレークポイントからのデータの再開をサポートします。予期せぬ状況によりリカバリが中断された場合は、リカバリタスクを再起動するだけで、中断したところから再開されます。

リカバリの完了後、特定のテーブルを削除して、再度リカバリすることはできますか?

はい、特定のテーブルを削除した後、再度復元できます。ただし、回復できるのはDROP TABLEまたはTRUNCATE TABLEステートメントを使用して削除されたテーブルのみであり、 DELETE FROMステートメントでは回復できないことに注意してください。これは、 DELETE FROM削除するデータをマークするために MVCC バージョンを更新するだけであり、実際のデータ削除は GC 後に発生するためです。

このページは役に立ちましたか?

Playground
新規
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.