前の記事でご紹介した、BigQuery Managed Disaster Recoveryの続きです。前の記事ではレプリカリージョンへのデータ切り替えができることの確認だけでしたが、実際にこのBigQueryテーブルをシステムで利用する際に必要なことが「BigQuery Editions」の機能観点からありますので、別記事としてご紹介します。
フェイルオーバーデータセットの設定まで出来た状態では、プライマリ、セカンダリそれぞれを指定してSELECTクエリによるデータ取得が出来ることは確認できました。ただし、それ以外のクエリ実行は、Editionsおよびスロットの機構により出来ない状態です。
ためしにデータを挿入するクエリを実行しようとすると、以下のエラーが出力されます。
The job references a table that belongs to a failover dataset in the "asia-northeast1" region (“テーブル名”). However, only jobs that run on a reservation with the "ENTERPRISE_PLUS" edition are allowed access to failover datasets.フェイルオーバーデータセットへの書き込みはEnterprise Plusエディションでのみ許可されているとのことですので、設定が必要です。
東京（asia-northeast1）をプライマリ、そして大阪（asia-northeast2）をセカンダリとしたデータセットのフェイルオーバーが出来ている状態で、データセットへの書き込みが出来るようにし、実際に書き込み操作を行います。
割り当てが完了すると、以下のように表示されます。
割り当てによるジョブ実行を確認します。
先ほど失敗していたBigQuery上でInsertのクエリを実行すると、正常に実行されました。また、割り当てた予約にも紐づいています。
この「予約がasia-northeast2に紐づいている」というのが今回の肝です。
あらためて作成した予約を「容量管理」で見てみると、当初asia-northeast1に作ったはずのものが、asia-northeast2の方に移行されています。
つまり、フェイルオーバーでは単純にデータセットのプライマリ/セカンダリロケーションが変わるわけではなく、確保している予約についても自動で切り替わるということです。プライマリ/セカンダリそれぞれで予約を取っておく必要もありません。
前回の記事での検証と合わせて、フェイルオーバーをしつつBigQueryのシステム利用が出来ることが確認できました。予約スロットもフェイルオーバーによって自動的に切り替わるのは、コスト面でも運用面でも痒いところに手が届いている機能だなと感じました。
この機能の利用をぜひご検討ください。
Google Cloud、Google Workspaceに関する お問い合わせはこちら