はじめに
タイトル通り、以前はMicrosoftの手順に従ってDistributorをPublisherと同じインスタンスに構築しましたが、今度はレプリカ先のSubscriber側に作成していきます。
今回はPublishar、Subscriber共にSQL Server2016で実施します。
前回記事は以下
capybara-engineer.hatenablog.com
capybara-engineer.hatenablog.com
実施内容
実施作業
構成確認&補足知識
前回までで参考にしたチュートリアルでは以下のような構成となっていました。
※マージレプリケーション用のものは除外済み
この時の各エージェントと実行されているタスクの流れは以下のようになっています。
※こう理解したという内容を書いているので、もしかしたら細かい部分が間違っているかもしれません
- スナップショットエージェント
- ログリーダーエージェント
- ディストリビューションエージェント
以下のチュートリアル手順を見ていると、どの手順がPublishar、Distributor、Subscriberのどこで設定されるべき手順なのかがちょっとわかりにくいです。
docs.microsoft.com
docs.microsoft.com
そこで公式ドキュメントの確認して、どこで設定されるか確認した結果を踏まえて明確に分離したところ、以下のようになりました。
これはトランザクションレプリケーションに絞って書いたものですが、基本的に実行するエージェントはDistributorで設定する必要があり、それに関してはPublisharで設定する内容はほとんどありません。
※Publisharで設定する内容がないわけではない
またPublisharとDistributorを分ける場合は、以下の手順でDistributor側でリモートPublisharの設定をする必要があります。
docs.microsoft.com
他にも、今回のように同じドメイン内に存在しないコンピュータ同士でレプリケーションする場合は、エージェントが接続を確立するために以下の通り認証方式を設定する必要があります。
仮にプッシュサブスクリプションでDistributorとSubscriberを接続させたい場合、ディストリビューションエージェントのWindowsアカウントをDistributor及びSubscriberで作成します。
※チュートリアルはこのパターンです
ここでサブスクリプションという言葉が出てきましたが、これは簡単に言うとPublisharとSubscriberのデータの同期方法です。
プッシュサブスクリプションとプルサブスクリプションの2通りあります。
それぞれ、Publishar→Subscriberへ変更を同期するのか、Subscriber→Publisharへ変更を同期するのかの違いがあります。
それぞれの違いについては以下の表に記載しておきます。
docs.microsoft.com
サブスクリプションの作成方法についてはこちらをご確認ください。
docs.microsoft.com
今回の構築で特に詰まったのは上記表でいうエージェントの権限設定です。
公式ドキュメントを確認しながら見やすいようにこちらも表にしたので、載せておきます。
docs.microsoft.com
以上のことを踏まえた上で、以下の構成の構築をしていきます。
事前準備
①必要なアカウントを作成します。
- Publishar側
- Subscriber側
②レプリケーション用のサンプルDBを作成します。
具体的な手順は以下記事参照
capybara-engineer.hatenablog.com
ここまでできたら実際に構築を行なっていきます。
Distributor構築
まずはレプリケーション先のサーバーでDistributionを作成します。
Replicationフォルダを右クリック→[Configure Distribution...]を押下してDistribution構築ウィザードを立ち上げます。
Distributorは現在のサーバー上に構築するようにします。
スナップショットフォルダーは事前に共有化設定済みのフォルダを指定します。
※今回はPublisharが別サーバ―なので、権限は全アカウントに対してフル権限を設定します。
Distribution Databaseは規定値のまま設定します。
※この時database fileとdtabase log fileを別のディスクドライブに設定するとパフォーマンス効率が向上します。
次にDistributorで操作するPublisharを設定します。
今回は別サーバ上のPublisharを設定するので、チェックを外してAddボタンからPublisharの追加をします。
接続情報を入力してConnectボタンを押下します。
接続が確認出来たらチェックが付いた状態でPublisharに追加されるので、そのまま次へいきます。
PublisharからこのDistributorを操作するための管理パスワードを設定します。
※このパスワードを設定するとdistributor_adminというユーザが作成され、そのユーザのパスワードとして設定されます。
あとは規定値で進めます。
以下のようにエラーが出なければDistributorの設定は完了です。
※作成後Distributor用のユーザが作成されているので、ユーザのプロパティからdistribution databaseのdb_ownerロールを追加しておきます。
distributionデータベースが作成されたので、最初に作成したWindowsアカウントとそのデータベースをマッピングします。
Publishar構築(レプリケーション元)
次にレプリケーション元のサーバーでPublicationを作成します。
最初に作成したWindowsアカウントとレプリケーション元のDBのマッピングをします。
- スナップショットアカウント
- ログリーダーアカウント
そのあとLocal Publicationsフォルダを右クリック→[New Publication...]を押下してPublication構築ウィザードを立ち上げます。
今回はDistributorは別サーバー上に構築しているため、それを追加します。
接続の際はDistribution構築時に自動で作成されたdistributor_adminユーザとそのパスワードを使用して接続します。
※ここはそのDBに接続できるユーザとパスワードであれば上記のユーザでなくても問題ありません。
無事に接続できたら次に行きます。
ここで再度distributor_adminユーザのパスワードを設定します。
Publication対象のDBを選択します。
Publication方法を選択します。
※トランザクションレプリケーションを行うので、ここでは[Transactional publication]を選びます。
レプリケーションするアーティクルを選択します。
データに対してのFilterは特にせずに次に行きます。
スナップショットをすぐに作成して初期化するチェックを入れて次に行きます。
スナップショットエージェントとログリーダーエージェントを実行するユーザを設定します。
Publicationを作成するチェックを入れて次にいきます。
Publication名を入れて終了を押下します。
うまくいけばここで成功するのですが、何故かログリーダーエージェントで設定したユーザでエラーが発生しました。
ログリーダーエージェントはDistributionデータベースに接続するはずなので、Distributor側で同じアカウント名・パスワードを持つWindowsアカウントを作成してみましたが、変わりませんでした。
試しにとDistributor側で作成したユーザを指定して再度実施してみたところ、エラーの内容がログリーダーエージェント用のアカウントからスナップショットエージェント用のアカウントのエラーに変わりました。
もしかしてと思い、スナップショットエージェント用のアカウントもDistributor側のアカウントを指定するように変更してみたところ、問題なくPublicationが作成されました。
恐らくですが、エージェントをメインで実行するのはDistributer側で、別サーバー上のPublisharで同名、同パスワードのアカウントを作成しておくことで、レプリケーション時に自動で実行してくれるということではないかと思っています。
※詳しくは確認していません。
スナップショットエージェントのステータス確認
設定できたらスナップショットエージェントのステータスを確認します。
共有フォルダにアクセスができなくてエラーになっているようです。
共有フォルダのセキュリティ設定で、作成したログリーダーエージェント用のアカウントとスナップショットエージェント用のアカウントを追加します。
※スナップショットのみフル権限、ログリーダーは読み取り権限にします。
※ついでに共有の権限にも設定しておきます。
再度実行してスナップショットエージェントが正常に完了したことを確認します。
Subscriber構築
最後にレプリケーション元のサーバーでSubscriptionの作成を行なっていきます。
Subscriberだからレプリケーション先のサーバー上で作成するんじゃないのかと思われるかもしれませんが、今回はプッシュサブスクリプションを使用して、Publisharの変更をSubscriberに対して同期するような方法になるので、Publication側で実施します。
※プルサブスクリプションであれば、Subscriber側で実施します。
Local Publicationsフォルダ配下のPublicationを右クリック→[New Subscriptions...]を押下してSubscription構築ウィザードを立ち上げます。
Publicationには、先ほど作成したものを指定します。
サブスクリプション方法を指定します。
今回はプッシュサブスクリプションを指定します。
※ここで、すべてのエージェントをDistributorで実行するように設定することになっているのに気が付きました。
※そもそもDistributorを分けた時点で、Publisharでエージェントは実行されないようですね。(間接的には実行されているかもしれませんが)
別サーバー上に構築しているSQL ServerをSubscriberとして指定します。
レプリカDBは新規で作成します。
ディストリビューションエージェントを実行するユーザを設定します。
同期スケジュールはすぐに実行するようにします。
Subscriptionの初期化も即時実行されるように設定します。
Subscriptionを作成するにチェックを付けます。
設定を完了します。
問題なければ作成は完了します。
レプリケーション確認
作成したレプリカDB内にレプリケーションしたテーブルが存在しているか確認したところ、何故か作成されていませんでした。
Job Historyを確認したところ、レプリカDBへのログインに失敗しているとのこと。
Message: Cannot open database "Replica2016" requested by the login. The login failed.
レプリカDBを作成した後にログインユーザに対してマッピングを行っていなかったので、設定します。
※スナップショットのユーザは不要な気もしましたが、念のため設定しました。
設定後少ししたらレプリカDBにレプリケーション指定したテーブルが存在していました。
レプリカDBに対してのクエリも問題なくできました。
レプリケーション元のDBでデータを更新します。
レプリケーション先のDBに即時反映されることが確認できました。
感想及び所感
最初は簡単にできるだろうと思っていましたが、思いの外時間がかかりました。
基本的には公式ドキュメントを読み漁りながら設定をしているのですが、中々ドキュメント通りに設定できなかったり、出力されたエラーについての情報が極端に少なかったりして、かなり大変でした。
一番効果的だった方法としては、やはりドキュメントの内容を図示化して全体の構成を理解することで、そのおかげで少しずつおかしい点が見えてきたので、やはりちゃんと理解することは大切だなと再認識しました。
ただ、Publicationのアクセスリストを設定しようとした際に、Distributorのユーザを追加できなかった(ドキュメントもない)ことなどドキュメントだけでは原因がわからないことが多かったです。
今回のようなDistributorをSubscriber側で構築したいという内容は、他の事例でも全然ありそうなものなので、ぜひチュートリアルに入れていただきたいものです。。
何はともあれ、設定できてよかったです。
もし認識が間違っていたり、変なこと言っていたりしたらご指摘ください。
最後に構築した構成図(修正版)を載せておきます。