Snowflakeデータベースレプリケーション入門|DR構成をやさしく解説

Snowflakeデータベースレプリケーション入門|DR構成をやさしく解説 Snowflake
2026.05.08

はじめに:なぜDR構成が必要なの?

こんにちは!今回はちょっと大人の話題、Snowflakeのデータベースレプリケーションを使ったDR(災害対策)構成について解説します。「DR」は Disaster Recovery の略で、地震・大規模障害・リージョン全体のダウンなどが起きてもサービスを止めないために、別の場所にデータの“分身”を準備しておく仕組みのこと。

Snowflakeには Time TravelやFail-safe といった「うっかり削除」対策の機能もありますが、これらはあくまで同じリージョン内の話。もしリージョン全体が落ちたら太刀打ちできません。そこで登場するのが データベースレプリケーション です。

レプリケーションの基本概念

レプリケーションは、あるアカウントのプライマリデータベースを、別アカウント(別リージョンやクラウド)のセカンダリデータベースへコピーし、定期的に最新状態に同期する仕組みです。

  • プライマリ: 書き込みOKの本番データベース
  • セカンダリ: プライマリから同期される読み取り専用のレプリカ

もしプライマリのリージョンで障害が起きたら、セカンダリを「昇格」させて新しいプライマリにすることでサービスを継続できます。これが フェイルオーバー です。

Snowflakeデータベースレプリケーション入門|DR構成をやさしく解説

具体的な使い方(SQL例)

1. アカウントを「組織(Organization)」でリンクする

まず、ORGADMINロールで、複製先となる別リージョンのSnowflakeアカウントを同じ組織内に作成しておきます。これで両アカウント間の通信が可能になります。

2. プライマリデータベースを有効化

-- プライマリ側(本番アカウント)で実行
ALTER DATABASE my_db ENABLE REPLICATION TO ACCOUNTS myorg.dr_account;

3. セカンダリデータベースを作成

-- セカンダリ側(DRアカウント)で実行
CREATE DATABASE my_db
  AS REPLICA OF myorg.prod_account.my_db;

4. 同期を実行

-- セカンダリ側で実行(初回 & 定期的に)
ALTER DATABASE my_db REFRESH;

このREFRESHをタスクで1時間ごとなどにスケジュールしておくと、自動同期が実現します。

4. 同期を実行の解説図

フェイルオーバーの実行

本番リージョンに障害が起きたら、セカンダリ側でこのコマンドを実行します。

-- セカンダリを新プライマリに昇格
ALTER DATABASE my_db PRIMARY;

これで読み書きOKの状態に変わります。事前に フェイルオーバーグループ(Failover Group) を作っておけば、データベースだけでなくユーザー・ロール・ウェアハウスもまとめて切り替えられて便利です。

注意点

  • レプリケーションには追加のクレジット(計算+データ転送)がかかります。リソースモニターで監視を。
  • セカンダリは読み取り専用。書き込もうとするとエラーになります。
  • 更新頻度を上げるほどRPO(失われる時間)は短くなりますが、コスト増。要件とのバランスが大切。
  • セキュアデータシェアもレプリケート可能です(Business Critical以上)。

まとめ

データベースレプリケーションを使えば、別リージョンに自動同期される“予備のDB”を簡単に作れて、万が一のときも素早くサービス復旧できます。最初は小さなDBで試してみて、フェイルオーバーの手順を体で覚えておくのがおすすめです!

参考リンク

関連記事