問題タブ [log-shipping]

本番データベースの読み取り専用のログ配布コピーであるデータベースを監視するための一貫した方法が必要です。これまで、私は次の方法に依存していました。

1. ログをデータベースに復元するジョブを設定し、最後のステップとして別のジョブを開始します。
2. ログをデータベースに復元するジョブを設定して、最後のステップとしてコントロールテーブルにレコードを挿入します。
3. msdbデータベースにクエリを実行して、ログをデータベースに復元するジョブのステータスを確認します。
4. トランザクションログがバックアップされる直前に値を取得するデータベース自体の内部の制御テーブルをクエリします。
5. データベース内のテーブルからMAX値をクエリして、最近変更があったかどうかを確認します。

上記のメソッドは機能しますが、さまざまな理由で、クエリを実行するすべてのログ配布データベースに実装できるわけではありません。ログ配布されたデータベースの「現在のデータ」の日付を監視するための最良の方法は何ですか？

私は現在、レプリケーション、ログ配布、ミラーリングなどの SQL Server スケールアウト テクノロジのジャングルを横断しています...選択には次の制約があります。

• 読み取り専用の負荷をプライマリ サーバーとセカンダリ (ミラー、サブスクライバー) サーバーに分散させたい
  • 書き込み負荷をプライマリ サーバーに直接送信可能
  • このソリューションは、ほぼメンテナンス不要です。スキーマの変更はセカンダリ サーバーにレプリケートする必要があります (注意: レプリケーションにはいくつかの深刻な制約があるようです)
  • 書き込まれたデータは、セカンダリ サーバーで非常に迅速にアクセスできる必要があります (1 秒未満で、より良いのは瞬時に)。
  • サーバーに障害が発生した場合、最大 1 時間のデータ損失を簡単に許容できます。私は簡単なスケーラビリティにもっと関心があります

ここに私が選ぶことができるいくつかのオプションがあります: http://msdn.microsoft.com/en-us/library/bb510414.aspx . 共有できる経験はありますか？

私は現在、地元の大学で MS SQL 2K5 管理コースを受講していますが、ログ配布の部分で問題が発生しました。

私のセットアップは次のとおりです。

Windows 7 x64 SQL 2005 SP3 同じマシン上の 2 つの SQL サーバー インスタンス

ログ配布設定:

1. プライマリの完全なログ バックアップを実行
2. スタンバイ モードでセカンダリを手動で復元する
3. テーブルに新しいレコードを挿入する
4. SQL 認証ログインを使用してプライマリにログ配布を設定し、セカンダリに接続します
5. セカンダリにタイマーとコピー先を設定する
6. 監視インスタンスが使用されていない

マシン上の両方のインスタンスが読み書きできるように、WORKGROUP の共有フォルダーを設定しました。Transaction Shipping ウィザードで定義されたように、トランザクション ログが生成およびコピーされたことを確認できます。ただし、セカンダリ インスタンスの指定されたテーブルは更新されていません。

異なるネットワーク上に 2 つの SQL 2008 サーバーがあり、間もなくそれらを VPN で接続します。早くて2～3週間です。これが適切に行われていれば、宛先 (スタンバイ / 読み取り専用) データベースを最新の状態に保つためのトランザクション ログ シッピング (またはその他の方法) を簡単にセットアップできます。読み取り専用モードで、宛先データベースに LSRestore_ ジョブをセットアップするにはどうすればよいでしょうか? 最初に *.trn ファイルを手動でコピーします。私の上司は、これが可能であるという投稿を見たと言います。私たちは、データベースの完全なバックアップを実行して毎回それをコピーすることを避けようとしていました。これに関するガイダンスを事前にありがとう。

私は、システムの 1 つにディザスター リカバリーを設定する任務を負っています。プライマリ サーバーは FL にあり、セカンダリ サーバーはドイツにあります。アプリケーションは、社内のグローバル アプリケーションです。

ログ配布とミラーリングのどちらを使用すべきかわかりません。私が読んだことは、ミラーリングがアプリケーションのパフォーマンスに悪影響を及ぼすということです。これは本当ですか？これは、ユーザーがレコードを変更または保存するたびに、肯定的な応答を得るのに時間がかかることを意味しますか?

