web-dev-qa-db-ja.com

手動シードによる分散可用性グループ

手動シードを使用して分散型可用性グループをセットアップする方法について、順を追って説明します。自動シードを機能させることはできますが、手動でシードしようとすると、フォワーダーのAGにセカンダリデータベースを取得できません。

データベースを通常のAGに追加しようとする前に分散AGをセカンダリに追加すると、次のメッセージが表示されます。

Msg 41190, Level 16, State 7, Line 22
Availability group 'MYDB' failed to process add-database command.  The local availability replica is not in a state that could process the command.  Verify that the availability group is online and that the local availability replica is the primary replica, then retry the command. 

セカンダリでDistributed AGに参加せずに最初にDBを追加しようとすると、プライマリであると見なされるため、次のメッセージが表示されます。

Msg 927, Level 14, State 2, Line 22
Database 'MYDB' cannot be opened. It is in the middle of a restore.

自動シーディングではこれらの問題はありません。すべてが魔法のように機能します。私がオンラインで見つけた例はすべて自動シードを使用しています。

前もって感謝します

8
Alf47

TL; DR:

DAGに参加する前にデータベースを前方にAGに追加した可能性があるという現在の説明とコメントからのように聞こえます。代わりに、最初にDAGを結合し、、次にデータベースを次の順序で追加します。

  1. AG1 を作成します
    • AG1にデータベースを追加する
  2. AG2を作成(データベースなし)
  3. DAGを作成する
    • AG 1と2をAG1からDAGに参加させる
    • AG 1と2をAG2からDAGに参加させる
  4. AG2にデータベースを追加する
  5. 利益?

より長い(より)フォームの回答

たくさんのもの...を仮定すると...

  1. リスナー/クラスター/インスタンスはすでに構成されています
  2. AGは既に存在します...
    • PRIMARYFORWARDERの両方で
    • それは同じAGではありません
    • どちらも既に別のDAGのメンバーではない
    • FORWARDER AGは空で、シードする準備ができています
  3. 両方のレプリカからアクセスできる共有ストレージがあります

... あなたはできる... 次のスクリプトはsqlcmd形式です。

ステップ0. |OLD_AG|のログバックアップを無効にする(オプション)

次の場合は、この手順を無視できます。

  1. プロセスの最後の「moving target」LSNを気にしない場合、または
  2. AG内のすべてのデータベースのログバックアップウィンドウ内でプロセス全体を完了することができます。

手順1. DAGを作成する

現在のプライマリでCREATE 1回、見込みフォワーダーでALTER ... JOIN。適切なサービスアカウントとして実行し、ユーザーアカウントが所有するアーキテクチャの一部になってしまうことがないようにします。

現在のPRIMARY...

:connect |OLD_AG|.|DOMAIN|
execute as login = 'sa'

-- double check local replica is manual seeding first
alter availability group [|OLD_AG|]
    modify replica on '|THIS_REPLICA|'
    with (seeding_mode = manual);

create availability group [|DAG_X|]
    with (distributed)
    availability group on 
        '|OLD_AG|' with ( 
            listener_url      = 'TCP://|OLD_AG|.|DOMAIN|:|PORT|',
            availability_mode = synchronous_commit,
            failover_mode     = manual,
            seeding_mode      = manual 
        ),
        '|NEW_AG|' with ( 
            listener_url      = 'TCP://|NEW_AG|.|DOMAIN|:|PORT|',
            availability_mode = synchronous_commit,
            failover_mode     = manual,
            seeding_mode      = manual 
        );
go

将来のFORWARDER...

:connect |NEW_AG|.|DOMAIN|
execute as login = 'sa'

alter availability group [|DAG_X|]
    join availability group on 
        '|OLD_AG|' with ( 
            listener_url      = 'TCP://|OLD_AG|.|DOMAIN|:|PORT|',
            availability_mode = synchronous_commit,
            failover_mode     = manual,
            seeding_mode      = manual 
        ),
        '|NEW_AG|' with ( 
            listener_url      = 'TCP://|NEW_AG|.|DOMAIN|:|PORT|',
            availability_mode = synchronous_commit,
            failover_mode     = manual,
            seeding_mode      = manual 
        );
go

ステップ2.完全バックアップ

ご存知ですか copy_only fullsにログバックアップを追加できます ?ごく最近まで私もしませんでした!ただし、ここでcopy_onlyを使用すると、

  1. バックアップチェーンをあらゆる不正行為から保護し、
  2. プロセスの最後の復元チェーンの長さを短くします。

exec as...は、このステップに厳密には必要ありません。

:connect |OLD_AG|.|DOMAIN|

backup database DB1 to disk = N'\\my.shared.storage\backups\DB1.bak' 
    with copy_only, compression;
backup database DB2 to disk = N'\\my.shared.storage\backups\DB2.bak' 
    with copy_only, compression;
go

ステップ3.復元

もう一度、適切なサービスアカウントとして実行します。

:connect |NEW_AG|.|DOMAIN|
execute as login = 'sa'

restore database DB1 from disk = N'\\my.shared.storage\backups\DB1.bak' 
    with norecovery;
restore database DB2 from disk = N'\\my.shared.storage\backups\DB2.bak' 
    with norecovery;
go

ステップ3(b)。ログのバックアップをオンのままにしましたか?

Nbd、しかしそれらを今追加します¯\ _(ツ)_ /¯

  1. 適切なサービスアカウントとして実行する
  2. with norecovery

手順4.フォワーダーで、DBを新しいAGに参加させる

:connect |NEW_AG|.|DOMAIN|
execute as login = 'sa'

alter database DB1 set hadr availability group = [|NEW_AG|];
alter database DB2 set hadr availability group = [|NEW_AG|];
go
6
Peter Vandivier

から 分散型可用性グループ

分散型可用性グループは、自動シードを使用して、2番目の可用性グループのプライマリレプリカを初期化するために使用される主な方法として設計されました。

次の場合、2番目の可用性グループのプライマリレプリカでデータベース全体を復元できます。

  • データベースバックアップWITH NORECOVERYを復元します。
  • 必要に応じて、NORECOVERYを指定して適切なトランザクションログバックアップを復元します。
  • データベース名を指定せず、SEEDING_MODE set to AUTOMATICを使用して2番目の可用性グループを作成します。
  • 自動シードを使用して、分散可用性グループを作成します。
0
user162314