SAP HANA 運用管理の基礎(3) システムレプリケーション
第３回目はシステムレプリケーションです。
SPS10までのシステムレプリケーション
システムレプリケーションは、HANA組み込みの障害・災害対策機能であり、その本質は複数のHANAインスタンス間のデータベース複製機能です。以下は、SPS10までのオペレーションモードである”delta_datashipping”の場合のデータ複製の動きを説明しています。
- まず、システムレプリケーションの設定を行うと、イニシャルデータ（要はプライマリーサイトのデータ）転送を行います。（赤の矢印）
- 運用中、データ変更が発生するとトランザクションのcommitのタイミングでログバッファーの内容がストレージのログボリュームに書き出されますが、この時、セカンダリー側のログボリュームにも書き出されます。（青の矢印）セカンダリーへのログ書き出しの同期モードには、以下があります。
- sync：ディスク書き出しまで同期
- syncmem：メモリー書き出しまで同期
- async：非同期
- データ変更の時はデータストアも変更されますが、10分間隔（デフォルト）で、変更差分を送るデルタデータ転送が行われます。（黄の矢印）デルタデータ転送は（ログではなく）データそのものの複製ですから、リプレイ不要なログが出てきますので、ログリプレイのスタート位置を修正します。
- フェールオーバーが起こると、セカンダリーでデータベースのリスタートシーケンスが実行され、この中でログリプレイが行われ、テーブルのメモリーロードが行われサービス可能状態になります。
スナップショットの視点で考える
以上を論理ページ、スナップショット、物理ページのレベルで見てみます。
- イニシャルデータ転送
- システムレプリケーションの設定を行うとイニシャルデータ転送が始まりますが、これは内部的にはスナップショット（変換テーブル＋物理ページ群）が作成され、セカンダリーサイトに転送されます。
- ログ転送
- 更新によるログボリュームへの出力はセカンダリーにも転送されます。sync/memsync/asyncのモードがあると言ったのはこの部分です。
- 更新によりメモリー上の論理ページも更新されます。
- デルタデータ転送
- デフォルト10分間隔で以下（デルタデータ転送）が実行されます。
- まず、スナップショットが作成され、更新された論理ページL1がディスクに書き出され新しい物理ページP104が割り当てられます。
- 差分情報とP104がセカンダリーに転送され、プライマリーと同じ状態になります
- 先に送ったログはもうリプレイの必要は無いのでログリプレイのスタートポイントをずらします。ここでは、更新２によるL2の変更ログをスタートポイントにします。（説明のため、L2はまだ永続化されていないことにします。）
- デフォルト10分間隔で以下（デルタデータ転送）が実行されます。
- フェールオーバー＆ログリプレイ
- この状態でフェールオーバーすると、
- セカンダリーは新プライマリーとなり、データベースのリスタートシーケンスを起動します。
- L２の物理ページP101は古いままですので、ログリプレイが走り更新2の内容が反映されます。
- テーブルのメモリーロードが実行され、終わり次第サービス開始となります。
- この状態でフェールオーバーすると、
SPS11のログリプレイモード
ログリプレイモードは、SPS11の新機能で、hdbnsutilコマンドで”--operationMode=logreplay”を設定すると、システムレプリケーションの動作が以下のように変わります。（従来のモードは、”--operationMode=delta_datashippinng”）
- デルタデータ転送を行わない
- ログリプレイが、セカンダリーで即実行される
メリットとして、以下のことが期待できます。
- デルタデータ転送が行われないのでネットワーク負荷が減る
- 通常の運用中にログリプレイが行われるので、フェールオーバー時間が短縮される。
ネットワーク負荷に関しては、SPS10以前では10分毎に発生していた転送量のピークが無くなり、負荷が平滑化されることが試験で確認されているようです。
ログリプレイモードの動作
再び、論理ページ、スナップショット、物理ページのレベルで見てみます。
（SPS11ログリプレイモードに関する記述及び図の一部には未検証の部分や詳細が不明な部分もあります。今後、検証・解析作業を行った時にはこのSCNブログでご紹介したいと思います。）
- イニシャルデータ転送
- hdbnsutil --operationMode=logreplayで設定が完了するとイニシャルデータ転送が自動的に開始されます。これは--operationMode=delta_datashippingと同様の動きです。
- ログリプレイ
- 更新トランザクションは、プライマリー、セカンダリーにログを書き込みに行きます。プライマリーの論理ページは更新トランザクションの中で更新されますが、セカンダリーの論理ページはログリプレイにより更新されます。
運用中はこのログリプレイの動作のみによってプライマリー/セカンダリー間の同期が維持されます。
- 更新トランザクションは、プライマリー、セカンダリーにログを書き込みに行きます。プライマリーの論理ページは更新トランザクションの中で更新されますが、セカンダリーの論理ページはログリプレイにより更新されます。
以上が、ログリプレイモードの動作です。デルタデータシッピングモードに比べて動作がシンプルになっているのがわかると思います。
今後は、ログリプレイモードがシステムレプリケーションの主流になると思われます。
まとめ
３回連続で永続化、バックアップ、システムレプリケーションについて、セーブポイント/スナップショット及びログを軸に説明してきました。
どの処理（永続化、バックアップ、システムレプリケーション）も
- データベース全体を扱うときにはセーブポイントまたはスナップショットで物理ページ全体を扱い、
- ログでトランザクション単位の更新差分を厳密に扱おうとし、
- 新旧セーブポイントまたはスナップショット間のデルタページを使うことにより、大量のログを処理する時間を短縮しようとする
という３つの共通点があります。
ここを押さえさえすれば運用上の要であるこの３つの機能を理解しやすいのではないかと思います。
個人的には、バックアップがデルタページを積極的に使おうとする方向で進化してきたことに対し、システムレプリケーションは逆にデルタページの転送を止める形で進化してきた、両者の違いが非常に面白いと思います。
（このブログ - SAP HANA 運用管理の基礎(永続化、バックアップ、システムレプリケーション) - は2016年4月14日に行った「SAP HANAナイトセッション 運用管理の基礎〜永続化、バックアップ、システムレプリケーションの基本動作を理解する〜」でお話した内容をブログ化したものです。）
以上。
- SAP Managed Tags:
