コンパクトログバックアップ
このドキュメントでは、ログバックアップをSST形式に圧縮することで、ポイントインタイムリカバリ ( PITR ) の効率を向上させる方法について説明します。
概要
従来のログ バックアップでは、書き込み操作が極めて非構造化された方法で保存されるため、次のような問題が発生する可能性があります。
- 回復パフォーマンスの低下: 順序付けられていないデータは、 Raftプロトコルを介してクラスターに 1 つずつ書き込む必要があります。
- 書き込み増幅: すべての書き込みは、L0 から最下レベルまでレベルごとに圧縮する必要があります。
- 完全バックアップへの依存: リカバリ データの量を制御するには、頻繁な完全バックアップが必要であり、アプリケーションの操作に影響を及ぼす可能性があります。
バージョン8.5.5以降、コンパクトログバックアップ機能にオフラインコンパクション機能が追加され、非構造化ログバックアップデータを構造化SSTファイルに変換できるようになりました。これにより、以下の改善がもたらされます。
- SST ファイルをクラスターに迅速にインポートできるため、リカバリ パフォーマンスが向上します。
- 圧縮中に冗長データが削除され、storageスペースの消費量が削減されます。
- リカバリ時間目標 (RTO) を確保しながら、より長い完全バックアップ間隔を設定できるため、アプリケーションへの影響を軽減できます。
制限事項
- コンパクトログバックアップは完全バックアップの代替手段ではありません。定期的な完全バックアップと併用する必要があります。PITR機能を確保するため、圧縮プロセスではすべてのMVCCバージョンが保持されます。完全バックアップを長期間実行しないと、storage使用量が過剰になり、後でデータを復元する際に問題が発生する可能性があります。
- 現在、ローカル暗号化を有効にしたバックアップの圧縮はサポートされていません。
コンパクトログバックアップを使用する
現在、ログバックアップの圧縮は手動でのみサポートされており、プロセスは複雑です。本番環境でのログバックアップの圧縮には、今後リリースされるTiDB Operatorソリューションのご利用をお勧めします。
手作業による圧縮
このセクションでは、ログ バックアップを手動で圧縮する手順について説明します。
前提条件
ログ バックアップを手動で圧縮するには、 tikv-ctlとbr 2 つのツールが必要です。
ステップ1:storageをBase64でエンコードする
次のエンコード コマンドを実行します。
br operator base64ify --storage "s3://your/log/backup/storage/here" --load-creds
注記：
- 上記のコマンドを実行する際にオプション
--load-credsを指定した場合、エンコードされたBase64文字列には、現在のBR環境から読み込まれた認証情報が含まれます。適切なセキュリティとアクセス制御を確保するためにご注意ください。--storage値は、ログ バックアップ タスクのlog statusコマンドからのstorage出力と一致します。
ステップ2: ログ圧縮を実行する
Base64エンコードstorageでは、 tikv-ctlで圧縮を開始できます。デフォルトのログレベルはtikv-ctlですが、 warningです。より詳細な情報を取得するには--log-level info使用してください。
tikv-ctl --log-level info compact-log-backup \
--from "<start-tso>" --until "<end-tso>" \
-s 'bAsE64==' -N 8
パラメータの説明:
-s: 先ほど取得した Base64 でエンコードされたstorage文字列。-N: 同時ログ圧縮タスクの最大数。--from: 圧縮の開始タイムスタンプ。--until: 圧縮の終了タイムスタンプ。
パラメータ--fromと--untilは、圧縮操作の時間範囲を定義します。圧縮操作では、指定された時間範囲内の書き込み操作を含むすべてのログファイルが処理されるため、生成されるSSTファイルにはこの範囲外のデータが含まれる場合があります。
特定の時点のタイムスタンプを取得するには、次のコマンドを実行します。
echo $(( $(date --date '2004-05-06 15:02:01Z' +%s%3N) << 18 ))
注記：
macOS ユーザーの場合は、 Homebrew経由で
coreutilsインストールし、dateではなくgdate使用する必要があります。