Lakehouse for Apache Iceberg は、カタログ メタデータのクロスリージョン レプリケーションと障害復旧をサポートしています。
この構成では、 Cloud Storage デュアルリージョン バケットまたは マルチリージョン バケットでバックアップされたカタログが必要です。
始める前に
-
BigLake API を有効にします。
API を有効にするために必要なロール
API を有効にするには、
serviceusage.services.enable権限が必要です。プロジェクトを作成した場合は、オーナーロール（roles/owner）を介してこの権限がすでに付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール（roles/serviceusage.serviceUsageAdmin）を介してこの権限を取得できます。ロールを付与する方法をご確認ください。
必要なロール
Lakehouse ランタイム カタログで Iceberg REST カタログ エンドポイントを使用するために必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。
-
カタログ ユーザー アクセス、ストレージ アクセス、カタログの認証情報ベンダー モードの管理などの管理タスクを実行する:
- BigLake 管理者 （
roles/biglake.admin）プロジェクトに対する - Cloud Storage バケットに対する ストレージ管理者 (
roles/storage.admin)
- BigLake 管理者 （
-
認証情報ベンダー モードでテーブルデータを読み取る:
BigLake 閲覧者 （
roles/biglake.viewer） プロジェクトに対する -
認証情報ベンダー モードでテーブルデータを書き込む:
BigLake 編集者 （
roles/biglake.editor） プロジェクトに対する -
認証情報ベンダー モード以外でカタログ リソースとテーブルデータを読み取る:
- プロジェクトに対する BigLake 閲覧者 （
roles/biglake.viewer） - Cloud Storage バケットに対する
Storage オブジェクト閲覧者
roles/storage.objectViewer
- プロジェクトに対する BigLake 閲覧者 （
-
認証情報ベンダー モード以外でカタログ リソースを管理し、テーブルデータを書き込む:
- プロジェクトに対する BigLake 編集者 （
roles/biglake.editor） - Cloud Storage バケットに対する Storage オブジェクト ユーザー （
roles/storage.objectUser）
- プロジェクトに対する BigLake 編集者 （
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
必要な権限は、カスタム ロールや他の事前定義 ロールから取得することもできます。
レプリケーションと障害復旧のワークフロー
クロスリージョン レプリケーションと障害復旧を使用するには、次の一般的な手順を行います。
- レプリケーションのステータスを表示する: 現在のプライマリ リージョンとセカンダリ リージョンを特定して、フェイルオーバーのターゲット リージョンを決定します。
- 同期ステータスを確認する: プライマリ リージョンとセカンダリ リージョンの現在の状態を確認して、移行の準備ができていることを確認します。
- フェイルオーバー モードを選択する: ソフト フェイルオーバー（ 計画メンテナンスに最適）またはハード フェイルオーバー（緊急 復旧に最適）を選択します。
- フェイルオーバーを開始する: 選択したモードに対応するコマンドを実行して、プライマリ リージョンとセカンダリ リージョンを切り替えます。
フェイルオーバーの準備
現在のプライマリ リージョンを特定し、セカンダリ リージョンの同期ステータスを確認します。その後、フェイルオーバーを開始します。
レプリケーションのステータスを表示する
カタログがレプリケートされるリージョンを特定するには、次の
gcloud biglake iceberg catalogs describe コマンドを実行します。
gcloud biglake iceberg catalogs describe CATALOG_NAME
CATALOG_NAME は、カタログの名前に置き換えます。
同期ステータスを確認する
フェイルオーバーを開始する前に、
セカンダリ レプリカの同期ステータスを gcloud biglake iceberg catalogs failover
コマンドを使用して確認します。
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--validate_only \
--primary-replica PRIMARY_REPLICA_REGION
次のように置き換えます。
CATALOG_NAME: カタログの名前。PRIMARY_REPLICA_REGION: 新しいプライマリ レプリカとして指定するリージョン。
フェイルオーバーを開始する
障害復旧機能では、メタストア レプリケーションを使用してプライマリ リージョンとセカンダリ リージョンを指定します。すべてのテーブル commit メタデータはプライマリ リージョンから提供され、セカンダリ リージョンにレプリケートされます。フェイルオーバー オペレーションを使用して、カタログのプライマリ リージョンとセカンダリ リージョンを切り替えることができます。
ソフト フェイルオーバー
ソフト フェイルオーバーを開始するには、次の gcloud biglake iceberg catalogs failover
コマンドを実行します。
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--primary-replica PRIMARY_REPLICA_REGION
次のように置き換えます。
CATALOG_NAME: カタログの名前。PRIMARY_REPLICA_REGION: 新しいプライマリ レプリカとして指定するリージョン。
ハード フェイルオーバー
ハード フェイルオーバーを開始するには、次の gcloud biglake iceberg catalogs failover
コマンドを実行します。
gcloud biglake iceberg catalogs failover CATALOG_NAME \
--primary-replica PRIMARY_REPLICA_REGION \
--conditional-failover-replication-time=REPLICATION_TIMESTAMP
次のように置き換えます。
CATALOG_NAME: カタログの名前。PRIMARY_REPLICA_REGION: 新しいプライマリ レプリカとして指定するリージョン。REPLICATION_TIMESTAMP: レプリケーションのチェックポイントとして機能する RFC 3339 タイムスタンプ。レプリケーション プロセスでは、レプリカにこの時点までに commit されたすべてのデータが含まれていることを確認します。このタイムスタンプより前に commit されたすべてのデータがレプリカに含まれていない場合、コマンドは失敗します。レプリケーションの遅延に関係なくフェイルオーバー プロセスを強制的に実行するには、このタイムスタンプを過去の日付に設定します。 注: この機能はプレビュー版であるため、REPLICATION_TIMESTAMP は Cloud Storage ファイルではなく、カタログ メタデータのみを追跡します。データ損失の下限を維持するには、Cloud Storage のデータの可用性と 耐久性のドキュメントをご覧ください。