ステージ、パイプ、ロード履歴の複製¶
このトピックでは、データパイプラインオブジェクトと関連するメタデータ(ステージ、ストレージ統合、パイプ、ロード履歴など)の複製サポートに関する情報を提供します。これらのオブジェクトを複製することで、 リージョン 間および クラウドプラットフォーム 間でインジェストおよび ETL パイプラインのフェールオーバーを構成できます。
開始する前に、Snowflakeの複製とフェールオーバー/フェールバックのサポートについて理解しておくことをお勧めします。詳細については、 複数のアカウント間にわたる複製とフェールオーバーの概要 をご参照ください。
要件¶
重要
使用予定のターゲットアカウントのデータベースに すでに ステージとパイプが含まれている場合は、複製を有効にする前にサポートに連絡することをお勧めします。ソースアカウントの複製グループまたはフェールオーバーグループにそのデータベースが含まれると、既存のステージとパイプはすべてデータベースからドロップされます。
ストレージ統合を使用する外部ステージを複製するには、 STORAGE INTEGRATIONS を複製するように複製またはフェールオーバーグループを構成する必要があります。そうでなければ、外部ステージは関連するストレージの統合なしに複製されます。
ALTER REPLICATION GROUP または ALTER FAILOVER GROUP ステートメントを使用して、既存のグループのこれらのプロパティを変更できます。
ALTER ステートメントで INTEGRATIONS を OBJECT_TYPES リストに追加する場合、リストに他の既存のオブジェクトを含めて、それらのオブジェクトがターゲットアカウントでドロップされないようにしてください。 STORAGE INTEGRATIONS を ALLOWED_INTEGRATION_TYPES リストに追加する場合も同様です。
例:
ALTER FAILOVER GROUP my_failover_group SET
  OBJECT_TYPES = ROLES, INTEGRATIONS
  ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS, STORAGE INTEGRATIONS;
注釈
クラウドストレージプロバイダーは、商用クラウドと政府クラウドのリージョン間でデータパイプラインオブジェクトの複製を制限している場合があります。政府クラウドのデータ複製の制限を回避するには、政府クラウドのリージョンにアクセス可能な任意のリージョンにフェールオーバーリソースを構成します。政府クラウドの制限の詳細については、クラウドストレージプロバイダーのドキュメントを確認してください。
複製とステージ¶
このセクションでは、Snowflakeがさまざまなタイプのステージに対して現在サポートしている複製機能のレベルについて説明します。
内部ステージの複製¶
次のテーブルでは、内部ステージのタイプごとに複製がどのように機能するかを説明しています。
| 型 | 複製サポートの説明 | 
|---|---|
| テーブルステージ | 空のテーブルステージは、複製されたデータベースのテーブルに作成されます。テーブルステージのファイルは複製されません。 | 
| ユーザーステージ | ユーザーおよびユーザーステージの複製には、Business Critical Edition(またはそれ以上)が必要です。 複製されたユーザーには空のユーザーステージが作成されます。ユーザーステージのファイルは複製されません。 | 
| 名前付きステージ | 名前付き内部ステージは、データベースを複製するときに複製されます。 ステージのファイルを複製するには、ステージでディレクトリテーブルが有効になっている必要があります。 | 
外部ステージの複製¶
注釈
Snowflakeは外部ステージにファイルを複製しません。クラウドストレージ URL は、プライマリデータベースとセカンダリデータベースの外部ステージの同じ場所を指しています。
次のテーブルでは、外部ステージのタイプごとに複製がどのように機能するかを説明しています。
| 型 | 複製サポートの説明 | 
|---|---|
| 認証情報がない名前付きステージ(パブリックストレージの場所) | データベースを複製すると、名前付き外部ステージが複製されます。外部ステージのファイルは複製されません。 | 
| 認証情報がある名前付きステージ(プライベートストレージの場所) | 複製されたステージには、秘密キーやアクセストークンなどのクラウドプロバイダーの認証情報が含まれます。 | 
| ストレージ統合がある名前付きステージ(プライベートストレージの場所) | ストレージ統合の複製には、Business Critical Edition(またはそれ以上)が必要です。 複製またはフェールオーバーグループは、  また、ターゲットアカウントでクラウドストレージの信頼関係を構成する必要があります。詳細については、 セカンダリストレージ統合のためにクラウドストレージアクセスを構成する をご参照ください。 | 
注釈
セカンダリステージまたはパイプを、プライマリオブジェクトに関連付けられているものとは異なるクラウドストレージの場所に関連付けるには、サポートチームにお問い合わせください。たとえば、他の地域の位置を選ぶこともできます。
考慮事項¶
ステージオブジェクトには、次の制約が適用されます。
- Snowflakeは現在、グループベースの複製(複製とフェールオーバーグループ)の一部として、ステージ複製をサポートしています。ステージ複製はデータベース複製ではサポートされていません。 
- 外部ステージを複製できます。ただし、外部ステージのファイルは複製されません。 
- 内部ステージを複製できます。内部ステージのファイルを複製するには、ステージのディレクトリテーブルを有効にする必要があります。Snowflakeは、ディレクトリテーブルによってマッピングされたファイルのみを複製します。 
- ディレクトリテーブルを持つ内部ステージを複製する場合、プライマリまたはセカンダリステージでディレクトリテーブルを無効にすることはできません。ディレクトリテーブルには、複製されたファイルや COPY ステートメントを使用してロードされたファイルに関する重要な情報が含まれています。 
- 内部ステージのディレクトリテーブルに 5GB を超えるサイズのファイルがある場合、リフレッシュ操作は失敗します。この制限を回避するには、 5GB より大きなファイルを別のステージに移動します。 - プライマリステージ、セカンダリステージ、または以前に複製されたステージのディレクトリテーブルを無効にすることはできません。ステージを含むデータベースを複製グループまたはフェールオーバーグループに追加する 前 に、これらの手順に従ってください。 - プライマリステージで ディレクトリテーブルを無効化 します。 
- 5GB より大きいファイルを、ディレクトリテーブルが有効になっていない別のステージに移動します。 
- ファイルを別のステージに移動したら、プライマリステージのディレクトリテーブルを再度有効にします。 
 
