none
AlwaysOnにバックアップで初回同期後、セカンダリレプリカは同期されれずDBが復元中になる RRS feed

  • 質問

  • SQL Server 2012、2016で簡単なAlwaysOnの可用性グループの作成のテストを行っています。

    可用性グループの作成には成功しますが、セカンダリレプリカが「同期されていない」状態となってしまいます。
    OSはWindows Server 2012R2、2016の両方で検証、結果は同じ、SQL Serverも2012、2016の両方で検証し同じ結果です。
    環境は、ローカルのVirtualBox内の2台のSQL Server(ADサーバー1台)の環境とAzure上で同様の環境の2つの環境で実施。結果は同じ。

    検証手順をざっくりまとめると

    1.2台のWindows Server(2012R2 or 2016)を新規に構築しADに参加させる
    2.SQL Server(2012 or 2016)をインストール、SSMSをインストール
    3.フェイルオーバークラスターをインストール
    4.クラスターを作成
     ※特にクォーラム等の設定は無し
     ※Azure上の場合は、クラスターコアリソースのIPアドレスを受け付ける内部ロードバランサを追加で作成、新たなIPを作成
    4.SQL Server構成マネージャーでSQL Serverサービスのユーザーをドメインユーザー(Domain Admins)に変更し、AlwaysOnを有効化
    5.1号機側でテスト用のデータベースを作成、mdfとldfのファイルパスと同じものを2号機側に作成
     ※データベースの復旧モデルは完全、その他の設定はGUIでのデフォルトのまま
    6.1号機側で完全バックアップを取得
     ※バックアップ先は1号機のローカル
    7.1号機に共有フォルダを作成(権限はEveryone FullControl)
    8.可用性グループ作成ウィザードにて、作成したデータベースを2台のSQL Serverで可用性レプリカを作成
     ※可用性モードは両サーバー共にに同期コミット
     ※読取り可能なセカンダリは両サーバーともにいいえ
     ※自動フェールオーバーの設定は無し
     ※リスナーは作成しない
     ※その他は全てSSMSデフォルト
    9.データの同期設定を選択にて「完全なデータベースとログバックアップ」を選択
     ※ファイル共有パスは1号機に作成した共有フォルダ
    10.検証結果はリスナーの警告以外は全て成功
     ※リスナーを作成して検証すると全て成功になる
    11.ウィザードは正常に終了
     ※「ログの復元」も成功と表示される
    12.下記の状態でセカンダリレプリカの同期がされない
     ※セカンダリレプリカの同期状態は「接続されていません」となったまま変化しない
     ※2号機に接続したSSMSからデータベースを確認すると「復元しています...」の状態になったまま(オブジェクトエクスプローラでアクセス出来ない)
    13.1号機、2号機のSQL ServerのERRORLOGには下記の行のみが記録
     ※2号機にもmfd、ldfファイルは作成されている
     ※データベース名は「DB2」、サーバー名はそれぞれ「SQL1」、「SQL2」

    <1号機>

    2020-07-03 11:11:56.37 spid51      Starting up database 'DB2'.
    2020-07-03 11:11:56.39 spid51      Setting database option COMPATIBILITY_LEVEL to 110 for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option ANSI_NULL_DEFAULT to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option ANSI_NULLS to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option ANSI_PADDING to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option ANSI_WARNINGS to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option ARITHABORT to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option AUTO_CLOSE to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option AUTO_SHRINK to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option AUTO_CREATE_STATISTICS to ON for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option AUTO_UPDATE_STATISTICS to ON for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option CURSOR_CLOSE_ON_COMMIT to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option CURSOR_DEFAULT to GLOBAL for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option CONCAT_NULL_YIELDS_NULL to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option NUMERIC_ROUNDABORT to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option QUOTED_IDENTIFIER to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option RECURSIVE_TRIGGERS to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option DISABLE_BROKER to ON for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option AUTO_UPDATE_STATISTICS_ASYNC to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option DATE_CORRELATION_OPTIMIZATION to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option PARAMETERIZATION to SIMPLE for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option READ_COMMITTED_SNAPSHOT to OFF for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option READ_WRITE to ON for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option RECOVERY to FULL for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option MULTI_USER to ON for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option PAGE_VERIFY to CHECKSUM for database 'DB2'.
    2020-07-03 11:11:56.40 spid51      Setting database option target_recovery_time to 0 for database 'DB2'.
    2020-07-03 11:13:44.28 Backup      Database backed up. Database: DB2, creation date(time): 2020/07/03(11:11:56), pages dumped: 298, first LSN: 31:108:73, last LSN: 31:141:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\DB2.bak'}). This is an informational message only. No user action is required.
    2020-07-03 11:13:44.30 Backup      BACKUP DATABASE successfully processed 291 pages in 0.017 seconds (133.300 MB/sec).
    2020-07-03 11:18:16.06 spid51      Starting up database 'BackupLocDb_8bf6a91c-1226-426d-90be-8edabd0d3ddc'.
    2020-07-03 11:18:16.13 spid51      Setting database option RECOVERY to FULL for database 'BackupLocDb_8bf6a91c-1226-426d-90be-8edabd0d3ddc'.
    2020-07-03 11:18:16.13 spid51      Setting database option RESTRICTED_USER to ON for database 'BackupLocDb_8bf6a91c-1226-426d-90be-8edabd0d3ddc'.
    2020-07-03 11:18:16.22 Backup      Database backed up. Database: BackupLocDb_8bf6a91c-1226-426d-90be-8edabd0d3ddc, creation date(time): 2020/07/03(11:18:16), pages dumped: 290, first LSN: 31:60:64, last LSN: 31:90:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'\\SQL1\Share\BackupLocDb_8bf6a91c-1226-426d-90be-8edabd0d3ddc.bak'}). This is an informational message only. No user action is required.
    2020-07-03 11:18:16.25 Backup      BACKUP DATABASE successfully processed 282 pages in 0.021 seconds (104.864 MB/sec).
    2020-07-03 11:19:30.25 spid51      The state of the local availability replica in availability group 'AG2' has changed from 'NOT_AVAILABLE' to 'RESOLVING_NORMAL'. The replica state changed because of either a startup, a failover, a communication issue, or a cluster error. For more information, see the availability group dashboard, SQL Server error log, Windows Server Failover Cluster management console or Windows Server Failover Cluster log. 
    2020-07-03 11:19:30.60 spid55      AlwaysOn: The local replica of availability group 'AG2' is preparing to transition to the primary role in response to a request from the Windows Server Failover Clustering (WSFC) cluster. This is an informational message only. No user action is required.
    2020-07-03 11:19:30.60 spid55      The state of the local availability replica in availability group 'AG2' has changed from 'RESOLVING_NORMAL' to 'PRIMARY_PENDING'. The replica state changed because of either a startup, a failover, a communication issue, or a cluster error. For more information, see the availability group dashboard, SQL Server error log, Windows Server Failover Cluster management console or Windows Server Failover Cluster log. 
    2020-07-03 11:19:30.60 Server      The lease worker of availability group 'AG2' is now sleeping the excess lease time (164656 ms) supplied during online. This is an informational message only. No user action is required.
    2020-07-03 11:19:30.63 Server      The state of the local availability replica in availability group 'AG2' has changed from 'PRIMARY_PENDING' to 'PRIMARY_NORMAL'. The replica state changed because of either a startup, a failover, a communication issue, or a cluster error. For more information, see the availability group dashboard, SQL Server error log, Windows Server Failover Cluster management console or Windows Server Failover Cluster log. 
    2020-07-03 11:19:30.80 spid36s     A connection for availability group 'AG2' from availability replica 'SQL1' with id  [946CF135-5911-4768-BADE-2F88FDE1454B] to 'SQL2' with id [4617128F-6E69-4043-9698-B4BC3FA13CB2] has been successfully established.  This is an informational message only. No user action is required.
    2020-07-03 11:19:30.90 Backup      Database backed up. Database: DB2, creation date(time): 2020/07/03(11:11:56), pages dumped: 298, first LSN: 31:193:70, last LSN: 31:224:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'\\SQL1\Share\DB2.bak'}). This is an informational message only. No user action is required.
    2020-07-03 11:19:30.91 Backup      BACKUP DATABASE successfully processed 290 pages in 0.017 seconds (133.243 MB/sec).
    2020-07-03 11:19:31.06 Backup      Log was backed up. Database: DB2, creation date(time): 2020/07/03(11:11:56), first LSN: 31:108:73, last LSN: 31:224:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'\\SQL1\Share\DB2.trn'}). This is an informational message only. No user action is required.

    <2号機>

    2020-07-03 11:19:30.91 spid51      The state of the local availability replica in availability group 'AG2' has changed from 'NOT_AVAILABLE' to 'RESOLVING_NORMAL'. The replica state changed because of either a startup, a failover, a communication issue, or a cluster error. For more information, see the availability group dashboard, SQL Server error log, Windows Server Failover Cluster management console or Windows Server Failover Cluster log. 
    2020-07-03 11:19:30.92 spid37s     The state of the local availability replica in availability group 'AG2' has changed from 'RESOLVING_NORMAL' to 'SECONDARY_NORMAL'. The replica state changed because of either a startup, a failover, a communication issue, or a cluster error. For more information, see the availability group dashboard, SQL Server error log, Windows Server Failover Cluster management console or Windows Server Failover Cluster log. 
    2020-07-03 11:19:31.00 spid40s     A connection for availability group 'AG2' from availability replica 'SQL2' with id  [4617128F-6E69-4043-9698-B4BC3FA13CB2] to 'SQL1' with id [946CF135-5911-4768-BADE-2F88FDE1454B] has been successfully established.  This is an informational message only. No user action is required.
    2020-07-03 11:19:31.19 spid51      Starting up database 'DB2'.
    2020-07-03 11:19:31.20 spid51      The database 'DB2' is marked RESTORING and is in a state that does not allow recovery to be run.
    2020-07-03 11:19:31.21 Backup      Database was restored: Database: DB2, creation date(time): 2020/07/03(11:11:56), first LSN: 31:193:70, last LSN: 31:224:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'\\SQL1\Share\DB2.bak'}). Informational message. No user action required.
    2020-07-03 11:19:31.22 Backup      RESTORE DATABASE successfully processed 290 pages in 0.037 seconds (61.219 MB/sec).
    2020-07-03 11:19:31.29 Backup      Log was restored. Database: DB2, creation date(time): 2020/07/03(11:11:56), first LSN: 31:108:73, last LSN: 31:224:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'\\SQL1\Share\DB2.trn'}). This is an informational message. No user action is required.


    SQL Server 2016の自動シード処理で試した場合は、正常に同期がされた状態になることは確認しています。
    ※SQL Server 2012では自動シード処理は利用出来ない、バックアップを選択した場合は同じ事象となる

    色々な文献を参考に、手順としては間違っていないはずと思っています。
    また、ログからもセカンダリレプリカのリストアまで成功している、ということが書かれている為、どこが問題なのか検討がつかない状況です。
    しかし、複数の環境、バージョン、初期構築から同手順、という検証で同様の結果になることから、環境依存の問題等ではなく、致命的な設定や手順が抜けているのでは、と考えていますが、まったく検討がつかず、何かわかることがあれば教えて下さい。


    2020年7月3日 2:31

