読み取りスケール可用性グループをお使いいただく際の注意点


皆さん、こんにちは。 BI Data Platform サポートチームです。
今回は、読み取りスケール可用性グループをお使いいただく際の注意点についてご紹介します。

構成手順について

読み取りスケール可用性グループについては下記の公開情報に解説があります。

読み取りスケール可用性グループ

現時点では具体的な構築または管理手順につきましては Linux を対象にした下記の公開情報のみとなっておりますが、本手順につきましては、Windows にも適用いただける手順です。

SQL Server on Linux の読み取りのスケールの可用性グループを構成します

必要に応じて、Linux のコマンドを Windows のコマンドなどへ置き換える必要があります。該当箇所を下記に抜き出しましたので、参考にしていただければ幸いです。


-
前提条件

Windows の場合 Hosts ファイルは既定で C:\Windows\System32\drivers\etc にございますので、管理者で実行されたメモ帳などで変更することが可能です。
「可用性レプリカをホストするすべてのサーバーが通信できるように、環境を設定します。」が目的となりますので、DNS などで名前解決ができる環境では必須ではありません。

- AlwaysOn 可用性グループを有効にし、mssql サーバーを再起動

下記弊社公開情報にて、SQL Server 構成マネージャーを使用した手順の記載がございます。
AlwaysOn 可用性グループの有効化と無効化 (SQL Server)

- 「データベース ミラーリング エンドポイントのユーザーを作成します。」~「すべてのレプリカにデータベース ミラーリング エンドポイントを作成する」

これらの設定は、下記2つの公開情報にて、より具体的に記載させていただいておりますので、ご参考にしてください。
データベース ミラーリング - 発信接続に証明書を使用する
データベース ミラーリング - 着信接続に証明書を使用する

また、下記のブログではミラーリングを前提としておりますが、上記公開情報を元に作成されております。下記のブログで手順 D3) まで実施することで、エンドポイントの構成が完了します。
非ドメイン環境上のサーバー間でミラーリングを構築する方法について

 

フェールオーバーについて

読み取りスケール可用性グループのフェールオーバーについては下記の公開情報に記載されています。

読み取りスケール可用性グループのプライマリ レプリカをフェールオーバーする

読み取りスケール可用性グループは、読み取り専用データベースを作成することで、書き込みと読み込みのデータベースを分離し、負荷を分散させることが目的であり、高可用性を目的とした機能ではありません。
そのため、高可用性を目的とした可用性グループと異なり自動的なロールの管理は無く、プライマリー/セカンダリーの各ロールの切り替え(手動フェールオーバー)は、管理者の判断により手動で行う必要があります

ロールを手動で明示的に切り変える必要があることは、何らかの障害回復を目的として非計画的に手動フェールオーバーを実施するときも、計画的に手動フェールオーバーを実施するときも同様になります。
上記の公開情報の 読み取りスケール可用性グループのプライマリ レプリカをフェールオーバーする の「データを失わずに手動フェールオーバー」の項に記載がありますように、プライマリーをセカンダリーに降格させた後に、元のセカンダリーを新しいプライマリーに昇格させるという手順が必要です。

また、プライマリー側のノードがサーバー故障によりダウンした場合、必要に応じて上記の公開情報の「データの損失の強制手動フェールオーバー」を行うことになります。
強制フェールオーバーの手順には明記されておりませんが、この場合、前述の通り元のプライマリーが起動してくるときにも自動でロールの変更(セカンダリへの降格)が行われません。
そのため、一時的に両方のノードがプライマリーとして動作し更新可能な状態になります。

この場合は、管理者は、アプリケーションからのアクセスを停止するなどの運用にて元プライマリーでの更新が行われないようにし、データロスが発生しないようにする必要があります。
そして、元プライマリーが起動後、管理者が明示的に元プライマリーをセカンダリーに降格してから、同期を再開する必要があります。

なお、両方のノードがプライマリーとして更新可能な状態で動作している間、セカンダリーに降格したノードで更新された情報は、同期の一環としてロールバックされ、失われることになります。繰り返しとなりますが、データロスが発生しないようにロールの管理にご注意ください

下記がプライマリにて障害が発生後、実施いただく手順の例となります。

  1. 任意のセカンダリへ強制フェールオーバーを行う

    ALTER AVAILABILITY GROUP [ag1] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  2. 障害が発生したプライマリを起動する前にネットワークの切断などで、クライアントが接続し、更新が発生しないようにする。
  3. 障害が発生したプライマリをセカンダリへ降格する。

    ALTER AVAILABILITY GROUP [ag1] SET (ROLE = SECONDARY);

  4. ネットワークの切断などを解除します。
  5. ダッシュボードなどから同期状態を確認します。

 

(2/28 Windows 向けの手順を追加しました)

Blogの内容は、20182月現在の内容となっております。

Comments (0)

Skip to main content