0

Snowflake内でフェイルオーバー/レプリケーションのユースケースを管理する方法に関するドキュメントに飛び込んできました。ここでは基本的に、フェールオーバー戦略は、異なる地域にある同じ組織の 2 つの異なるアカウント間のデータベースのレプリケーション機能に基づいています。

レプリケーションの観点から、これら 2 つの DB を構成し、プライマリ DB を 10 分ごとに更新するタスク内でレプリケーションをセットアップして、セカンダリ DB を可能な限り更新し続けるようにします。それにもかかわらず、予期しないイベントが発生した場合、セカンダリ データベースは一度昇格し、最後に完了した更新に基づくバージョンのデータがプライマリに保持されます。これは、停止の直前に実行された新しいデータ/変換全体が部分的に失われる可能性があることを意味します。これは私に考えさせます：

  • レプリケーション タスクを 1 分にスケジュールするだけでなく、Snowflake 内のフェイルオーバー設計で失われるデータを可能な限り削減する方法はありますか?
  • 停止が解決され、セカンダリ DB にレプリケートできなかったデータの一部を管理する方法をプライマリ DB に戻す必要がありますが、セカンダリDBを本番として？

本当にありがとう

4

1 に答える 1

1

a) データ損失を減らすための戦略の 1 つは、ご指摘のとおり、レプリケーション操作を頻繁にスケジュールすることです。もう 1 つは、フェールオーバー後に最近の ETL ジョブを再生できるようにすることです。そのためには、ソース データが利用可能であり、災害後に ETL プロセスを回復できることを確認する必要があります。そして、その ETL はべき等な方法で再生できます。

b) 変更のマージ / 競合の解決はサポートされていません。Snowflake のデータベース レプリケーションは、シングルマスター モデルに従います。セカンダリ データベースを更新すると、プライマリの現在の状態で上書きされます。(a) で提案されているように、ETL を再生することにより、フェールオーバー後にプライマリで失われたデータを回復することをお勧めします。

于 2019-11-19T00:03:00.800 に答える