Always On 可用性グループに対するセカンダリ データベースの準備
適用対象:
SQL Server
このトピックでは、SQL Server Management Studio、Transact-SQL、または PowerShell を使用して、SQL Server で AlwaysOn 可用性グループのデータベースを準備する方法について説明します。 データベースの準備には、2 つの手順が必要です。
- RESTORE WITH NORECOVERY を使用して、セカンダリ レプリカをホストする各サーバー インスタンスに、プライマリ データベースの最新のデータベース バックアップと以降のログ バックアップを復元します。
- 復元したデータベースを可用性グループに参加させます。
ヒント
既存のログ配布構成がある場合は、ログ配布プライマリ データベースとその 1 つ以上のセカンダリ データベースを、可用性グループ プライマリ レプリカと 1 つ以上のセカンダリ レプリカに変換できる場合があります。 詳細については、このトピックの「ログ配布から AlwaysOn 可用性グループへの移行の前提条件 (SQL Server)」を参照してください。
前提条件と制限
データベースを配置するシステムのディスク ドライブに、セカンダリ データベース用に十分な空き領域があることを確認します。
セカンダリ データベースの名前は、プライマリ データベースの名前と同じである必要があります。
すべて復元操作に RESTORE WITH NORECOVERY を使用します。
セカンダリ データベースをプライマリ データベースとは異なるファイル パス (ドライブ文字を含む) に配置する必要がある場合は、復元コマンドでデータベース ファイルごとに WITH MOVE オプションも使用して、それらのファイルをセカンダリ データベースのパスに指定する必要があります。
データベースのファイル グループをファイル グループごとに復元する場合は、必ずデータベース全体を復元してください。
データベースの復元後、復元された最後のデータ バックアップの後に作成されたすべてのログ バックアップを復元する必要があります (WITH NORECOVERY)。
推奨事項
SQL Serverのスタンドアロン インスタンスでは、可能であれば、特定のセカンダリ データベースのファイル パス (ドライブ文字を含む) は、対応するプライマリ データベースのパスと一致させることをお勧めします。 セカンダリ データベースの作成時にデータベース ファイルを移動し、その後でセカンダリ データベースにファイルを追加しようとした場合、ファイルの追加操作が失敗し、セカンダリ データベースが中断される可能性があるためです。
セカンダリ データベースを準備する場合は、セカンダリ レプリカの初期化が完了するまでの間、可用性グループ内のデータベースでスケジュールされているログ パックアップを一時停止することを強くお勧めします。
セキュリティ
データベースをバックアップするときに、 TRUSTWORTHY データベース プロパティ は OFF に設定されます。 したがって、新たに復元されたデータベースでは TRUSTWORTHY は常に OFF です。
アクセス許可
BACKUP DATABASE 権限と BACKUP LOG 権限は、既定では、 sysadmin 固定サーバー ロール、 db_owner 固定データベース ロール、および db_backupoperator 固定データベース ロールのメンバーに与えられています。 詳細については、「BACKUP (Transact-SQL)」を参照してください。
復元するデータベースがサーバー インスタンスに存在しない場合、RESTORE ステートメントに CREATE DATABASE 権限が必要です。 詳細については、「RESTORE (Transact-SQL)」を参照してください。
SQL Server Management Studio を使用します
Note
バックアップ ファイルと復元ファイルのパスが、プライマリ レプリカをホストするサーバー インスタンスとセカンダリ レプリカをホストする各インスタンスとで同じ場合は、新しい可用性グループ ウィザード、可用性グループへのレプリカ追加ウィザード、または可用性グループへのデータベース追加ウィザードを使用して、セカンダリ レプリカ データベースを作成できます。
セカンダリ データベースを準備するには
プライマリ データベースの最新のバックアップがない場合は、データベースの新しい完全バックアップか差分バックアップを作成してください。 このバックアップとそれ以降のすべてのログ バックアップは、推奨されるネットワーク共有に配置することをお勧めします。
プライマリ データベースの新しいログ バックアップを 1 つ以上作成します。
Note
プライマリ レプリカのデータベースでトランザクション ログ バックアップがまだキャプチャされていない場合は、トランザクション ログ バックアップが不要な可能性があります。 Microsoft では、可用性グループに新しいデータベースを追加するたびにトランザクション ログ バックアップを実行することをお勧めします。
セカンダリ レプリカをホストするサーバー インスタンスで、プライマリ データベースの完全バックアップ (および必要に応じて差分バックアップ)、それ以降のすべてのログ バックアップの順で復元します。
[RESTORE DATABASE オプション] ページで、 [データベースは操作不可状態のままで、コミットされていないトランザクションはロールバックしない。別のトランザクション ログは復元できます。] (RESTORE WITH NORECOVERY) を選択します。
プライマリ データベースとセカンダリ データベースのファイル パスが異なる場合、たとえばプライマリ データベースはドライブ "F:" にあり、セカンダリ レプリカをホストするサーバー インスタンスに F: ドライブがない場合は、WITH 句に MOVE オプションを含めてください。
セカンダリ データベースの構成を完了するには、セカンダリ データベースを可用性グループに参加させる必要があります。 詳細については、「可用性グループへのセカンダリ データベースの参加 (SQL Server)」を参照してください。
Note
これらのバックアップ操作および復元操作の実行方法については、このセクションの「 関連するバックアップと復元のタスク」を参照してください。
関連するバックアップおよび復元のタスク
データベースのバックアップを作成するには
ログ バックアップを作成するには
バックアップを復元するには
Transact-SQL の使用
セカンダリ データベースを準備するには
Note
この手順の例については、このトピックの「 例 (Transact-SQL)」を参照してください。
プライマリ データベースの最新の完全バックアップがない場合は、プライマリ レプリカをホストするサーバー インスタンスに接続し、データベースの完全バックアップを作成してください。 このバックアップとそれ以降のすべてのログ バックアップは、推奨されるネットワーク共有に配置することをお勧めします。
セカンダリ レプリカをホストするサーバー インスタンスで、プライマリ データベースの完全バックアップ (および必要に応じて差分バックアップ)、それ以降のすべてのログ バックアップの順で復元します。 すべて復元操作に WITH NORECOVERY を使用します。
プライマリ データベースとセカンダリ データベースのファイル パスが異なる場合、たとえばプライマリ データベースはドライブ "F:" にあり、セカンダリ レプリカをホストするサーバー インスタンスに F: ドライブがない場合は、WITH 句に MOVE オプションを含めてください。
必要なログ バックアップ以降にプライマリ データベースのログ バックアップを作成した場合は、それらのログ バックアップもセカンダリ レプリカをホストするサーバー インスタンスにコピーして、各ログ バックアップをセカンダリ データベースに適用する必要があります。その際には古いものから順に適用し、毎回 RESTORE WITH NORECOVERY を使用します。
Note
プライマリ データベースを作成したばかりでログ バックアップがまだ作成されていない場合や、復旧モデルを単純から完全に変更したばかりの場合には、ログ バックアップが存在しない可能性があります。
セカンダリ データベースの構成を完了するには、セカンダリ データベースを可用性グループに参加させる必要があります。 詳細については、「可用性グループへのセカンダリ データベースの参加 (SQL Server)」を参照してください。
Note
これらのバックアップ操作および復元操作の実行方法については、このトピックの「 関連するバックアップと復元のタスク」を参照してください。
Transact-SQL の例
次の例では、セカンダリ データベースを準備します。 この例では、既定で単純復旧モデルを使用する AdventureWorks2022 サンプル データベースを使用します。
AdventureWorks2022データベースを使用するには、完全復旧モデルが使用されるように変更します。USE master; GO ALTER DATABASE MyDB1 SET RECOVERY FULL; GOデータベースの復旧モデルを SIMPLE から FULL に変更した後は、完全バックアップを作成します。作成した完全バックアップはセカンダリ データベースの作成に使用できます。 復旧モデルを変更した直後なので、新しいメディア セットを作成するには WITH FORMAT オプションを指定します。 これにより、完全復旧モデルのバックアップを、単純復旧モデルで作成された以前のバックアップと分離できます。 この例では、バックアップ ファイル (C:\
AdventureWorks2022.bak) をデータベースと同じドライブに作成します。Note
運用データベースを使用する場合は、必ず別のデバイスにバックアップしてください。
プライマリ レプリカをホストするサーバー インスタンス (
INSTANCE01) 上で、次のとおりプライマリ データベースの完全バックアップを作成します。BACKUP DATABASE MyDB1 TO DISK = 'C:\MyDB1.bak' WITH FORMAT GOセカンダリ レプリカをホストするサーバー インスタンスに完全バックアップをコピーします。
RESTORE WITH NORECOVERY を使用して、セカンダリ レプリカをホストするサーバー インスタンスに完全バックアップを復元します。 復元コマンドは、プライマリ データベースとセカンダリ データベースのパスが同じかどうかによって変わります。
パスが同じ場合は、次のようにします。
セカンダリ レプリカをホストするコンピューターで、次のとおり完全バックアップを復元します。
RESTORE DATABASE MyDB1 FROM DISK = 'C:\MyDB1.bak' WITH NORECOVERY GOパスが異なる場合は、次のようにします。
セカンダリ データベースのパスがプライマリ データベースのパスと異なる (たとえば、ドライブ文字が異なる) 場合、セカンダリ データベースを作成するには、復元操作に MOVE 句が必要です。
重要
プライマリ データベースとセカンダリ データベースのパス名が異なる場合は、ファイルを追加することはできません。 ファイル追加操作のログの受信時に、セカンダリ レプリカのサーバー インスタンスがプライマリ データベースで使用されるのと同じパスに新しいファイルを配置しようとするためです。
たとえば、次のコマンドは、既定の SQL Serverインスタンスのデータ ディレクトリ (C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA) に存在するプライマリ データベースのバックアップを復元します。 データベースの復元操作では、別のクラスター ノードのセカンダリ レプリカをホストする、(SQL Server AlwaysOn1) というのリモート インスタンスのデータ ディレクトリにデータベースを移動する必要があります。 そこで、データおよびログ ファイルが C:\Program Files\Microsoft SQL Server\MSSQL13.Always On1\MSSQL\DATA ディレクトリに復元されます。 この復元操作では WITH NORECOVERY を使用してセカンダリ データベースを復元するデータベースに残します。
RESTORE DATABASE MyDB1 FROM DISK='C:\MyDB1.bak' WITH NORECOVERY, MOVE 'MyDB1_Data' TO 'C:\Program Files\Microsoft SQL Server\MSSQL13.Always On1\MSSQL\DATA\MyDB1_Data.mdf', MOVE 'MyDB1_Log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL13.Always On1\MSSQL\DATA\MyDB1_Data.ldf'; GO
完全バックアップを復元した後、プライマリ データベースでログ バックアップを作成する必要があります。 たとえば、次の Transact-SQL ステートメントは、ログを E:\MyDB1_log.trn というバックアップ ファイルにバックアップします。
BACKUP LOG MyDB1 TO DISK = 'E:\MyDB1_log.trn' GOデータベースをセカンダリ レプリカに参加させるには、必要なログ バックアップ (およびそれ以降のすべてのログ バックアップ) を事前に適用する必要があります。
たとえば、次の Transact-SQL ステートメントは、最初のログを C:\MyDB1.trn から復元します。
RESTORE LOG MyDB1 FROM DISK = 'E:\MyDB1_log.trn' WITH FILE=1, NORECOVERY GOデータベースをセカンダリ レプリカに参加させる前に追加のログ バックアップが行われた場合は、RESTORE WITH NORECOVERY を使用して、それらすべてのログ バックアップもセカンダリ レプリカをホストするサーバー インスタンスに順番に復元する必要があります。
たとえば、次の Transact-SQL ステートメントは、2 つの追加のログを E:\MyDB1_log.trn から復元します。
RESTORE LOG MyDB1 FROM DISK = 'E:\MyDB1_log.trn' WITH FILE=2, NORECOVERY GO RESTORE LOG MyDB1 FROM DISK = 'E:\MyDB1_log.trn' WITH FILE=3, NORECOVERY GO
PowerShell の使用
セカンダリ データベースを準備するには
プライマリ データベースの最新のバックアップを作成する必要がある場合は、プライマリ レプリカがホストされているサーバー インスタンスにディレクトリを変更します (cd)。
Backup-SqlDatabase コマンドレットを使用して各バックアップを作成します。
ディレクトリ変更コマンド (cd) を使用して、セカンダリ レプリカがホストされているサーバー インスタンスに移動します。
各プライマリ データベースのデータベースおよびログ バックアップを復元するには、 restore-SqlDatabase コマンドレットを使用して、 NoRecovery 復元パラメーターを指定します。 プライマリ レプリカをホストするコンピューターとターゲット セカンダリ レプリカをホストするコンピューターとでファイル パスが異なる場合は、 RelocateFile 復元パラメーターも使用します。
Note
コマンドレットの構文を表示するには、 PowerShell 環境で Get-Help SQL Server コマンドレットを使用します。 詳細については、「 Get Help SQL Server PowerShell」を参照してください。
セカンダリ データベースの構成を完了するには、セカンダリ データベースを可用性グループに参加させる必要があります。 詳細については、「可用性グループへのセカンダリ データベースの参加 (SQL Server)」を参照してください。
SQL Server PowerShell プロバイダーを設定して使用するには
バックアップと復元のスクリプトとコマンドのサンプル
次の PowerShell コマンドは、データベースの完全バックアップとトランザクション ログをネットワーク共有にバックアップし、その共有からこれらのバックアップを復元します。 この例では、データベースの復元先のファイル パスとデータベースがバックアップされたファイル パスが同じであると想定しています。
# Create database backup
Backup-SqlDatabase -Database "MyDB1" -BackupFile "\\share\backups\MyDB1.bak" -ServerInstance "SourceMachine\Instance"
# Create log backup
Backup-SqlDatabase -Database "MyDB1" -BackupAction "Log" -BackupFile "\\share\backups\MyDB1.trn" -ServerInstance "SourceMachine\Instance"
# Restore database backup
Restore-SqlDatabase -Database "MyDB1" -BackupFile "\\share\backups\MyDB1.bak" -NoRecovery -ServerInstance "DestinationMachine\Instance"
# Restore log backup
Restore-SqlDatabase -Database "MyDB1" -BackupFile "\\share\backups\MyDB1.trn" -RestoreAction "Log" -NoRecovery -ServerInstance "DestinationMachine\Instance"
次のステップ
セカンダリ データベースの構成を完了するには、新たに復元したデータベースを可用性グループに参加させる必要があります。 詳細については、セカンダリ データベースの可用性グループへの参加 (SQL Server) に関するページを参照してください。
関連項目
Always On 可用性グループの概要 (SQL Server)
BACKUP (Transact-SQL)
RESTORE の引数 (Transact-SQL)
RESTORE (Transact-SQL)
失敗したファイルの追加操作のトラブルシューティング (AlwaysOn 可用性グループ)
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示