すべての返信

  • 古いSSMSを使用している場合、ウィザードから可用性グループを構築した場合、セカンダリ側で可用性データベースへの参加コマンドが実行されないという問題があった記憶があります。

    セカンダリ(2号機)側で SSMSを起動し、AlwaysOn 高可用性 - 可用性グループ - 可用性グループ名(セカンダリ) - 可用性データベース - 該当のデータベース - 右クリック - 可用性グループへの結合 を実施することで、現象が解消するかを確認してみると良いかもしれません。

    2020年7月3日 6:38
  • ばっちょろげさん、こんにちは。フォーラムオペレーターのHarukaです。
    MSDNフォーラムにご投稿くださいましてありがとうございます。

    ご説明から、AGに結合されたインスタンスはSQL 2012とSQL 2016でしょうか。 私の認識が間違った場合はご指摘ください。 
    MSのドキュメントによると、Always on可用性グループに参加するには、各サーバーインスタンスが同じバージョンのSQL Serverを実行している必要があります。

    [Select Initial Data Synchronization]ページで[Join Only]オプションを選択したようです。 
    データベースをセカンダリレプリカに復元しないことをお勧めします。
    AGの構成中に以下のスクリーンショットのように「完全」オプションを選択してみてください。


    Step-By-Step: Creating a SQL Server Always on Availability Group Steps for Installing SQL Server Always on Availability Groupsをご参照いただければと思います。

    どうぞよろしくお願いいたします。

    MSDN/ TechNet Community Support Haruka
    ~参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、 ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、MSDNFSF@microsoft.comまでお気軽にお問い合わせください。~

    2020年7月9日 8:10
    モデレータ
  • ばっちょろげさん、こんにちは。フォーラムオペレーターのHarukaです。
    MSDNフォーラムにご投稿くださいましてありがとうございます。

    ご質問いただいた件ですが、その後いかがでしょうか。
    追加でご確認いただいたことなどあれば、追記いただくことで回答がつきやすくなります。

    また、皆さんから寄せられた投稿はお役に立ちましたか。
    参考になった投稿には [回答としてマーク] をお願い致します。

    設定いただくことで、
    他のユーザーもお役に立つ回答を見つけやすくなります。

    お手数ですが、ご協力の程どうかよろしくお願いいたします。

    MSDN/ TechNet Community Support Haruka
    ~参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、 ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、MSDNFSF@microsoft.comまでお気軽にお問い合わせください。~

    2020年7月14日 6:23
    モデレータ