異なるサーバー上の2つのデータベースを同期する
以下の要件に適したソリューションを選択できません。あなたは人々がアドバイスしてくれませんか？
2つのSQL Server 2012データベースサーバーがあります。
- 最初はテキサス（米国）です。クライアントはこれをUATに使用します。
- 2つ目はチェンナイ（インド）にあります。これは、開発/ローカルテストに使用します。
アプリケーションをテストしている間、クライアントはUAT環境で問題/バグを見つけるため、詳細な分析のために開発環境に複製し、バグの修正を開発する必要があります。
2つの異なる場所にある2つのデータベースを同期する予定です。データベースを単一方向で同期することを検討しています。書き込み操作をサポートする必要があります。
私はいくつかの潜在的な解決策を見つけました：
トランザクションログ配送
トランザクションログ配布では、セカンダリデータベースは常に読み取り専用/復元モードであるため、書き込み操作を実行できません。問題/バグを修正するために書き込み操作を行う必要があります。したがって、ログ配布は役に立たないと思います。
データベースミラーリングとAlways On高可用性
ジュニアDBAとして、私はこれらの知識があまりありません。これらが私に合うかどうか教えてください。
毎日のジョブのスケジュール
UATサーバーのバックアップを取り、それをローカルの開発サーバーに復元し、FTP経由でデータベースのバックアップをコピーします。
これに最適なソリューションを教えてください。
編集：-データベース1（サーバー1）で発生しているデータ変更をデータベース2（サーバー2）に移動したいと思います。変更をデータベース2（サーバー2）に移動すると、書き込み可能モードになります。また、データベース2（サーバー2）で発生した変更をデータベース1（サーバー1）に移動したくありません。つまり、単一方向の同期です。
下の画像は理解を深めます。 
簡単にするために、これが限られた時間枠である場合は、バックアップと復元を行います。
数分以内に応答する必要がない限り、おそらく毎日のバックアップで十分です。バックアップを取り、要求に応じてFTPで送信するようにジョブを設定することもできます。after彼らは欠陥を報告しました。
新しく作成されたデータに固有の問題でない限り、私は毎日復元することすらしません。私の経験では、UATは機能性についてです。したがって、既存のデータを使用してテストし、新しいデータを作成します。 DBが数日遅れているということは、テストを繰り返して欠陥を再現できるはずです。
このアプローチは、dbが大きくなるほど遅くなり、難しくなり、実行可能性が低くなります。
継続的なサポートを提供する場合、データベースは巨大であり、SLAで数分以内に応答する必要があると言っている場合、何らかのレプリケーション/同期を設定するのは、努力する価値があります。
最適なソリューションは、クライアントのセキュリティまたは技術ポリシーによって決まる場合があります。彼らと協力して、提案しているものが受け入れ可能であることを確認してください。覚えていなければ、このテーマには多くのバリエーションがあります。しかし、それはすべて次のように要約されます。1。バックアップを取るために何かが必要です。2。スケジュールに従って、またはオンデマンドでファイルをFTPするために何かが必要です。
私がこれを個人的にやっていたら、 Ola Hallengrenのバックアップスクリプト から始めます。インストール後、バックアップを呼び出すSQLエージェントジョブを作成します。
次に、エージェントジョブを編集して、ファイルをFTP転送するステップを追加します。さっそく検索してみたところ、この例の SSISを使用してファイルをFTP転送する の例が見つかり、 SQL ServerのFTPスクリプト の例も見つかりました。
このジョブをスケジュールに従って実行するように設定し、本当に必要な場合にのみオンデマンドで実行することをお勧めします。リモートアクセスとタスクを実行する権限がない場合は、クライアントサイトの誰かにタスクの実行を要求できます。
ユーザー受け入れテスト（UAT）は通常、アプリケーション内をクリックすることを伴います。これは通常、変更を加えてテストすることを意味します。
これは、「これらの問題/バグを開発環境に複製する」と考えている場合は特に当てはまります。双方向で同期することを考えているようです。
これには書き込み可能なデータベースが必要ですが、残念ながら、トランザクションログの配布、データベースのミラーリング、およびAlways On可用性グループは除外されています。これらのシナリオはすべて、読み取り専用のセカンダリデータベース用に設計されています。
両側でデータを変更する場合、理論的には、SQL Serverのレプリケーションテクニック（マージ、ピアツーピア、双方向トランザクションレプリケーション）を使用して、データを両方向にプッシュできます。実際には、開発者は開発データベースにテーブルスキーマの変更を加えるため、レプリケーションが中断する可能性があります。