レプリケーション時のバックアップ運用について

Question

＜システム情報＞

OS：Windows 2003 Server R2 SP2

SQL Server：Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86)

復旧モデル：完全

select log_reuse_wait, log_reuse_wait_desc, * from sys.databases

の結果

log_reuse_wait:2

log_reuse_wait_desc:LOG_BACKUP

＜質問内容＞

１．レプリケーション構成でのバックアップ運用はどのように行うべきでしょうか？

パブリッシャ（１台：webからの参照・更新に使用）、

サブスクライバ（１台：パブリッシャ障害時の予備）

という構成になります。

現状は、サブスクライバのみ完全バックアップをdailyで実施という運用をしているため

パブリッシャ・サブスクライバ共に、トランザクションログが肥大化しています。

サブスクライバのみバックアップを取得するとした場合、下記のような運用は現実的でしょうか？

パブリッシャ　：トランザクションログの切捨て（daily）

サブスクライバ：完全バックアップ(daily)、トランザクションログのバックアップ（hourly）

２．トランザクションログの圧縮について

ログ(ldf)のサイズが約50GBになっているため

トランザクションログの切捨てを実施しようと考えています。

手順としては、下記で問題ないでしょうか？

また、オンラインでの実施は可能でしょうか？

可能である場合、サービスへの影響は無視出来る程度と思って良いでしょうか？

BACKUP LOG データベース名 WITH TRUNCATE_ONLY

DBCC SHRINKFILE( 'database.ldf')

３．トランザクションログの見積もり方法

DBCC SHRINKFILE実施後（もしくは実施時）に現実的なサイズに変更しておこうと思いますが

見積もりの指針などはありますでしょうか？

Answer 1

> １．レプリケーション構成でのバックアップ運用はどのように行うべきでしょうか？

パブリケーション データベースに障害が発生時、どの時点までのデータを復旧すべきかによって、バックアップの方式が決まるのではないかと思っています。

個人的には、パブリケーション データベースの復旧には、パブリケーション データベースのバックアップを取得したほうが良いと思います。 また、トランザクション ログ からの復旧を考えていないのですが、データベースの復旧モデルを、単純(simple) に変更すれば、トランザクションログのバックアップを実施する必要がなくなります。

> ２．トランザクションログの圧縮について

トランザクションログ情報がなくなっても良いのであれば、このコマンドで問題ないと思います。

トランザクションログの切捨ては、オンラインで実施しても問題ないと思いますが、アクティブなログが、トランザクション ログの末尾に残っている場合、意図したサイズに圧縮できない場合がございます。

ただ、上記の場合も、何回がこの２つのコマンドを実行すれば、意図したサイズまで圧縮できると思います。

> ３．トランザクションログの見積もり方法

トランザクションログ ログを完全に見積もる方法はないと思います。

しかしながら、例えば、データベースの復旧モデルを 単純(simple) に変更後、数日、数週間 様子をみた後のトランザクションログの物理ファイルサイズを確認することにより、この環境では、現在のサイズまで拡張するような処理が行われているということが判断することができると思います。

 

Answer 2

返信ありがとうございます。

 

> > １．レプリケーション構成でのバックアップ運用はどのように行うべきでしょうか？

>データベースの復旧モデルを、単純(simple) に変更

基本レプリケーションで冗長化、念のためのdaily backupであれば　復旧モデル：単純　への変更でもよさそうですね。

考えられるリスクって何かありますでしょうか？

 

気になる点としては、

オンラインでの実施は可能か

レプリケーションへの影響が無いか

などです。

 

 

>> ３．トランザクションログの見積もり方法

>トランザクションログ ログを完全に見積もる方法はないと思います。

確かに仰る通りです。

以前どこかで（失念してしまいました）見積の指針というか計算式を見たような気がしたので

ついでに聞いてみた次第です。

Answer 3

> 考えられるリスクって何かありますでしょうか？

復旧モデル：単純 にした場合のリスクは、パブリケーション データベースにて、何らかの障害が発生した場合、直前の状態まで復旧することができない点でしょうか。

パブリケーション データベース に更新が行われていたとしても、ログ リーダーで読み取られるまでは、サブスクライバ側へ情報がレプリケートされないため、ログ リーダーで更新情報が読み取られるまでの間に、何らかの障害が パブリケーション データベースに発生した場合は、データがロストする可能性が考えられます。

そのため、パブリケーション データベースは、パブリケーション データベースとしてバックアップ(復旧モデル：完全(Full) ) を実施し、何らかの問題が発生時、どの時点までの情報を復旧する必要があるかについてご検討された上で、トランザクション ログのバックアップ間隔を決められたら良いのではないかと思います。その上で、バックアップが破損していて復旧することができないなどの問題が発生した場合に、保険として サブスクリプション からの復旧を検討されるなどの方法が良いような気がします。

あくまで、個人的な意見です。

[補足]

sync with backup が有効になっていない環境では、パブリケーションDB、ディストリビューションDB に何らかの問題が発生した場合は、レプリケーションの再構築が必要となります。

Answer 4

なるほど、非常に参考になります。

ご教授いただいた方式ですすめたいと思います。

 

＃sync with backupの件は、勉強不足で認識していなかったので、これから調べます。