ありがとう

WALファイルを適用するウォームスタンバイスレーブサーバーを備えたWAL出荷セットアップが機能しています。

pg_standby トリガー ファイルを作成すると、すぐに検出されますが、実際に接続を受け入れる準備が整うまでに 10 ～ 15 分ほどかかります。ほとんどの時間は、.history ファイルの待機に費やされます。

トリガー ファイルが空であるため、「スマート」フェイルオーバーを実行する必要があります。フェイルオーバーを (はるかに) 高速化するために何かできることはありますか?

ログ出力:

ありがとう。

-デニス

すべてのログ配布構成をスクリプト化することは可能ですか？

例：サーバーAからサーバーBへの2つのデータベースからログ配布を開始するジョブを作成する必要があります。

ジョブはサーバーAで実行されます。

ちなみに、どちらもSQL 2008R2Enterpriseです。

サーバーAに共有があります。\serverA\ Log

必要なのはこれだけだと思います。スクリプトだけでそれを行うことは可能ですか？データベースを初期化する必要がありますか、それとも自動初期化するSSMSのようなオプションがありますか？

ジョブを手動で作成する必要がありますか？または、ジョブを作成して管理するように構成されていますか？

スクリプト化可能ですか？誰かがこのようなことをしましたか？これを行うためのスクリプトを持っている人はいますか？

前もって感謝します。

私の会社の Web サイトでは PostgreSQL データベースを使用しています。私たちのデータセンターには、マスター DB といくつかの読み取り専用スレーブ DB があり、それらの間の継続的なレプリケーションに Londiste を使用しています。

レポート用に別の読み取り専用スレーブ DB をセットアップしたいと考えており、このスレーブをリモート ロケーション (データ センターの外) に置きたいと考えています。このスレーブは 100% 最新である必要はありません。24時間以内であれば問題ありません。また、マスター DB にかかる負荷を最小限に抑えたいと考えています。私たちのマスター DB は日中はビジーで、夜はアイドル状態であるため、(可能であれば) レポート スレーブを毎晩 1 回キャッチアップすることをお勧めします。

http://www.postgresql.org/docs/8.4/static/continuous-archiving.htmlで説明されているように、これにログ配布を使用することを考えてい ます

私の計画は次のとおりです。

1. マスター DB に WAL アーカイブをセットアップする
2. 完全な DB スナップショットを作成し、リモートの場所にコピーします
3. DBを復元して追いつく
4. 次の場合に定常状態に入ります。
   • DAYTIME -- DB は遅れていますが、人々はクエリを実行できます
   • 夜 -- 1 日分の WAL ファイルをコピーして、DB を追い上げます

注: ここで重要なのは、完全な DB スナップショットを 1 回だけコピーする必要があるということです。その後、リモート スレーブを再び追いつくために、1 日分の WAL ファイルをコピーするだけで済みます。

ログ配布を行ったことがないので、フィードバックやアドバイスをお願いします。

これは機能しますか？PostgreSQL はこの種の繰り返し復旧をサポートしていますか?

リモートのセミフレッシュ読み取り専用スレーブをセットアップする方法について、他に提案はありますか?

ありがとう！

--S

ログ配布フェールオーバーを自動化し、ログ配布でセカンダリ データベースを回復することは可能ですか?Powershell では、コピーする .trn ファイルが他にあるかどうかをチェックし、適用されていないすべてのトランザクションを復元し、セカンダリ データベースを回復しますか?

物理的な Prod DB サーバー (SQL05) があり、現在は VM DB サーバーです。アイデアは、物理マシンがダウンした場合、ルーターを (NAT 経由で) VM マシンに再ポイントするというものです。VM DB を基本的に最新の状態に保つために、ログ配布を使用することを考えています。

1. これは正しい方法ですか？
2. おそらくミラーリングなど、別の方法で見る必要がありますか？
3. VM DB を常に使用可能な状態にしたい (そのため、ミラーリングが妨げられていると思います)

任意の (良い) 提案が要求されました! :)