- ユーザーステージとテーブルステージのファイルは複製されません。 
- ストレージ統合を使用する名前付き外部ステージの場合、フェールオーバーの前に、ターゲットアカウントでセカンダリストレージ統合の信頼関係を構成する必要があります。詳細については、 セカンダリストレージ統合のためにクラウドストレージアクセスを構成する をご参照ください。 
- 外部ステージをディレクトリテーブルで複製し、ソースディレクトリテーブルに 自動リフレッシュ を構成した場合、フェールオーバー前に セカンダリ ディレクトリテーブルに自動リフレッシュを構成する必要があります。詳細については、 セカンダリステージでディレクトリテーブルの自動リフレッシュを構成する をご参照ください。 
- 複製されたステージ上のディレクトリテーブルがステージ上の複製されたファイルと一致していない場合、コピーコマンドに予想以上の時間がかかることがあります。ディレクトリテーブルの一貫性を保つには、 ALTER STAGE ... REFRESH ステートメントでリフレッシュしてください。ディレクトリテーブルの整合性ステータスを確認するには、 SYSTEM$GET_DIRECTORY_TABLE_STATUS 関数を使用します。 
複製とパイプ¶
このセクションでは、さまざまなタイプのパイプに対して現在サポートしている複製機能のレベルについて説明します。
Snowflakeは、次の複製をサポートしています。
- 外部ステージからデータをロードする自動インジェストおよび REST エンドポイントパイプを含むパイプオブジェクト。 
- パイプレベルのパラメーター。 
- パイプオブジェクトへの権限の付与。 
注釈
セカンダリステージまたはパイプを、プライマリオブジェクトに関連付けられているものとは異なるクラウドストレージの場所に関連付けるには、サポートチームにお問い合わせください。たとえば、他の地域の位置を選ぶこともできます。
セカンダリデータベースのパイプ¶
セカンダリデータベースのパイプは READ_ONLY 実行状態にあり、通知を受け取りますが、セカンダリデータベースをプライマリデータベースとして機能するように昇格させるまではデータをロードしません。セカンダリデータベースを昇格させると、パイプは FAILING_OVER 実行状態に移行します。フェールオーバーが完了すると、パイプは RUNNING 実行状態になり、最後のリフレッシュ時刻(つまり、以前のプライマリデータベースが最後にリフレッシュされた時刻)以降に使用可能なすべてのデータのロードを開始します。
自動インジェストパイプの複製¶
フェールオーバーが発生した場合、複製された自動インジェストパイプが新しいプライマリパイプとなり、次が可能になります。
- まだロードされていないデータをロードする。これには、新しく昇格されたプライマリデータベースが最後にリフレッシュされた以降の新しいデータが含まれます。 
- ステージが新しいファイルをロードするときに通知を継続して受け取り、それらのファイルからデータをロードします。 - 注釈 - 通知を受け取るには、 フェールオーバーの前に ターゲットアカウントでセカンダリ自動インジェストパイプを構成する必要があります。詳細については、 セカンダリ自動インジェストパイプの通知を構成する をご参照ください。 
REST エンドポイントパイプの複製¶
Snowpipe REST API を使用してデータをロードするパイプの場合、Snowflakeは指定した各ターゲットアカウントにパイプとそのロード履歴メタデータを複製します。ターゲットアカウントで実行が必要となる追加の構成手順はありません。ロード履歴メタデータの詳細なリストについては、 メタデータのロード をご参照ください。
フェールオーバー時にデータのロードを続行するには、新しく昇格したソースアカウントから REST API を呼び出します。
考慮事項¶
パイプオブジェクトには、次の制約が適用されます。
- Snowflakeは現在、グループベースの複製(複製とフェールオーバーグループ)の一部として、パイプ複製をサポートしています。パイプ複製はデータベース複製ではサポートされていません。 
- Snowflakeは、パイプがターゲットテーブルと同じ複製グループに属している場合にのみ、パイプのコピー履歴を複製します。 
- 通知統合の複製はサポートされていません。 
- Snowflakeは、最新のテーブル切り捨て後のロード履歴のみを複製します。 
- 通知を受け取るには、 フェールオーバーの前に ターゲットアカウントでセカンダリ自動インジェストパイプを構成する必要があります。詳細については、 セカンダリ自動インジェストパイプの通知を構成する をご参照ください。 
- SYSTEM$PIPE_STATUS 関数を使用して、フェールオーバー後に期待される実行状態にないパイプを解決します。 
- SnowflakeはKafkaコネクタを使用したSnowpipeの複製とフェールオーバーをサポートしていませんが、SnowflakeはKafkaコネクタを使用したSnowpipe Streamingの複製とフェールオーバーをサポートしています。詳細については、 Snowpipe StreamingとKafkaコネクタ をご参照ください。 
例1: 名前付き内部ステージの複製¶
この例は、内部ステージの複製がどのように機能するかを示しています。特にこの例では、複製の前後で、ディレクトリテーブルがステージメタデータの唯一の信頼できる情報源であることを示しています。
例の最初の部分では、 ソース アカウントで次のタスクを完了します。
- ステージのファイルを複製するために、ディレクトリテーブルを有効にした - my_int_stageという名前の内部ステージを作成します。次に、- my_tableという名前のテーブルからステージのファイルにデータをコピーします。- 注釈 - この例では、 - file1と- file2をステージにロードした後にディレクトリテーブルをリフレッシュして、テーブルのメタデータをディレクトリテーブルのステージ定義にある最新のファイルセットと同期させています。ただし、- file3をロードした後にリフレッシュ操作は発生しません。- CREATE OR REPLACE STAGE my_stage DIRECTORY = (ENABLE = TRUE); COPY INTO @my_stage/folder1/file1 from my_table; COPY INTO @my_stage/folder2/file2 from my_table; ALTER STAGE my_stage REFRESH; COPY INTO @my_stage/folder3/file3 from my_table; 
- フェールオーバーグループを作成する - CREATE FAILOVER GROUP my_stage_failover_group OBJECT_TYPES = DATABASES ALLOWED_DATABASES = my_database_1 ALLOWED_ACCOUNTS = myorg.my_account_2; 
この例の2番目の部分は、 ターゲット アカウントでの複製とフェールオーバー処理を完了します。
- ソースアカウントのフェールオーバーグループのレプリカとしてフェールオーバーグループを作成し、新しいフェールオーバーグループのオブジェクトをリフレッシュし、ターゲットアカウントをソースアカウントとして機能するように昇格させます。 - CREATE FAILOVER GROUP my_stage_failover_group AS REPLICA OF myorg.my_account_1.my_stage_failover_group; ALTER FAILOVER GROUP my_stage_failover_group REFRESH; ALTER FAILOVER GROUP my_stage_failover_group PRIMARY; 
- 次に、複製されたステージのディレクトリテーブルをリフレッシュし、 - my_stage上のディレクトリテーブルが追跡しているすべてのファイルを- my_tableという名前のテーブルにコピーします。- 注釈 - COPY INTO ステートメントは - file1と- file2をテーブルにロードしますが、- file3はロードしません。これは、ソースアカウントに- file3を追加した後、ディレクトリテーブルがリフレッシュされなかったためです。- ALTER STAGE my_stage REFRESH; COPY INTO my_table FROM @my_stage; 
例2: 外部ステージとストレージの統合を複製する¶
この例は、外部ステージとストレージ統合をターゲットアカウントに複製するためのサンプルワークフローを提供します。
この例は、既に以下を完了していることを前提としています: Amazon S3バケットへの安全なアクセスの構成。
例の最初の部分では、 ソース アカウントで次のタスクを完了します。
- データベース - my_database_2のAmazon S3バケットにストレージ統合を作成します。- CREATE STORAGE INTEGRATION my_storage_int TYPE = external_stage STORAGE_PROVIDER = 's3' STORAGE_ALLOWED_LOCATIONS = ('s3://mybucket/path') STORAGE_BLOCKED_LOCATIONS = ('s3://mybucket/blockedpath') ENABLED = true; 
- ストレージ統合 - my_storage_intを使用して、データベース- my_database_2に外部ステージを作成します。- CREATE STAGE my_ext_stage URL = 's3://mybucket/path' STORAGE_INTEGRATION = my_storage_int 
- フェールオーバーグループを作成し、データベース - my_database_2とストレージ統合オブジェクトを含めます。- CREATE FAILOVER GROUP my_external_stage_fg OBJECT_TYPES = databases, integrations ALLOWED_INTEGRATION_TYPES = storage integrations ALLOWED_DATABASES = my_database_2 ALLOWED_ACCOUNTS = myorg.my_account_2; 
この例の2番目の部分は、 ターゲット アカウントでの複製とフェールオーバー処理を完了します。
- ソースアカウントのフェールオーバーグループのレプリカとしてフェールオーバーグループを作成し、更新します。 - CREATE FAILOVER GROUP my_external_stage_fg AS REPLICA OF myorg.my_account_1.my_external_stage_fg; ALTER FAILOVER GROUP my_external_stage_fg REFRESH; 
- ストレージ統合をターゲットアカウントに複製した後、複製統合にクラウドストレージへのアクセスを許可するために、クラウドプロバイダーのアクセス許可を更新する追加のステップを実行する必要があります。詳細については、 セカンダリストレージ統合のためにクラウドストレージアクセスを構成する をご参照ください。 
例3: 自動インジェストパイプの複製¶
この例では、 Amazon Simple Notification Service(SNS)トピックとAmazon Simple Queue Service(SQS)を使用するパイプを複製し、Snowpipe を自動化するためのサンプルワークフローを提供します。
例では、すでに次のタスクを完了していることを前提としています。
- Amazon S3のストレージ統合の作成と構成。たとえば、 - my_s3_storage_intという名前のストレージ統合を使用します。
- Amazon SNS トピックとサブスクリプションを作成し、Snowflake SQS キューを SNS トピックにサブスクライブします。 
- ストレージ統合を参照する外部ステージを作成します。たとえば、 - my_s3_stageという名前のステージを使用します。手順については、 CREATE STAGE をご参照ください。
ソース アカウントで次のタスクを開始します。
- CREATE PIPE コマンドを使用して、外部ステージから - mytableという名前のテーブルにデータをロードする自動インジェストを有効にしたパイプを作成します。- CREATE PIPE snowpipe_db.public.mypipe AUTO_INGEST=TRUE AWS_SNS_TOPIC='<topic_arn>' AS COPY INTO snowpipe_db.public.mytable FROM @snowpipe_db.public.my_s3_stage FILE_FORMAT = (TYPE = 'JSON'); 
- ALTER PIPE ステートメントでパイプをリフレッシュし、ステージから過去7日間のデータをロードします。 - ALTER PIPE mypipe REFRESH; 
- 最後に、 CREATE FAILOVER GROUP を使用してストレージ統合の複製を許可するフェールオーバーグループを作成します。 - CREATE FAILOVER GROUP my_pipe_failover_group OBJECT_TYPES = DATABASES, INTEGRATIONS ALLOWED_INTEGRATION_TYPES = STORAGE INTEGRATIONS ALLOWED_DATABASES = snowpipe_db ALLOWED_ACCOUNTS = myorg.my_account_2; 
この例の2番目の部分は、 ターゲット アカウントでの複製とフェールオーバー処理を完了します。
- ソースアカウントのフェールオーバーグループのレプリカとして、フェールオーバーグループを作成します。 - CREATE FAILOVER GROUP my_pipe_failover_group AS REPLICA OF myorg.my_account_1.my_pipe_failover_group; 
- DESCRIBE INTEGRATION ステートメントを実行して、セカンダリデプロイメントのSnowflakeアカウントの AWS IAM ユーザーの ARN を取得します。 - ARN を使用して、IAM ユーザにS3バケットへのアクセス許可を与えます。 ステップ 5: IAM ユーザーにバケットオブジェクトへのアクセス権限を付与する を参照してください。 - DESC INTEGRATION my_s3_storage_int; 
- SYSTEM$GET_AWS_SNS_IAM_POLICY システム関数を呼び出し、新しい SQS キューに SNS トピックをサブスクライブする権限を与える IAM ポリシーを生成します。Snowflakeは、ソースアカウントからフェールオーバーグループを複製したときに、ターゲットアカウントに新しい SQS キューを作成しました。 - SELECT SYSTEM$GET_AWS_SNS_IAM_POLICY('<topic_arn>'); - topic_arnは、ソースアカウントで元のパイプ用に作成した SNS トピックのAmazonリソースネーム(ARN)です。- 次に、 新しいAmazonの SQS キューを SNS トピック にサブスクライブします。 
- 新しいフェールオーバーグループのオブジェクトをリフレッシュします。 - ALTER FAILOVER GROUP my_pipe_failover_group REFRESH; 
- 最後に、 ALTER FAILOVER GROUP コマンドを使用して、ターゲットアカウントをソースアカウントとして機能するように昇格させます。 - ALTER FAILOVER GROUP my_pipe_failover_group PRIMARY; - mypipeパイプは、ソースアカウントでフェールオーバーグループが最後にリフレッシュされたとき以降に使用可能になったデータのロードを開始します。- 複製されたパイプが機能していることを確認するには、パイプの COPY ステートメントからテーブルにクエリを実行してください。 - SELECT * FROM mytable; 
Amazon Simple Notification Service(SNS)への移行¶
このセクションでは、次のシナリオでAmazon S3イベント通知をAmazon Simple Queue Service(SQS)キューに直接送信する方法から、Amazon Simple Notification Service(SNS)トピックを使用する方法に移行する方法について説明します。
ディレクトリテーブルまたはパイプを複製すると、Snowflakeは自動化を処理するためにターゲットアカウントに新しい SQS キューを作成します。単一の SNS トピックを構成して、S3バケットから複数のアカウントにまたがるすべての SQS キューにイベント通知を配信できます。S3イベント通知を SQS キューごとにブロードキャストすることで、フェールオーバー後に通知やデータが失われるリスクは軽減されます。
注釈
すでに SNS を使用している場合は、移行の必要はありません。代わりに、通常の手順に従って、セカンダリディレクトリテーブルの SNS、またはフェールオーバー前の自動インジェストパイプを使用して自動化を構成します。
前提条件¶
移行するには、次の条件を満たす必要があります。
- S3バケットに1つ以上のイベント通知がすでに設定されていること。手順については、ユースケースに応じて次のトピックをご参照ください。 
- ディレクトリテーブルまたはパイプを持つステージを含むターゲットアカウントで、複製グループまたはフェールオーバーグループを作成済みであること。 
SNS トピックへの移行¶
- AWS アカウントで SNS トピックを作成します。手順については、 AWS SNS ドキュメントの Amazon SNS トピックの作成 をご参照ください。 
- S3イベント通知の送信先(他の SQS キューまたは AWS Lambda ワークロードなど)を SNS トピックにサブスクライブします。SNS バケットのイベント通知をトピックのすべてのサブスクライバーにパブリッシュします。手順については、 AWS SNS ドキュメント をご参照ください。 
- トピックのアクセスポリシーを次の権限で更新します。 - Snowflake IAM ユーザーが、 target アカウントにある SQS キューをトピックにサブスクライブできるようにします。 
- Amazon S3がバケットから SNS トピックにイベント通知をパブリッシュすることを許可します。 
 - 手順については、 ステップ1: Snowflake SQS キューを SNS トピックにサブスクライブする をご参照ください。 
- ターゲットSnowflakeアカウントで、 SYSTEM$CONVERT_PIPES_SQS_TO_SNS 関数を呼び出します。この関数は、メタデータの同期またはインジェスチョン作業を中断することなく、 ターゲット アカウントの SQS キューを SNS トピックにサブスクライブします。 - S3バケット名と SNS トピック ARN を指定します。 - SELECT SYSTEM$CONVERT_PIPES_SQS_TO_SNS('s3_mybucket', 'arn:aws:sns:us-west-2:001234567890:MySNSTopic') 
- S3イベント通知を更新して、 SNS トピックを宛先として使用するようにします。手順については、 Amazon S3 ユーザーガイド をご参照ください。 
これらの手順を完了すると、 SQS キューは自動的にS3イベント通知からアンバインドされます。指定されたS3バケットを使用するすべてのディレクトリテーブルとパイプは、通知のソースとして SNS の使用を開始します。