コピーのみを使用したHASQLAlwaysOnバックアップ+セカンダリレプリカからのログ
私はあなたの集合的なDBAの経験からいくつかのガイダンスを引き出すことを望んでいます。
これが私たちの問題です：
大規模なデータベース（約3TB）の完全バックアップは、リソースを大量に消費しているため、タイムアウトが長くなります。ほとんどがI/Oバウンドのようです。
完全バックアップは週に1回実行され、その間に定期的に15分のトランザクションログバックアップが行われます。ある時点で完全バックアップを取る必要があります。
検討中のオプション：
SQL 2016Standardから2016Enterprise Editionにアップグレードし、Resource Governorを構成して、バックアップによるI/Oを制限します。基本的に、バックアップを少しチョークして、アプリケーション要求のサービスを向上させます。
HA（高可用性）ルートに移動し、SQL AlwaysOnを使用してセカンダリノードを展開し、セカンダリレプリカからバックアップを実行します。これにより、バックアップ業務のプライマリレプリカが軽減され、アプリケーションリクエストに引き続き使用できるようになり、タイムアウトの問題が解決される可能性があります。
賛否両論：
Enterprise Editionのコストはささいなことではなく、他にも多くの利点がありますが、現時点では飲み込むのは難しい薬です。
同様またはそれ以下のコストで、2番目のSQL 2016 Standardエディションサーバーを展開し、HADRベースのデータベース展開の恩恵を受けることができます。現在、回復のためのコールドスタンバイしかないため、このオプションは非常に魅力的です。
バックアップ中のタイムアウトの問題を解決できれば、エンタープライズよりもHADRのメリットを優先する可能性があります。
いくつかのラボの調査結果：
Enterpriseエディションの場合、一部のラボテストでは、バックアップリソースを適切に制御できることが示されていますが、理想的とは言えません。ハードウェアの数値を微調整して、バックアップの速度を大幅に低下させることなく、バックアップに必要なレベルの制限を実現するための「スイートスポット」を見つける必要があります。
AlwaysOnの場合、いくつかのラボテストを行ったところ、セカンダリレプリカで通常の「完全」バックアップを実行できないことがわかりましたが、COPY_ONLY「完全」バックアップを作成することはできます。これは、プライマリレプリカのログチェーンを保持するため、理にかなっています。
セカンダリレプリカでトランザクションログのバックアップを作成できますが、ログチェーンは実際にはプライマリからの「スレーブ」であり、セカンダリレプリカで作成しても害はないため、問題ありません。
CopyOnlyBackup + TransactionLogsから復元できることを確認したので、これは実行可能なデータ回復戦略である可能性があります。
調査結果と質問：
誰かが同様の問題を抱えていて、どちらかのオプションでそれを解決し、オプションの実行可能性を確認しましたか？
「セカンダリレプリカからのCopyOnlyBackup + TransactionLogs」シナリオでは、プライマリレプリカの完全バックアップはログチェーンを切断し、後続のトランザクションログバックアップのためにセカンダリレプリカのCopyOnlyBackupを無効にします。修正は、セカンダリレプリカで別のCopyOnlyBackupを作成するか、プライマリで完全バックアップを作成しないことです。
notプライマリで通常の完全バックアップを作成し、COPY_ONLY完全バックアップのみを作成することの意味は何ですか。長期的には大丈夫ですか？
任意のガイダンスをいただければ幸いです。うまくいけば、私たちは間違った木を吠えないでください。
私は実際に1TBのデータベースで同様のセットアップを使用しています。
- 誰かが同様の問題を抱えていて、どちらかのオプションでそれを解決し、オプションの実行可能性を確認しましたか？
セカンダリのみでバックアップを使用しています。数回の停止でも、完全バックアップとログバックアップのみをコピーして回復しようとしました。
コピーのみのバックアップを使用しても問題はありません。
上記のステートメントは、2番目と3番目の質問を明確にします。