- TiDBについて
- クイックスタート
- デプロイ
- 移行する
- 管理
- アップグレード
- 規模
- バックアップと復元
- BRツールを使用する(推奨)
- タイムゾーンの構成
- 毎日のチェックリスト
- TiFlashを管理する
- TiUPを使用してTiDBを管理する
- オンラインで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
- TiUPDMコマンド
- 概要
- tiup dm audit
- tiup dm deploy
- tiup dm destroy
- tiup dm disable
- tiup dm display
- tiup dm edit-config
- tiup dm enable
- tiup dm help
- tiup dm import
- tiup dm list
- tiup dm patch
- tiup dm prune
- tiup dm reload
- tiup dm replay
- tiup dm restart
- tiup dm scale-in
- tiup dm scale-out
- tiup dm start
- tiup dm stop
- tiup dm template
- tiup dm upgrade
- TiDBクラスタートポロジリファレンス
- DMクラスタートポロジリファレンス
- ミラーリファレンスガイド
- TiUPコンポーネント
- TiDB Operator
- バックアップと復元(BR)
- TiDB Binlog
- TiDB Lightning
- TiDBデータ移行
- TiDBデータ移行について
- DMの概要
- 基本的な機能
- 高度な機能
- シャーディングされたテーブルからのデータのマージと移行
- GH-ost/PT-oscを使用するMySQLデータベースからの移行
- SQL式を使用してDMLをフィルタリングする
- DMアーキテクチャ
- ベンチマーク
- クイックスタート
- データ移行シナリオ
- デプロイ
- 管理
- ツール
- クラスターのアップグレード
- データソースを作成する
- データソースの管理
- データ移行タスクの管理
- シャーディングDDLロックを手動で処理する
- 移行するMySQLインスタンスを切り替えます
- 移行するテーブルのスキーマを管理する
- アラートを処理する
- デイリーチェック
- トラブルシューティング
- 性能チューニング
- 参照
- セキュリティ
- モニタリング指標
- アラートルール
- エラーコード
- FAQ
- 用語集
- 例
- リリースノート
- TiCDC
- Dumpling
- sync-diff-inspector
- TiSpark
- 参照
- クラスターアーキテクチャ
- 主要な監視指標
- セキュリティ
- 権限
- 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 USER
ANALYZE TABLE
BACKUP
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
- INFORMATION_SCHEMA
- 概要
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_RULES
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バージョニング
- v5.4
- v5.3
- v5.2
- v5.1
- v5.0
- v4.0
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- 用語集
保存時の暗号化
ノート:
クラスタがAWSにデプロイされ、EBSストレージを使用している場合は、EBS暗号化を使用することをお勧めします。 AWSドキュメント-EBS暗号化を参照してください。ローカルNVMeストレージなどのAWSで非EBSストレージを使用している場合は、このドキュメントで紹介されている保存時に暗号化を使用することをお勧めします。
保存時の暗号化とは、データが保存されるときに暗号化されることを意味します。データベースの場合、この機能はTDE(透過データ暗号化)とも呼ばれます。これは、飛行中の暗号化(TLS)または使用中の暗号化(めったに使用されない)とは対照的です。保管時に暗号化を行うことはさまざまですが(SSDドライブ、ファイルシステム、クラウドベンダーなど)、ストレージの前にTiKVに暗号化を行わせることで、攻撃者がデータにアクセスするためにデータベースで認証する必要があります。たとえば、攻撃者が物理マシンにアクセスした場合、ディスク上のファイルをコピーしてデータにアクセスすることはできません。
さまざまなTiDBコンポーネントでの暗号化のサポート
TiDBクラスタでは、コンポーネントごとに異なる暗号化方式が使用されます。このセクションでは、TiKV、TiFlash、PD、バックアップと復元(BR)などのさまざまなTiDBコンポーネントでの暗号化サポートを紹介します。
TiDBクラスタが展開されると、ユーザーデータの大部分はTiKVノードとTiFlashノードに保存されます。一部のメタデータはPDノードに保存されます(たとえば、TiKV領域の境界として使用されるセカンダリインデックスキー)。保管時に暗号化のメリットを最大限に活用するには、すべてのコンポーネントで暗号化を有効にする必要があります。暗号化を実装するときは、バックアップ、ログファイル、およびネットワークを介して送信されるデータも考慮する必要があります。
TiKV
TiKVは、保存時の暗号化をサポートしています。この機能により、 AESはクリック率モードを使用してデータファイルを透過的に暗号化できます。保管時に暗号化を有効にするには、ユーザーが暗号化キーを提供する必要があり、このキーはマスターキーと呼ばれます。 TiKVは、実際のデータファイルの暗号化に使用したデータキーを自動的にローテーションします。マスターキーを手動で回転させることもできます。保存データの暗号化は保存データ(つまり、ディスク上)でのみ暗号化され、データがネットワーク経由で転送されている間は暗号化されないことに注意してください。残りの暗号化と一緒にTLSを使用することをお勧めします。
オプションで、クラウドとオンプレミスの両方のデプロイにAWSKMSを使用できます。プレーンテキストのマスターキーをファイルで指定することもできます。
TiKVは現在、コアダンプから暗号化キーとユーザーデータを除外していません。保管時に暗号化を使用する場合は、TiKVプロセスのコアダンプを無効にすることをお勧めします。これは現在、TiKV自体では処理されていません。
TiKVは、ファイルの絶対パスを使用して暗号化されたデータファイルを追跡します。その結果、 raftstore.raftdb-path
ノードの暗号化がオンになったら、ユーザーはstorage.data-dir
などのデータファイルraftdb.wal-dir
の構成を変更しないでrocksdb.wal-dir
。
TiFlash
TiFlashは、保存時の暗号化をサポートしています。データキーはTiFlashによって生成されます。 TiFlash(TiFlashプロキシを含む)に書き込まれるすべてのファイル(データファイル、スキーマファイル、および一時ファイルを含む)は、現在のデータキーを使用して暗号化されます。暗号化アルゴリズム、TiFlashでサポートされている暗号化構成( tiflash-learner.toml
ファイル内)、および監視メトリックの意味は、TiKVのものと一致しています。
Grafanaを使用してTiFlashをデプロイした場合は、 TiFlash-Proxy-Details- > Encryptionパネルを確認できます。
PD
PDの保存時の暗号化は実験的機能であり、TiKVと同じ方法で構成されます。
BRによるバックアップ
BRは、データをS3にバックアップするときに、S3サーバー側暗号化(SSE)をサポートします。お客様が所有するAWSKMSキーは、S3サーバー側の暗号化と一緒に使用することもできます。詳細については、 BRS3サーバー側の暗号化を参照してください。
ロギング
TiKV、TiDB、およびPD情報ログには、デバッグ目的のユーザーデータが含まれる場合があります。情報ログとその中のこのデータは暗号化されていません。 ログ編集を有効にすることをお勧めします。
安静時のTiKV暗号化
概要
TiKVは現在、CTRモードでAES128、AES192、またはAES256を使用したデータの暗号化をサポートしています。 TiKVはエンベロープ暗号化を使用します。その結果、暗号化が有効になっている場合、TiKVでは2種類のキーが使用されます。
- マスターキー。マスターキーはユーザーによって提供され、TiKVが生成するデータキーを暗号化するために使用されます。マスターキーの管理はTiKVの外部にあります。
- データキー。データキーはTiKVによって生成され、データの暗号化に実際に使用されるキーです。
同じマスターキーをTiKVの複数のインスタンスで共有できます。本番環境でマスターキーを提供するための推奨される方法は、AWSKMSを使用することです。 AWS KMSを使用してカスタマーマスターキー(CMK)を作成し、CMKキーIDを設定ファイルのTiKVに提供します。 TiKVプロセスは、実行中にKMS CMKにアクセスする必要があります。これは、 IAMの役割を使用して実行できます。 TiKVがKMSCMKにアクセスできない場合、起動または再起動に失敗します。 KMSおよびわたしの使用法については、AWSのドキュメントを参照してください。
または、カスタムキーを使用する必要がある場合は、ファイルを介したマスターキーの提供もサポートされています。ファイルには、16進文字列としてエンコードされた256ビット(または32バイト)のキーが含まれ、改行(つまり、 \n
)で終わり、他には何も含まれていない必要があります。ただし、キーをディスクに保持するとキーがリークするため、キーファイルはRAMのtempfs
に保存する場合にのみ適しています。
データキーは、基盤となるストレージエンジン(つまり、RocksDB)に渡されます。 SSTファイル、WALファイル、MANIFESTファイルなど、RocksDBによって書き込まれるすべてのファイルは、現在のデータキーによって暗号化されます。ユーザーデータを含む可能性のあるTiKVによって使用される他の一時ファイルも、同じデータキーを使用して暗号化されます。データキーは、デフォルトで毎週TiKVによって自動的にローテーションされますが、期間は構成可能です。キーローテーションでは、TiKVは既存のすべてのファイルをリライトしてキーを置き換えるわけではありませんが、クラスタが一定の書き込みワークロードを取得する場合、RocksDBコンパクションは古いデータを最新のデータキーで新しいデータファイルにリライトすることが期待されます。 TiKVは、各ファイルの暗号化に使用されるキーと暗号化方法を追跡し、その情報を使用して読み取り時にコンテンツを復号化します。
データの暗号化方法に関係なく、データキーは追加の認証のためにGCMモードのAES256を使用して暗号化されます。これには、KMSの代わりにファイルから渡す場合、マスターキーが256ビット(32バイト)である必要がありました。
キーの作成
AWSでキーを作成するには、次の手順に従います。
- AWSコンソールのAWS KMSに移動します。
- コンソールの右上隅で正しい領域を選択していることを確認してください。
- [キーの作成]をクリックし、キータイプとして[対称]を選択します。
- キーのエイリアスを設定します。
AWSCLIを使用して操作を実行することもできます。
aws --region us-west-2 kms create-key
aws --region us-west-2 kms create-alias --alias-name "alias/tidb-tde" --target-key-id 0987dcba-09fe-87dc-65ba-ab0987654321
2番目のコマンドに入力する--target-key-id
は、最初のコマンドの出力にあります。
暗号化を構成する
暗号化を有効にするには、TiKVおよびPDの構成ファイルに暗号化セクションを追加します。
[security.encryption]
data-encryption-method = "aes128-ctr"
data-key-rotation-period = "168h" # 7 days
data-encryption-method
に指定できる値は、「aes128-ctr」、「aes192-ctr」、「aes256-ctr」、および「plaintext」です。デフォルト値は「plaintext」です。これは、暗号化がオンになっていないことを意味します。 data-key-rotation-period
は、TiKVがデータキーをローテーションする頻度を定義します。新しいTiKVクラスタまたは既存のTiKVクラスタに対して暗号化をオンにすることができますが、暗号化を有効にした後に書き込まれたデータのみが暗号化されることが保証されます。暗号化を無効にするには、設定ファイルのdata-encryption-method
を削除するか、「plaintext」にリセットして、TiKVを再起動します。暗号化方式を変更するには、構成ファイルのdata-encryption-method
を更新し、TiKVを再起動します。
暗号化が有効になっている場合(つまり、 data-encryption-method
は「プレーンテキスト」ではない場合)、マスターキーを指定する必要があります。 AWS KMS CMKをマスターキーとして指定するには、 encryption
セクションの後にencryption.master-key
セクションを追加します。
[security.encryption.master-key]
type = "kms"
key-id = "0987dcba-09fe-87dc-65ba-ab0987654321"
region = "us-west-2"
endpoint = "https://kms.us-west-2.amazonaws.com"
key-id
は、KMSCMKのキーIDを指定します。 region
は、KMSCMKのAWSリージョン名です。 endpoint
はオプションであり、AWS以外のベンダーのAWS KMS互換サービスを使用しているか、 KMSのVPCエンドポイントを使用する必要がない限り、通常は指定する必要はありません。
AWSでもマルチリージョンキーを使用できます。このためには、特定のリージョンに主キーを設定し、必要なリージョンにレプリカキーを追加する必要があります。
ファイルに保存されるマスターキーを指定するには、マスターキーの構成は次のようになります。
[security.encryption.master-key]
type = "file"
path = "/path/to/key/file"
ここで、 path
はキーファイルへのパスです。ファイルには、16進文字列としてエンコードされた256ビット(または16バイト)のキーが含まれ、改行( \n
)で終わり、他には何も含まれていない必要があります。ファイルの内容の例:
3b5896b5be691006e0f71c3040a29495ddcad20b14aff61806940ebd780d3c62
マスターキーを回転させます
マスターキーをローテーションするには、構成で新しいマスターキーと古いマスターキーの両方を指定し、TiKVを再起動する必要があります。 security.encryption.master-key
を使用して新しいマスターキーを指定し、 security.encryption.previous-master-key
を使用して古いマスターキーを指定します。 security.encryption.previous-master-key
の構成フォーマットはencryption.master-key
と同じです。再起動時に、TiKVは古いマスターキーと新しいマスターキーの両方にアクセスする必要がありますが、TiKVが起動して実行されると、TiKVは新しいキーにのみアクセスする必要があります。それ以降、構成ファイルにencryption.previous-master-key
の構成を残しておいてもかまいません。再起動しても、TiKVは、新しいマスターキーを使用して既存のデータを復号化できない場合にのみ、古いキーを使用しようとします。
現在、オンラインマスターキーローテーションはサポートされていないため、TiKVを再起動する必要があります。オンラインクエリを提供する実行中のTiKVクラスタに対してローリングリスタートを実行することをお勧めします。
KMSCMKをローテーションするための設定例を次に示します。
[security.encryption.master-key]
type = "kms"
key-id = "50a0c603-1c6f-11e6-bb9e-3fadde80ce75"
region = "us-west-2"
[security.encryption.previous-master-key]
type = "kms"
key-id = "0987dcba-09fe-87dc-65ba-ab0987654321"
region = "us-west-2"
監視とデバッグ
保管時の暗号化を監視するために、Grafanaを使用してTiKVをデプロイする場合は、 TiKV-詳細ダッシュボードの[暗号化]パネルを確認できます。探すべきいくつかのメトリックがあります:
- 初期化された暗号化:TiKVの起動中に暗号化が初期化された場合は1、それ以外の場合は0。マスターキーローテーションの場合、暗号化が初期化された後、TiKVは前のマスターキーにアクセスする必要はありません。
- 暗号化データキー:既存のデータキーの数。データキーのローテーションが発生するたびに、数値は1ずつ増えます。このメトリックを使用して、データキーのローテーションが期待どおりに機能するかどうかを監視します。
- 暗号化されたファイル:現在存在する暗号化されたデータファイルの数。以前に暗号化されていないクラスタの暗号化をオンにしたときに、この数をデータディレクトリ内の既存のデータファイルと比較して、暗号化されているデータの一部を推定します。
- 暗号化メタファイルサイズ:暗号化メタデータファイルのサイズ。
- 読み取り/書き込み暗号化メタ期間:暗号化のためにメタデータを操作するための追加のオーバーヘッド。
デバッグの場合、 tikv-ctl
コマンドを使用して、ファイルの暗号化に使用される暗号化方式やデータキーIDなどの暗号化メタデータ、およびデータキーのリストをダンプできます。この操作は機密データを公開する可能性があるため、本番環境での使用はお勧めしません。 TiKVコントロールドキュメントを参照してください。
TiKVバージョン間の互換性
TiKVが暗号化メタデータを管理するときにI/Oとミューテックスの競合によって引き起こされるオーバーヘッドを減らすために、最適化がTiKV v4.0.9に導入され、TiKV構成ファイルでsecurity.encryption.enable-file-dictionary-log
によって制御されます。この構成パラメーターは、TiKVv4.0.9以降のバージョンでのみ有効です。
有効になっている場合(デフォルト)、暗号化メタデータのデータ形式はTiKVv4.0.8以前のバージョンでは認識できません。たとえば、暗号化を保存し、デフォルトのenable-file-dictionary-log
構成でTiKVv4.0.9以降を使用するとします。クラスタをTiKVv4.0.8以前にダウングレードすると、TiKVの起動に失敗し、情報ログに次のようなエラーが表示されます。
[2020/12/07 07:26:31.106 +08:00] [ERROR] [mod.rs:110] ["encryption: failed to load file dictionary."]
[2020/12/07 07:26:33.598 +08:00] [FATAL] [lib.rs:483] ["called `Result::unwrap()` on an `Err` value: Other(\"[components/encryption/src/encrypted_file/header.rs:18]: unknown version 2\")"]
上記のエラーを回避するには、最初にsecurity.encryption.enable-file-dictionary-log
をfalse
に設定し、v4.0.9以降でTiKVを開始します。 TiKVが正常に起動すると、暗号化メタデータのデータ形式は、以前のTiKVバージョンで認識できるバージョンにダウングレードされます。この時点で、TiKVクラスタを以前のバージョンにダウングレードできます。
BRS3サーバー側の暗号化
BRを使用してS3にバックアップするときにS3サーバー側の暗号化を有効にするには、 --s3.sse
の引数を渡し、値を「aws:kms」に設定します。 S3は、暗号化に独自のKMSキーを使用します。例:
./br backup full --pd <pd-address> --storage "s3://<bucket>/<prefix>" --s3.sse aws:kms
作成して所有したカスタムAWSKMSCMKを使用するには、さらに--s3.sse-kms-key-id
を渡します。この場合、BRプロセスとクラスタのすべてのTiKVノードの両方がKMS CMKにアクセスする必要があり(たとえば、AWS IAM経由)、KMSCMKは以前のS3バケットと同じAWSリージョンにある必要がありますバックアップを保存します。 AWSIAMを介してBRプロセスおよびTiKVノードにKMSCMKへのアクセスを許可することをお勧めします。 わたしの使用法については、AWSのドキュメントを参照してください。例えば:
./br backup full --pd <pd-address> --storage "s3://<bucket>/<prefix>" --s3.region <region> --s3.sse aws:kms --s3.sse-kms-key-id 0987dcba-09fe-87dc-65ba-ab0987654321
バックアップを復元するときは、 --s3.sse
と--s3.sse-kms-key-id
の両方を使用しないでください。 S3はそれ自体で暗号化設定を把握します。バックアップを復元するクラスタのBRプロセスとTiKVノードも、KMS CMKにアクセスする必要があります。そうしないと、復元が失敗します。例:
./br restore full --pd <pd-address> --storage "s3://<bucket>/<prefix> --s3.region <region>"