SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

可用性グループのバックアップを整理してみました

leave a comment

可用性グループ (AlwaysOn Availability Groups) ではセカンダリでバックアップを取得することが可能です。

バックアップの取得について一度整理しておきたいと思います。

■可用性グループのバックアップ


可用性グループのバックアップを表にまとめると以下のようになります。

  完全 差分 ログ
プライマリ
セカンダリ COPY_ONLY のみ可 ×

 

バックアップについては以下の技術情報に記載されています。
Backup on Secondary Replicas (AlwaysOn Availability Groups)

 

For backups taken on a secondary replica, the BACKUP DATABASE Transact-SQL statement supports creating only copy-only backups of a full database, files, and filegroups.
Creating differential backups is not supported. The BACKUP LOG Transact-SQL statement, in contrast, is fully supported on secondary replicas.

The backup of a secondary replicate cannot be performed if the secondary replica is not able to communicate with the primary replica.
The secondary replica must be synchronized or be in the process of synchronizing in order to perform the backup on the secondary replica

セカンダリレプリカを使用したバックアップはプライマリと通信ができるという条件のもとで実施できるようですね。

セカンダリでは差分バックアップはサポートされていませんが、COPY_ONLY を使用した完全バックアップは取得することが可能です。

トランザクションログに関しては、COPY_ONLY だけでなく、通常のログバックアップを取得することが可能となっています。

以下の画像は、上がプライマリ、下がセカンダリのログの使用状況を取得したものになります。
[プライマリ]
image

[セカンダリ]
image

この状態でプライマリでトランザクションログのバックアップを取得してみます。

以下の画像はバックアップ後のプライマリのトランザクションログの使用状況になります。
トランザクションログのバックアップが取得され、ログの再利用が可能となりますので、使用しているログの領域がバックアップ前と比較して減少しています。
image

バックアップ後のセカンダリの使用状況がこちらです。
image

プライマリでバックアップを取得することで、セカンダリに対してもログの切り捨てが行われていますね。

それでは、次はセカンダリでログのバックアップを取得してみたいと思います。
バックアップ取得前のログの使用状況がこちらです。

[プライマリ]
image

[セカンダリ]
image

この状態でセカンダリでログのバックアップを取得してみます。

[プライマリ]
image

[セカンダリ]
image

セカンダリでログのバックアップを取得してもログの切り捨てが行われているのが確認できますね。

このようなバックアップが取得できるので、

  • セカンダリで取得した COPY_ONLY の完全バックアップ
  • セカンダリで取得したトランザクションログのバックアップ

を使用して、リストアを計画することができるようになるかと思います。

また、セカンダリを使用して通常運用のバックアップが取得できるようになりますので、プライマリ (稼働系) のディスク負荷を低くしてバックアップ運用をすることが可能になります。
# セカンダリでは差分は取れないのでそこは考慮する必要がありますが。

バックアップファイルを一元的な場所に格納するためには共有フォルダに取得する必要が出てくるかも知れませんが、可用性グループを使用することで、可用性だけでなく通常運用のサーバー負荷を減らすことができるようになりそうですね。

Written by masayuki.ozawa

1月 3rd, 2012 at 10:07 pm

Posted in SQL Server

Tagged with ,

No Responses to '可用性グループのバックアップを整理してみました'

Subscribe to comments with RSS or TrackBack to '可用性グループのバックアップを整理してみました'.

  1. こんにちは、お世話になります。

    SQL Server 2012のAlwaysOn環境下(セカンダリは同期2台,非同期2台)で、下記のようなログ切り捨てを行った場合について教えてください。
    BACKUP LOG [対象データベース] TO DISK = N’NUL’;

    プライマリから接続を行った場合、セカンダリ同期2台、非同期2台共にログ切り捨てされるのでしょうか?
    非同期側でまだ処理できていない処理があった場合、ログ切り捨てによる影響はないのでしょうか?
    例えば) UPDATE → ログ切り捨て で、非同期側がUPDATEをまだ実施していない場合、ログ切り捨てにより
          非同期側ではUPDATEが実施されないままになるとか・・・

    tempdbとかは各サーバーでログ切り捨てを行う必要があると思いますが、そのような考え方で間違えていないでしょうか?

    すみません、今まで「単純」設定でしかDBを使用した事がなく、「完全」設定でなおかつAlwaysOnを使用した場合の事に関して無知なため、色々と読ませて頂きながら勉強しておりますが・・・ まだまだ理解しきれておりません。
    ご迷惑をおかけいたしますが、上記の件などに関しまして教えて頂けないでしょうか。

    以上、よろしくお願いいたします。

    ホーリー・ジュン

    17 2月 14 at 18:44

  2. BACKUP LOG [対象データベース] TO DISK = N’NUL’ は可用性グループで実行したことがないので正確なことが言えないのですが、プライマリで実行すれば、セカンダリのログも NULL デバイスのバックアップにより切り捨てられるかと思います。

    AlwaysOn 可用性グループでは各レプリカに対して、どこまでログを送信したかを持っていますので、同期/非同期レプリカの一部が停止していたとしても、そのログがロストするということはありません。
    # ログのバックアップを取得しても未同期分に関しては切り捨てられないはずです。

    tepmpdb に関してはデフォルトで単純復旧のモデルですのでログ切り捨ては不要です。

    AlwaysOn 可用性グループに含めたデータベースについては「完全」で運用をする必要がありますので、そこについての運用を検討されるとよろしいかと思います。

    Masayuki.Ozawa

    17 2月 14 at 20:44

  3. お世話になります。

    ご回答、ありがとうございました。 頂いたアドバイスを元に検討してみます。

    ホーリー・ジュン

    19 2月 14 at 10:41

Leave a Reply

*