AlwaysOn パブリケーション データベースのメンテナンス (SQL Server)
このトピックでは、AlwaysOn 可用性グループを使用するときのパブリケーション データベースのメンテナンスについての特別な考慮事項について説明します。
このトピックの内容
可用性グループでのパブリッシュされたデータベースのメンテナンス
可用性グループからのパブリッシュされたデータベースの削除
関連タスク
可用性グループでのパブリッシュされたデータベースのメンテナンス
AlwaysOn パブリケーション データベースのメンテナンスは、通常のパブリケーション データベースのメンテナンスと基本的に同じです。ただし、次の点を考慮する必要があります。
管理は、プライマリ レプリカ ホストで行う必要があります。 SQL Server Management Studio では、プライマリ レプリカ ホストと読み取り可能なセカンダリ レプリカの [ローカル パブリケーション] フォルダーにパブリケーションが表示されます。 フェールオーバー後、プライマリに昇格したセカンダリが読み取り不可である場合は、変更を反映させるために Management Studio を手動で更新する必要がある場合があります。
レプリケーション モニターは、常に元のパブリッシャーの下でパブリケーション情報を表示します。 ただし、元のパブリッシャーをサーバーとして追加することで、この情報を任意のレプリカからレプリケーション モニターで表示することができます。
ストアド プロシージャまたはレプリケーション管理オブジェクト (RMO) を使用して現在のプライマリでレプリケーションを管理する場合、パブリッシャー名を指定する際には、データベースのレプリケーションを有効にしたインスタンス (元のパブリッシャー) の名前を指定する必要があります。 適切な名前を決定するには、PUBLISHINGSERVERNAME 関数を使用します。 パブリッシング データベースを可用性グループに参加させると、セカンダリ データベース レプリカに格納されているレプリケーション メタデータは、プライマリにあるレプリケーション メタデータと同一になります。 その結果、プライマリでレプリケーションが有効なパブリケーション データベースでは、セカンダリのシステム テーブルに格納されるパブリッシャー インスタンス名は、セカンダリではなくプライマリの名前になります。 これにより、パブリケーション データベースがセカンダリにフェールオーバーした場合に、レプリケーションの構成およびメンテナンスに影響が出ます。 たとえば、フェールオーバー後にセカンダリでストアド プロシージャを使用してレプリケーションを構成していて、別のレプリカで有効化されたパブリケーション データベースへのプル サブスクリプションが必要な場合、sp_addpullsubscription または sp_addmergepulllsubscription の @publisher パラメーターとして現在のパブリッシャーではなく元のパブリッシャーの名前を指定する必要があります。 ただし、フェールオーバー後にパブリケーション データベースを有効にした場合、システム テーブルに格納されるパブリッシャー インスタンス名は、現在のプライマリ ホストの名前になります。 この場合、@publisher パラメーターに現在のプライマリ レプリカのホスト名を使用します。
注 sp_addpublication などの一部のプロシージャでは、@publisher パラメーターは SQL Server のインスタンスではないパブリッシャーに対してのみサポートされます。この場合は SQL Server AlwaysOn と無関係です。
フェールオーバー後に Management Studio でサブスクリプションを同期するには、サブスクライバーからプル サブスクリプションを同期し、アクティブなパブリッシャーからプッシュ サブスクリプションを同期します。
[先頭に戻る]
可用性グループからのパブリッシュされたデータベースの削除
パブリッシュされたデータベースを可用性グループから削除する場合、またはパブリッシュされたメンバー データベースを含む可用性グループを削除する場合、次の点を考慮します。
元のパブリッシャーのパブリケーション データベースを可用性グループのプライマリ レプリカから削除する場合、パブリッシャーとデータベースのペアについてのリダイレクトを削除するために、@redirected_publisher パラメーターの値を指定せずに sp_redirect_publisher を実行する必要があります。
EXEC sys.sp_redirect_publisher @original_publisher = 'MyPublisher', @published_database = 'MyPublishedDB';
データベースはプライマリで復旧中の状態のままとなり、復元する必要があります。 データベースを復元すると、レプリケーションは元のパブリッシャーに対して変更なしで動作します。
パブリケーション データベースが元のパブリッシャーからレプリカにフェールオーバーし、そのパブリケーション データベースを可用性グループのプライマリ レプリカから削除した場合、ストアド プロシージャ sp_redirect_publisher を使用して元のパブリッシャーを新しいパブリッシャーに明示的にリダイレクトします。 データベースは復旧中の状態のままとなり、復元する必要があります。 データベースを復元すると、レプリケーションは可用性グループの下で引き続き機能します。
EXEC sys.sp_redirect_publisher @original_publisher = 'MyPublisher', @published_database = 'MyPublishedDB', @redirected_publisher = 'MyNewPublisher';
元のパブリッシャーのリモート サーバーは、以降にアクセスできなくなる場合でもディストリビューターから削除しないでください。 ディストリビューターでパブリケーション メタデータ クエリに対応するために、元のパブリッシャーのサーバー メタデータが必要です。
可用性グループ全体を削除した場合、メンバーであるレプリケートされたデータベースについての動作は、パブリッシュされたデータベースを可用性グループから削除した場合と同じです。 データベースを復元し、リダイレクトを変更すると、レプリケーションを最後のプライマリから再開できます。 データベースを元のパブリッシャーで復元した場合、リダイレクトを削除する必要があります。 データベースを別のホストで復元した場合、新しいホストに対してリダイレクトを明示的に指定する必要があります。
注 メンバー データベースをパブリッシュした可用性グループを削除した場合、またはパブリッシュされたデータベースを可用性グループから削除した場合、パブリッシュされたデータベースのすべてのコピーは復旧中の状態のままとなります。 それぞれを復元すると、パブリッシュされたデータベースとして表示されます。 1 つのコピーだけをパブリケーション メタデータで保持する必要があります。 パブリッシュされたデータベース コピーのレプリケーションを無効にするには、最初にすべてのサブスクリプションとパブリケーションをデータベースから削除します。
sp_dropsubscription を実行してパブリケーション サブスクリプションを削除します。 アクティブなパブリッシング データベースのメタデータをディストリビューターで保持するために、@ignore_distributributor パラメーターを 1 に設定します。
USE MyDBName; GO EXEC sys.sp_dropsubscription @subscriber = 'MySubscriber', @publication = 'MyPublication', @article = 'all', @ignore_distributor = 1;
sp_droppublication を実行してすべてのパブリケーションを削除します。 この場合も、アクティブなパブリッシング データベースのメタデータをディストリビューターで保持するために、@ignore_distributor パラメーターを 1 に設定します。
EXEC sys.sp_droppublication @publication = 'MyPublication', @ignore_distributor = 1;
sp_replicationdboption を実行してデータベースのレプリケーションを無効にします。
EXEC sys.sp_replicationdboption @dbname = 'MyDBName', @optname = 'publish', @value = 'false';
この時点で、パブリッシュされたデータベースのコピーを保持または削除できます。
[先頭に戻る]
関連タスク
[先頭に戻る]
関連項目
概念
AlwaysOn 可用性グループの前提条件、制限事項、および推奨事項 (SQL Server)
AlwaysOn 可用性グループの概要 (SQL Server)