皆さん、こんにちは。 BI Data Platform サポートチームです。
今回は、読み取りスケール可用性グループをお使いいただく際の注意点についてご紹介します。
■構成手順について
読み取りスケール可用性グループについては下記の公開情報に解説があります。
現時点では具体的な構築または管理手順につきましては Linux を対象にした下記の公開情報のみとなっておりますが、本手順につきましては、Windows にも適用いただける手順です。
SQL Server on Linux の読み取りのスケールの可用性グループを構成します
※必要に応じて、Linux のコマンドを Windows のコマンドへ置き換える必要があります。
■フェールオーバーについて
読み取りスケール可用性グループのフェールオーバーについては下記の公開情報に記載されています。
読み取りスケール可用性グループのプライマリ レプリカをフェールオーバーする
読み取りスケール可用性グループは、読み取り専用データベースを作成することで、書き込みと読み込みのデータベースを分離し、負荷を分散させることが目的であり、高可用性を目的とした機能ではありません。
そのため、高可用性を目的とした可用性グループと異なり自動的なロールの管理は無く、プライマリー/セカンダリーの各ロールの切り替え（手動フェールオーバー）は、管理者の判断により手動で行う必要があります。
ロールを手動で明示的に切り変える必要があることは、何らかの障害回復を目的として非計画的に手動フェールオーバーを実施するときも、計画的に手動フェールオーバーを実施するときも同様になります。
上記の公開情報の 読み取りスケール可用性グループのプライマリ レプリカをフェールオーバーする の「データを失わずに手動フェールオーバー」の項に記載がありますように、プライマリーをセカンダリーに降格させた後に、元のセカンダリーを新しいプライマリーに昇格させるという手順が必要です。
また、プライマリー側のノードがサーバー故障によりダウンした場合、必要に応じて上記の公開情報の「データの損失の強制手動フェールオーバー」を行うことになります。
強制フェールオーバーの手順には明記されておりませんが、この場合、前述の通り元のプライマリーが起動してくるときにも自動でロールの変更（セカンダリへの降格）が行われません。
そのため、一時的に両方のノードがプライマリーとして動作し更新可能な状態になります。
この場合は、管理者は、アプリケーションからのアクセスを停止するなどの運用にて元プライマリーでの更新が行われないようにし、データロスが発生しないようにする必要があります。
そして、元プライマリーが起動後、管理者が明示的に元プライマリーをセカンダリーに降格してから、同期を再開する必要があります。
なお、両方のノードがプライマリーとして更新可能な状態で動作している間、セカンダリーに降格したノードで更新された情報は、同期の一環としてロールバックされ、失われることになります。繰り返しとなりますが、データロスが発生しないようにロールの管理にご注意ください。
※ 本Blogの内容は、2018年1月現在の内容となっております。