Azure Databricksの「System tables reference」で、2026年6月12日に確認すべき変更点は、Managed Disaster Recovery（Managed DR）の複製状況を記録するsystem.replication.statesの仕様が公開されたことです。
一般ユーザーに必須の更新や一斉移行はありません。影響を受けるのは、Managed DRを導入するアカウント管理者、メタストア管理者、DR運用担当者です。対象組織は、プレビューの利用可否、Unity Catalogの設定、参照権限、Mission Criticalアドオンの料金、監視データの遅延を確認してください。Managed DRはPublic Previewですが、複製状態を取得するシステムテーブル自体はPrivate Previewとして案内されています。(Microsoft Learn)
Azure DatabricksのSystem tables referenceで何が変わったのか
今回の主な変更は、Azure DatabricksのマネージドDRを監視するためのシステムテーブルが明確になったことです。
| 確認項目 | 内容 |
|---|---|
| テーブル名 | system.replication.states |
| 主な用途 | DRの複製状態、遅延、エラー、対象資産の履歴確認 |
| データ範囲 | Azure Databricksアカウント内の全フェイルオーバーグループ |
| ストリーミング | 対応 |
| 無償保持期間 | 365日 |
| データ反映 | イベント発生後、最大3時間かかる場合がある |
| 提供状態 | Private Preview |
system.replication.statesには、定期的に出力される状態イベントだけでなく、フェイルオーバーグループが変更された際のイベントも記録されます。現在の状態確認に加え、過去のRPO傾向や複製エラーの分析に利用できます。(Microsoft Learn)
誰に影響する変更なのか
影響が大きいのは、次の担当者です。
- Azure DatabricksでManaged DRを導入する管理者
- フェイルオーバーやDR訓練を担当するSRE・運用担当者
- 複製遅延やRPOをダッシュボードで監視する担当者
- システムテーブルを別テーブルへ取り込んでいるデータ基盤担当者
- Unity Catalogの権限を管理するセキュリティ担当者
Managed DRを利用していない環境では、既存ジョブやノートブックを直ちに変更する必要はありません。
一方、システムテーブルを自動検出するツールや、systemカタログ全体を広い権限で参照している環境では、新しいスキーマや機密性の高いDR情報が参照対象に入る可能性があります。アクセス権をグループ単位で見直す必要があります。
system.replication.statesで確認できる情報
監視で特に重要な列は次のとおりです。
| 列名 | 確認できる内容 |
|---|---|
event_time | 状態イベントが記録された日時 |
failover_group_name | 対象フェイルオーバーグループ |
replication_state | 複製やフェイルオーバーの状態 |
replication_lag_ms | 最後に成功した複製からの経過時間 |
errors | 複製を妨げているエラーと影響資産数 |
effective_primary_region | イベント発生時点のプライマリリージョン |
managed_assets | 管理対象のメタストア、ワークスペース、カタログ |
replication_lag_msがnullの場合は、遅延がゼロという意味ではありません。少なくとも1つの資産が一度も複製されていない状態を示します。正常値として扱わないよう注意してください。(Microsoft Learn)
利用前に確認する設定
Managed DRとシステムテーブルのプレビュー状態を分けて確認する
Managed DRはPublic Previewとして公開されていますが、利用にはAzure Databricksのアカウントチームによる有効化が必要です。
一方、system.replication.statesはPrivate Previewです。Managed DRが利用できても、システムテーブルが自動的に利用可能とは限らないため、両方の有効化状況をアカウントチームへ確認してください。(Microsoft Learn)
Unity Catalogとリージョンを確認する
システムテーブルの参照には、Unity Catalog対応ワークスペースが少なくとも1つ必要です。メタストアは、権限継承に対応したPrivilege Model Version 1.0である必要があります。(Microsoft Learn)
日本リージョンでは、システムテーブルはJapan EastとJapan Westでサポートされています。一方、Managed DRの対応リージョン一覧にはJapan Eastが掲載されていますが、Japan Westは掲載されていません。DR構成では、システムテーブルの対応状況だけでなく、Managed DR自体のリージョン対応も確認してください。(Microsoft Learn)
最小限の参照権限を付与する
アカウント管理者かつメタストア管理者であるユーザーには、システムテーブルへのアクセス権が既定で付与されます。それ以外のユーザーやサービスプリンシパルには、Unity Catalogで権限を付与します。
GRANT USE CATALOG ON CATALOG system TO `dr-operators`;
GRANT USE SCHEMA ON SCHEMA system.replication TO `dr-operators`;
GRANT SELECT ON TABLE system.replication.states TO `dr-operators`;DR情報はアカウント全体に関係するため、systemカタログ全体へのSELECTではなく、対象テーブルに限定するのが安全です。(Microsoft Learn)
複製状態を確認するSQL
各フェイルオーバーグループの最新状態は、次のSQLで確認できます。
SELECT
failover_group_name,
event_time,
replication_state,
replication_lag_ms,
effective_primary_region,
errors
FROM system.replication.states
QUALIFY ROW_NUMBER() OVER (
PARTITION BY failover_group_name
ORDER BY event_time DESC
) = 1;監視ルールを作る場合は、次の条件を重点的に確認します。
replication_lag_ms IS NULLreplication_lag_msが組織で定めたRPOを超えているerrorsに1件以上の要素があるFAILOVER_ABORTEDなど、対応が必要なイベントが記録されている
例えばRPOを5分とする場合は、replication_lag_msが300,000ミリ秒を超えた状態を通知対象にできます。ただし、システムテーブルへの反映には最大3時間かかる可能性があります。障害時の即時判断にはアカウントコンソールを使用し、システムテーブルは履歴分析や傾向監視に使うのが適切です。(Microsoft Learn)
設定・更新・移行・料金・期限の確認ポイント
| 項目 | 確認すべき内容 |
|---|---|
| 設定 | Managed DRとReplicationシステムテーブルの利用可否、Unity Catalog、リージョン、権限 |
| バージョン更新 | 今回の情報では、特定のDatabricks Runtimeへの更新は案内されていない |
| 移行 | 既存環境への強制移行はなく、必要な組織が監視処理を追加する |
| 料金 | プライマリ・セカンダリ両方のワークスペースでMission Criticalアドオンが必要 |
| 保持期間 | system.replication.statesの無償保持期間は365日 |
| 期限 | 移行期限や一般提供開始日は記載されていない |
| 構築期間 | 大規模環境では、ワークスペース資産の初回複製に最大2週間かかる場合がある |
Mission Criticalアドオンを有効にしたワークスペースでは、コンピューティング使用量にMission Criticalの料金が適用されます。具体的な単価は公式ドキュメントに固定額で掲載されておらず、Azure Databricksのアカウントチームへの確認が必要です。
また、365日の無償保持期間はシステムテーブルのデータ保持に関する条件です。Managed DRやMission Criticalアドオン全体が無料になるという意味ではありません。(Microsoft Learn)
運用で失敗しやすいポイント
Public PreviewとPrivate Previewを混同する
Managed DRはPublic Preview、system.replication.statesはPrivate Previewです。環境でテーブルが見つからない場合、権限だけでなくプレビューの有効化状況も確認してください。
リアルタイム監視として利用する
データ反映には最大3時間かかる場合があります。秒単位・分単位の障害検知を、このテーブルだけに依存する設計は避けてください。
固定スキーマで取り込む
Azure Databricksのシステムテーブルには、新しい列や構造体内のフィールドが追加される場合があります。ETLで固定列数を前提にしたり、SELECT *の結果を固定スキーマへ書き込んだりすると、将来の変更で処理が失敗する可能性があります。必要な列を明示し、取り込み先ではスキーマ進化を検討してください。(Microsoft Learn)
ストリーミング処理を長期間停止する
システムテーブルをストリーミングで取り込む場合は、skipChangeCommitsをtrueに設定します。また、元テーブルの変更履歴は既定で7日間のため、ストリームが7日以上遅れると処理が停止する可能性があります。(Microsoft Learn)
DR情報を無制限に公開する
システムテーブルには、アカウント構成、運用状況、エラーなどの機密情報が含まれます。Azure Databricksは、システムテーブルのデータをプラットフォーム外へ移動することを強く推奨していません。外部の監視サービスへ転送する場合は、保存先、暗号化、保持期間、閲覧者を明確にしてください。(Microsoft Learn)
まず実施すべきこと
Managed DRを利用している、または導入予定の組織は、最初にAzure Databricksのアカウントチームへ連絡し、Managed DRとsystem.replication.statesの利用可否を確認してください。
利用できる場合は、Unity Catalogとリージョンを確認し、DR運用グループへ最小限の権限を付与します。その後、最新状態を取得するSQLを実行し、アカウントコンソールの表示と比較してください。最後に、自社のRPOに合わせて複製遅延とエラーの通知条件を決めれば、今回の変更を実務的なDR監視へつなげられます。
コメント