SQL Server 2005の一方向レプリケーション

Question

私が働いているビジネスでは、プライマリ データベースの読み取り負荷を軽減する方法について議論しています。

提案されているオプションの 1 つは、プライマリ データベースからスレーブ データベースへの一方向のライブ レプリケーションを行うことです。その後、アプリケーションはスレーブ データベースから読み取り、プライマリ データベースに直接書き込みます。それで...

• アプリケーションはスレーブから読み取ります
• アプリケーションがプライマリに書き込む
• プライマリはスレーブを自動的に更新します

この方法の主な長所と短所は何ですか?

Answer 1

いくつかの短所:

• 2つの失敗点
• アプリケーション ロジックは、セカンダリ データベースからすぐに利用できないため、何かを書き込んでから読み取るまでの遅延を考慮する必要があります。

私が使用した戦略は、主要なレポート データを毎晩セカンダリ データベースに送信し、途中で非正規化することで、テーブルをロックして OLTP サーバーからリソースを盗む代わりに、そのデータベース上で強力なクエリを実行できるようにすることです。私は正式なデータ ウェアハウスやレプリケーション ツールを使用していません。むしろ、最新のデータがなくても問題ない問題のあるクエリを特定し、それらのクエリ専用のデータ構造をセカンダリ サーバー上に作成します。

「すべてを複製する」アプローチには間違いなく利点があります。

• セカンダリにはすべてのデータが含まれるため、アドホック クエリをセカンダリで実行できます。
• プライマリ サーバーが停止した場合、セカンダリ サーバーをすぐに再利用して引き継ぐことができます。

Answer 2

一方向レプリケーションを使用していますが、同じアプリケーションからではありません。私たちのアプリケーションはマスター データベースに対して読み書きを行い、データは replca データベースに同期され、レポート ツールはこのレプリカを使用します。

アプリケーションが別のデータベースから読み取ることを望まないため、このシナリオでは、マスター データベースでファイル グループとパーティション分割を使用することをお勧めします。ファイル グループ (特に異なるドライブ上) を使用し、ファイルとインデックスをパーティション分割すると、パフォーマンスが大幅に向上します。