- TiDBについて
- クイックスタート
- 発展させる
- 概要
- クイックスタート
- TiDB Cloud(開発者層) で TiDB クラスターを構築する
- TiDB の CRUD SQL
- TiDB でシンプルな CRUD アプリを構築する
- 応用例
- TiDB に接続する
- データベース スキーマの設計
- 書き込みデータ
- データの読み取り
- 取引
- 最適化
- トラブルシューティング
- 参照
- 書店のサンプル アプリケーション
- ガイドライン
- アーカイブされたドキュメント
- クラウドネイティブ開発環境
- サードパーティのサポート
- デプロイ
- 移行する
- 管理
- 監視と警告
- トラブルシューティング
- TiDB トラブルシューティング マップ
- 遅いクエリを特定する
- 遅いクエリを分析する
- SQL 診断
- Top SQLを使用して高価なクエリを特定する
- ログを使用して高価なクエリを特定する
- ステートメント要約表
- ホットスポットの問題のトラブルシューティング
- 増加した読み取りおよび書き込み遅延のトラブルシューティング
- クラスターのオンサイト情報の保存と復元
- クラスタ セットアップのトラブルシューティング
- 高いディスク I/O 使用率のトラブルシューティング
- ロック競合のトラブルシューティング
- TiFlash のトラブルシューティング
- オプティミスティック トランザクションでの書き込み競合のトラブルシューティング
- データとインデックス間の不一致のトラブルシューティング
- 性能チューニング
- チューニングガイド
- Configuration / コンフィグレーションのチューニング
- システムのチューニング
- ソフトウェアのチューニング
- Configuration / コンフィグレーション
- コプロセッサ キャッシュ
- SQL チューニング
- チュートリアル
- TiDB ツール
- 概要
- ユースケース
- ダウンロード
- TiUP
- ドキュメンテーション マップ
- 概要
- 用語と概念
- TiUP コンポーネントの管理
- FAQ
- トラブルシューティングガイド
- コマンドリファレンス
- 概要
- TiUP コマンド
- TiUP クラスタ コマンド
- 概要
- tiup cluster audit
- tiup cluster check
- tiup cluster clean
- tiup cluster deploy
- tiup cluster destroy
- tiup cluster disable
- tiup cluster display
- tiup cluster edit-config
- tiup cluster enable
- tiup cluster help
- tiup cluster import
- tiup cluster list
- tiup cluster patch
- tiup cluster prune
- tiup cluster reload
- tiup cluster rename
- tiup cluster replay
- tiup cluster restart
- tiup cluster scale-in
- tiup cluster scale-out
- tiup cluster start
- tiup cluster stop
- tiup cluster template
- tiup cluster upgrade
- TiUP DMコマンド
- TiDB クラスター トポロジ リファレンス
- DM クラスタ トポロジ リファレンス
- ミラー リファレンス ガイド
- TiUP コンポーネント
- PingCAPクリニック診断サービス
- TiDB Operator
- Dumpling
- TiDB Lightning
- TiDB データ移行
- バックアップと復元 (BR)
- Binlog
- TiCDC
- Dumpling
- 同期差分インスペクター
- ティスパーク
- 参照
- クラスタ アーキテクチャ
- 主な監視指標
- セキュリティ
- 権限
- SQL
- SQL 言語の構造と構文
- SQL ステートメント
ADD COLUMN
ADD INDEX
ADMIN
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
ADMIN SHOW TELEMETRY
ALTER DATABASE
ALTER INDEX
ALTER INSTANCE
ALTER PLACEMENT POLICY
ALTER TABLE
ALTER TABLE COMPACT
ALTER USER
ANALYZE TABLE
BACKUP
BATCH
BEGIN
CHANGE COLUMN
COMMIT
CHANGE DRAINER
CHANGE PUMP
CREATE [GLOBAL|SESSION] BINDING
CREATE DATABASE
CREATE INDEX
CREATE PLACEMENT POLICY
CREATE ROLE
CREATE SEQUENCE
CREATE TABLE LIKE
CREATE TABLE
CREATE USER
CREATE VIEW
DEALLOCATE
DELETE
DESC
DESCRIBE
DO
DROP [GLOBAL|SESSION] BINDING
DROP COLUMN
DROP DATABASE
DROP INDEX
DROP PLACEMENT POLICY
DROP ROLE
DROP SEQUENCE
DROP STATS
DROP TABLE
DROP USER
DROP VIEW
EXECUTE
EXPLAIN ANALYZE
EXPLAIN
FLASHBACK TABLE
FLUSH PRIVILEGES
FLUSH STATUS
FLUSH TABLES
GRANT <privileges>
GRANT <role>
INSERT
KILL [TIDB]
LOAD DATA
LOAD STATS
MODIFY COLUMN
PREPARE
RECOVER TABLE
RENAME INDEX
RENAME TABLE
REPLACE
RESTORE
REVOKE <privileges>
REVOKE <role>
ROLLBACK
SELECT
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET PASSWORD
SET ROLE
SET TRANSACTION
SET [GLOBAL|SESSION] <variable>
SHOW ANALYZE STATUS
SHOW [BACKUPS|RESTORES]
SHOW [GLOBAL|SESSION] BINDINGS
SHOW BUILTINS
SHOW CHARACTER SET
SHOW COLLATION
SHOW [FULL] COLUMNS FROM
SHOW CONFIG
SHOW CREATE PLACEMENT POLICY
SHOW CREATE SEQUENCE
SHOW CREATE TABLE
SHOW CREATE USER
SHOW DATABASES
SHOW DRAINER STATUS
SHOW ENGINES
SHOW ERRORS
SHOW [FULL] FIELDS FROM
SHOW GRANTS
SHOW INDEX [FROM|IN]
SHOW INDEXES [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW MASTER STATUS
SHOW PLACEMENT
SHOW PLACEMENT FOR
SHOW PLACEMENT LABELS
SHOW PLUGINS
SHOW PRIVILEGES
SHOW [FULL] PROCESSSLIST
SHOW PROFILES
SHOW PUMP STATUS
SHOW SCHEMAS
SHOW STATS_HEALTHY
SHOW STATS_HISTOGRAMS
SHOW STATS_META
SHOW STATUS
SHOW TABLE NEXT_ROW_ID
SHOW TABLE REGIONS
SHOW TABLE STATUS
SHOW [FULL] TABLES
SHOW [GLOBAL|SESSION] VARIABLES
SHOW WARNINGS
SHUTDOWN
SPLIT REGION
START TRANSACTION
TABLE
TRACE
TRUNCATE
UPDATE
USE
WITH
- データ型
- 関数と演算子
- クラスタ化インデックス
- 制約
- 生成された列
- SQL モード
- テーブル属性
- 取引
- ガベージ コレクション (GC)
- ビュー
- パーティショニング
- 一時テーブル
- キャッシュされたテーブル
- 文字セットと照合順序
- SQL の配置規則
- システム テーブル
mysql
- 情報_スキーマ
- 概要
ANALYZE_STATUS
CLIENT_ERRORS_SUMMARY_BY_HOST
CLIENT_ERRORS_SUMMARY_BY_USER
CLIENT_ERRORS_SUMMARY_GLOBAL
CHARACTER_SETS
CLUSTER_CONFIG
CLUSTER_HARDWARE
CLUSTER_INFO
CLUSTER_LOAD
CLUSTER_LOG
CLUSTER_SYSTEMINFO
COLLATIONS
COLLATION_CHARACTER_SET_APPLICABILITY
COLUMNS
DATA_LOCK_WAITS
DDL_JOBS
DEADLOCKS
ENGINES
INSPECTION_RESULT
INSPECTION_RULES
INSPECTION_SUMMARY
KEY_COLUMN_USAGE
METRICS_SUMMARY
METRICS_TABLES
PARTITIONS
PLACEMENT_POLICIES
PROCESSLIST
REFERENTIAL_CONSTRAINTS
SCHEMATA
SEQUENCES
SESSION_VARIABLES
SLOW_QUERY
STATISTICS
TABLES
TABLE_CONSTRAINTS
TABLE_STORAGE_STATS
TIDB_HOT_REGIONS
TIDB_HOT_REGIONS_HISTORY
TIDB_INDEXES
TIDB_SERVERS_INFO
TIDB_TRX
TIFLASH_REPLICA
TIKV_REGION_PEERS
TIKV_REGION_STATUS
TIKV_STORE_STATUS
USER_PRIVILEGES
VIEWS
METRICS_SCHEMA
- UI
- TiDB ダッシュボード
- 概要
- 管理
- アクセス
- 概要ページ
- クラスター情報ページ
- Top SQLページ
- キー ビジュアライザー ページ
- メトリクス関係グラフ
- SQL ステートメントの分析
- スロークエリページ
- クラスタ診断
- 検索ログ ページ
- インスタンスのプロファイリング
- セッションの管理とConfiguration / コンフィグレーション
- FAQ
- CLI
- コマンド ライン フラグ
- Configuration / コンフィグレーションファイルのパラメーター
- システム変数
- ストレージ エンジン
- テレメトリー
- エラーコード
- テーブル フィルター
- トポロジ ラベルごとにレプリカをスケジュールする
- よくある質問
- リリースノート
- すべてのリリース
- リリースのタイムライン
- TiDB のバージョニング
- v6.1
- v6.0
- v5.4
- v5.3
- v5.2
- v5.1
- v5.0
- v4.0
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- 用語集
バックアップと復元に関するFAQ
このドキュメントには、よくある質問(FAQ)とバックアップと復元(BR)に関するソリューションが記載されています。
TiDB v5.4.0以降のバージョンでは、バックアップタスクが高いワークロードの下でクラスタ上で実行される場合、バックアップタスクの速度が遅くなるのはなぜですか?
TiDB v5.4.0以降、BRではバックアップタスクの自動調整機能が導入されています。 v5.4.0以降のバージョンのクラスターの場合、この機能はデフォルトで有効になっています。クラスタのワークロードが重い場合、この機能はバックアップタスクで使用されるリソースを制限して、オンラインクラスタへの影響を軽減します。詳細については、 BRオートチューンを参照してください。
TiKVは動的に構成する自動調整機能をサポートしています。クラスタを再起動せずに、次の方法で機能を有効または無効にできます。
- 自動調整を無効にする:TiKV構成項目
backup.enable-auto-tune
をfalse
に設定します。 - 自動調整を有効にする:
backup.enable-auto-tune
をtrue
に設定します。 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-threads
はCPU * 0.75
でした。つまり、バックアップタスクで使用されるスレッドの数は、論理CPUコアの75%を占めています。最大値は32
でした。 v5.4.0以降、この構成アイテムのデフォルト値はCPU * 0.5
で、最大値は8
です。
オフラインクラスタでバックアップタスクを実行する場合、バックアップを高速化するために、 tikv-ctl
を使用してbackup.num-threads
の値をより大きな数値に変更できます。
エラーメッセージcould not read local://...:download sst failed
場合、データの復元中に何が返されますか?
データを復元する場合、各ノードはすべてのバックアップファイル(SSTファイル)にアクセスできる必要があります。デフォルトでは、 local
のストレージが使用されている場合、バックアップファイルは異なるノードに分散しているため、データを復元することはできません。したがって、各TiKVノードのバックアップファイルを他のTiKVノードにコピーする必要があります。
バックアップ中にNFSディスクをバックアップディスクとしてマウントすることをお勧めします。詳細については、 単一のテーブルをネットワークディスクにバックアップしますを参照してください。
バックアップ操作はクラスタにどの程度の影響を与えますか?
TiDB v5.4.0以降のバージョンの場合、BRは、バックアップタスクで使用されるデフォルトのCPU使用率を削減するだけでなく、ワークロードが重いクラスタのバックアップタスクで使用されるリソースを制限するBRオートチューンつの機能も導入します。したがって、ワークロードが重いv5.4.0クラスタのバックアップタスクにデフォルト構成を使用する場合、クラスタのパフォーマンスに対するタスクの影響は、v5.4.0より前のクラスターの場合よりも大幅に小さくなります。
以下は、単一ノードでの内部テストです。テスト結果は、フルスピードバックアップシナリオでv5.4.0とv5.3.0のデフォルト構成を使用する場合、クラスタのパフォーマンスに対するBRを使用したバックアップの影響がまったく異なることを示しています。詳細なテスト結果は次のとおりです。
- BRがv5.3.0のデフォルト構成を使用すると、書き込み専用ワークロードのQPSが75%削減されます。
- BRがv5.4.0のデフォルト構成を使用すると、同じワークロードのQPSが25%削減されます。ただし、この構成を使用すると、BRを使用したバックアップタスクの期間がそれに応じて長くなります。必要な時間は、v5.3.0構成の1.7倍です。
次のいずれかのソリューションを使用して、バックアップタスクがクラスタのパフォーマンスに与える影響を手動で制御できます。これらの方法は、クラスタへのバックアップタスクの影響を軽減しますが、バックアップタスクの速度も低下させることに注意してください。
--ratelimit
パラメータを使用して、バックアップタスクの速度を制限します。このパラメータは、バックアップファイルを外部ストレージに保存する速度を制限することに注意してください。バックアップファイルの合計サイズを計算するときは、バックアップログのbackup data size(after compressed)
をベンチマークとして使用します。- TiKV構成項目
backup.num-threads
を調整して、バックアップタスクで使用されるスレッドの数を制限します。 BRがバックアップタスクに使用するスレッドが8
以下で、クラスタの合計CPU使用率が60%を超えない場合、読み取りと書き込みのワークロードに関係なく、バックアップタスクはクラスタにほとんど影響を与えません。
BRはシステムテーブルをバックアップしますか?データの復元中に、競合が発生しますか?
v5.1.0より前では、BRはバックアップ中にシステムスキーマmysql.*
からデータを除外していました。 v5.1.0以降、BRは、システムスキーマmysql.*
を含むすべてのデータをデフォルトでバックアップします。
mysql.*
でシステムテーブルを復元する技術的な実装はまだ完了していないため、システムスキーマmysql
のテーブルはデフォルトでは復元されません。つまり、競合は発生しません。詳細については、 mysql
スキーマで作成されたテーブルを復元します(実験的)を参照してください。
rootを使用してBRを実行しようとしても、 Permission denied
た、またはNo such file or directory
エラーがない場合はどうすればよいですか?
TiKVがバックアップディレクトリにアクセスできるかどうかを確認する必要があります。データをバックアップするには、TiKVに書き込み権限があるかどうかを確認してください。データを復元するには、読み取り権限があるかどうかを確認してください。
バックアップ操作中に、記憶媒体がローカルディスクまたはネットワークファイルシステム(NFS)である場合は、BRを開始するユーザーとTiKVを開始するユーザーが一致していることを確認してください(BRとTiKVが異なるマシン上にある場合、ユーザーは'UIDは一貫している必要があります)。そうしないと、 Permission denied
の問題が発生する可能性があります。
バックアップファイル(SSTファイル)はTiKVによって保存されるため、rootアクセスでBRを実行すると、ディスクのアクセス許可が原因で失敗する可能性があります。
ノート:
データの復元中に同じ問題が発生する可能性があります。 SSTファイルを初めて読み取るときに、読み取り権限が検証されます。 DDLの実行期間は、権限の確認とBRの実行の間に長い間隔がある可能性があることを示しています。長時間待つと、エラーメッセージ
Permission denied
が表示される場合があります。したがって、次の手順に従って、データを復元する前に権限を確認することをお勧めします。
プロセスクエリに対して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
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
バックアップディレクトリの権限を確認してください。たとえば、
backup
はバックアップデータストレージ用です。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 ..
上記の出力から、
tikv-server
つのインスタンスがユーザーtidb_ouo
によって開始されていることがわかります。ただし、ユーザーtidb_ouo
にはbackup
の書き込み権限がありません。したがって、バックアップは失敗します。
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 =...
BRでエラーが発生しましたか?
このエラーは、(BRを使用して)復元するクラスタの容量が不十分な場合に発生する可能性があります。このクラスタの監視メトリックまたはTiKVログを確認することで、原因をさらに確認できます。
この問題を処理するには、クラスタリソースをスケールアウトし、復元中の同時実行性を減らし、 RATE_LIMIT
オプションを有効にすることができます。
local
ストレージを使用すると、バックアップされたファイルはどこに保存されますか?
local
のストレージを使用すると、BRが実行されているノードでbackupmeta
が生成され、各リージョンのリーダーノードでバックアップファイルが生成されます。
バックアップデータのサイズはどうですか?バックアップのレプリカはありますか?
データのバックアップ中に、バックアップファイルが各リージョンのリーダーノードに生成されます。バックアップのサイズはデータサイズと同じであり、冗長なレプリカはありません。したがって、合計データサイズは、おおよそTiKVデータの合計数をレプリカの数で割ったものになります。
ただし、ローカルストレージからデータを復元する場合は、各TiKVがすべてのバックアップファイルにアクセスできる必要があるため、レプリカの数はTiKVノードの数と同じです。
BRがTiCDC/ Drainerのアップストリームクラスタにデータを復元する場合はどうすればよいですか?
BRを使用して復元されたデータは、ダウンストリームに複製できません。これは、BRがSSTファイルを直接インポートしますが、現在、ダウンストリームクラスタがこれらのファイルをアップストリームから取得できないためです。
v4.0.3より前では、BRの復元中に生成されたDDLジョブにより、TiCDC/ Drainerで予期しないDDL実行が発生する可能性がありました。したがって、TiCDC / Drainerのアップストリームクラスタで復元を実行する必要がある場合は、BRを使用して復元されたすべてのテーブルをDrainer / Drainerブロックリストに追加します。
filter.rules
を使用してTiCDCのブロックリストを構成し、 syncer.ignore-table
を使用してDrainerのブロックリストを構成できます。
BRは、テーブルのSHARD_ROW_ID_BITS
およびPRE_SPLIT_REGIONS
情報をバックアップしますか?復元されたテーブルには複数のリージョンがありますか?
はい。 BRは、テーブルのSHARD_ROW_ID_BITS
およびPRE_SPLIT_REGIONS
の情報をバックアップします。復元されたテーブルのデータも複数のリージョンに分割されます。
the entry too large, the max entry size is 6291456, the size of data is 7690800
というエラーメッセージが表示されて復元が失敗した場合は、どうすればよいですか?
--ddl-batch-size
から128
以下の値を設定することにより、バッチで作成されるテーブルの数を減らすことができます。
BRを使用して[ --ddl-batch-size
](/br/br-batch-create-table.md#how to use)の値が1
より大きいバックアップデータを復元する場合、TiDBはテーブル作成のDDLジョブをDDLジョブキューに書き込みますそれはTiKVによって維持されています。現時点では、ジョブメッセージの最大値はデフォルトで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
エラーを報告します。
BRを使用してバックアップデータを復元した後、SQLクエリでregion is unavailable
というエラーが報告されるのはなぜですか?
BRを使用してバックアップされたクラスタにTiFlashがある場合、BRがバックアップデータを復元するときにTableInfo
がTiFlash情報を保存します。復元するクラスタにTiFlashがない場合は、 region is unavailable
エラーが報告されます。
BRは、一部の履歴バックアップのインプレース完全復元をサポートしていますか?
いいえ。BRは、一部の履歴バックアップのインプレース完全復元をサポートしていません。
Kubernetes環境で増分バックアップにBRを使用するにはどうすればよいですか?
最後のBRバックアップのcommitTs
フィールドを取得するには、kubectlを使用してkubectl -n ${namespace} get bk ${name}
コマンドを実行します。このフィールドの内容は--lastbackupts
として使用できます。
BR backupTSをUnix時間に変換するにはどうすればよいですか?
BR backupTS
は、デフォルトで、バックアップが開始される前にPDから取得された最新のタイムスタンプになります。 pd-ctl tso timestamp
を使用してタイムスタンプを解析して正確な値を取得するか、 backupTS >> 18
を使用して推定値をすばやく取得できます。
BRがバックアップデータを復元した後、テーブルとインデックスのTiDBの統計を更新するために、テーブルでANALYZE
ステートメントを実行する必要がありますか?
BRは統計をバックアップしません(v4.0.9を除く)。したがって、バックアップデータを復元した後、手動でANALYZE TABLE
を実行するか、TiDBが自動的にANALYZE
を実行するのを待つ必要があります。
v4.0.9では、BRはデフォルトで統計をバックアップするため、メモリを大量に消費します。バックアッププロセスが正常に行われるようにするために、v4.0.10以降、統計のバックアップはデフォルトで無効になっています。
テーブルでANALYZE
を実行しない場合、統計が不正確であるため、TiDBは最適化された実行プランの選択に失敗します。クエリのパフォーマンスが重要な問題でない場合は、 ANALYZE
を無視できます。
複数のBRプロセスを同時に使用して、単一のクラスタのデータを復元できますか?
次の理由により、複数のBRプロセスを同時に使用して単一のクラスタのデータを復元することは強くお勧めしません。
- BRがデータを復元すると、PDの一部のグローバル構成が変更されます。したがって、データの復元に複数のBRプロセスを同時に使用すると、これらの構成が誤って上書きされ、異常なクラスタステータスが発生する可能性があります。
- BRはデータを復元するために多くのクラスタリソースを消費するため、実際、BRプロセスを並行して実行すると、復元速度は限られた範囲でしか向上しません。
- データの復元のために複数のBRプロセスを並行して実行するテストは行われていないため、成功する保証はありません。
バックアップログでkey locked Error
が報告された場合はどうすればよいですか?
ログのエラーメッセージ: log - ["backup occur kv error"][error="{\"KvError\":{\"locked\":
バックアッププロセス中にキーがロックされている場合、BRはロックを解決しようとします。このエラーがたまにしか発生しない場合、バックアップの正確性には影響しません。
バックアップ操作が失敗した場合はどうすればよいですか?
ログのエラーメッセージ: log - Error: msg:"Io(Custom { kind: AlreadyExists, error: \"[5_5359_42_123_default.sst] is already exists in /dir/backup_local/\" })"
バックアップ操作が失敗し、上記のメッセージが表示された場合は、次のいずれかの操作を実行してから、バックアップを再開してください。
- バックアップ用のディレクトリを変更します。たとえば、
/dir/backup_local/
を/dir/backup-2020-01-01/
に変更します。 - すべてのTiKVノードとBRノードのバックアップディレクトリを削除します。
BRのバックアップまたは復元後に、監視ノードに表示されるディスク使用量に一貫性がない場合はどうすればよいですか?
この不整合は、バックアップで使用されるデータ圧縮率が復元で使用されるデフォルトの率と異なるという事実によって引き起こされます。チェックサムが成功した場合、この問題は無視できます。
配置ルールをクラスタに復元するとエラーが発生するのはなぜですか?
v6.0.0より前では、BRは配置ルールをサポートしていません。 v6.0.0以降、BRは配置ルールをサポートし、配置ルールのバックアップおよび復元モードを制御するためのコマンドラインオプション--with-tidb-placement-mode=strict/ignore
を導入します。デフォルト値strict
の場合、BRは配置ルールをインポートして検証しますが、値がignore
の場合はすべての配置ルールを無視します。
BRがnew_collations_enabled_on_first_bootstrap
不一致を報告するのはなぜですか?
TiDB v6.0.0以降、デフォルト値のnew_collations_enabled_on_first_bootstrap
がfalse
からtrue
に変更されました。 BRは、アップストリームクラスタのnew_collations_enabled_on_first_bootstrap
の構成をバックアップし、この構成の値がアップストリームクラスターとダウンストリームクラスターの間で一貫しているかどうかを確認します。値が一貫している場合、BRはアップストリームクラスタにバックアップされたデータをダウンストリームクラスタに安全に復元します。値に一貫性がない場合、BRはデータの復元を実行せず、エラーを報告します。
以前のバージョンのv6.0.0のTiDBクラスタにデータをバックアップし、このデータをv6.0.0以降のバージョンのTiDBクラスタに復元するとします。この状況では、 new_collations_enabled_on_first_bootstrap
の値がアップストリームクラスターとダウンストリームクラスターの間で一貫しているかどうかを手動で確認する必要があります。
- 値が一貫している場合は、復元コマンドに
--check-requirements=false
を追加して、この構成チェックをスキップできます。 - 値に一貫性がなく、強制的に復元を実行すると、BRはデータ検証エラーを報告します。
- TiDB v5.4.0以降のバージョンでは、バックアップタスクが高いワークロードの下でクラスタ上で実行される場合、バックアップタスクの速度が遅くなるのはなぜですか?
- エラーメッセージ<code>could not read local://...:download sst failed</code>場合、データの復元中に何が返されますか?
- バックアップ操作はクラスタにどの程度の影響を与えますか?
- BRはシステムテーブルをバックアップしますか?データの復元中に、競合が発生しますか?
- rootを使用してBRを実行しようとしても、 <code>Permission denied</code>た、または<code>No such file or directory</code>エラーがない場合はどうすればよいですか?
- <code>Io(Os...)</code>エラーを処理するにはどうすればよいですか?
- <code>rpc error: code = Unavailable desc =...</code> BRでエラーが発生しましたか?
- <code>local</code>ストレージを使用すると、バックアップされたファイルはどこに保存されますか?
- バックアップデータのサイズはどうですか?バックアップのレプリカはありますか?
- BRがTiCDC/ Drainerのアップストリームクラスタにデータを復元する場合はどうすればよいですか?
- BRは、テーブルの<code>SHARD_ROW_ID_BITS</code>および<code>PRE_SPLIT_REGIONS</code>情報をバックアップしますか?復元されたテーブルには複数のリージョンがありますか?
- <code>the entry too large, the max entry size is 6291456, the size of data is 7690800</code>というエラーメッセージが表示されて復元が失敗した場合は、どうすればよいですか?
- BRを使用してバックアップデータを復元した後、SQLクエリで<code>region is unavailable</code>というエラーが報告されるのはなぜですか?
- BRは、一部の履歴バックアップのインプレース完全復元をサポートしていますか?
- Kubernetes環境で増分バックアップにBRを使用するにはどうすればよいですか?
- BR backupTSをUnix時間に変換するにはどうすればよいですか?
- BRがバックアップデータを復元した後、テーブルとインデックスのTiDBの統計を更新するために、テーブルで<code>ANALYZE</code>ステートメントを実行する必要がありますか?
- 複数のBRプロセスを同時に使用して、単一のクラスタのデータを復元できますか?
- バックアップログで<code>key locked Error</code>が報告された場合はどうすればよいですか?
- バックアップ操作が失敗した場合はどうすればよいですか?
- BRのバックアップまたは復元後に、監視ノードに表示されるディスク使用量に一貫性がない場合はどうすればよいですか?
- 配置ルールをクラスタに復元するとエラーが発生するのはなぜですか?
- BRが<code>new_collations_enabled_on_first_bootstrap</code>不一致を報告するのはなぜですか?