Exploring failover handling with PGD#
高可用性クラスターでは、フェールオーバー機能がクラスター全体の復元力にとって重要です。リードデータノードが何らかの理由で動作を停止した場合、アプリケーションはほとんどまたはまったく中断せずにデータベースでの作業を継続できる必要があります。 PGDの場合、それはアプリケーションを新しいリードデータノードに転送することを意味します。これは、自動的に引き継ぎます。ここでPGDプロキシが役立ちます。クラスターと連携し、トラフィックをリードデータノードに自動的に転送します。
この演習では、データベースにデータを定期的に送信するアプリケーションを作成します。次に、 PGD CLIを介して変更を要求することにより、リードデータノードをソフトに切り替えます。次に、データベースインスタンスを強制的にシャットダウンし、PGDがそれを処理する方法を確認します。
すぐに始められる構成#
この探索では、 quick start for Docker 、 quick start for AWS または quick start for Linux hosts を使用してPGDクラスターを作成したことを前提としています。
各クイックスタートの最後に、4つのノードと次のロールを含むクラスターが作成されます。
Host name |
Host role |
|---|---|
kaboom |
PGD data node and pgd-proxy co-host |
kaftan |
PGD data node and pgd-proxy co-host |
kaolin |
PGD data node and pgd-proxy co-host |
kapok |
Barman backup node |
この演習では、これらのホスト名を使用します。
運用環境では、フェールオーバー実験を実行する別の要塞サーバーを作成し、クラスターにログインするための適切なPostgresユーザーを作成することをお勧めします。
xpanes
は、簡単に切り替えることができる複数のターミナルセッションをすばやく作成できるユーティリティを使用します。デフォルトではインストールされないため、インストールする必要があります。この演習では、
tpaexecを実行してクイックスタートクラスターを構成したシステムからxpanesを起動します。
システムがUbuntuを実行している場合は、これを実行します。
sudo apt install software-properties-common
sudo add-apt-repository ppa:greymd/tmux-xpanes
sudo apt update
sudo apt install tmux-xpanes
これらは、 the xpanes repository からのインストール手順です。 Ubuntuを使用していない場合、リポジトリには他のシステムのインストール手順も含まれています。
4つのサーバーに接続する#
xpanesがインストールされている場合、次を実行して4つのサーバーすべてとのSSHセッションを作成できます。
cd democluster
xpanes -d -c "ssh -F ssh_config {}" "kaboom" "kaolin" "kaftan" "kapok"
これらのコマンドを実行すると、4つのペインが表示されます。 4つのペインはkaboom、kaolin、kaftan、およびkapokに接続され、それぞれにrootユーザーとしてログインしています。この特権は、運動中に後でサービスを簡単に停止および開始できるようにするために必要です。
Control-b に続いて q を押して、各ペインの数値を一時的に表示します。
4 SSH Sessions showing numbers#
ペイン間でフォーカスを切り替えるには、 Control-b とカーソルキーを使用してペイン間を移動できます。または、 Control-b に続いて q とフォーカスするペインの番号を使用できます。両方の方法を紹介します。
Control-b &darrを使用しますControl-b → または Control-b q 3 は、カポックホストである右下のペインにフォーカスを移動します。このサーバーは、バックアップを実行します。これを、デモアプリケーションの操作のベースとして使用します。 Barman資格情報を使用して、データベースサーバーとプロキシに接続できます。
sudo -iu barman
psql -h kaboom -p 6432 bdrdb
このコードは、kaboomホスト上のプロキシに接続します。これも、クラスターの一部としてPostgresインスタンスを実行します。
次のステップは、アプリケーションが書き込むテーブルを作成することです。
drop table if exists ping cascade;
CREATE TABLE ping (id SERIAL PRIMARY KEY, node TEXT, timestamp TEXT) ;
このコードは、最初にping テーブルをドロップします。次に、
ID主キーと、ノードとタイムスタンプの2つのテキストフィールドを使用してping
テーブルを再作成します。これで、テーブルの準備が整ったはずです。確認するには、
Control-b ←を使用します。 Control-b ↑ または Control-b q 0
を押して左上のペインに移動し、kaboomサーバーに移動します。このペインで、enterprisedbユーザーになるように、データベースに簡単に接続できます。
sudo -iu enterprisedb
次を実行して、ローカルデータベースに接続できるようになりました。
psql bdrdb
このコマンドは、kaboomのローカルデータベースインスタンスに直接接続します。
\dt を使用して、使用可能なテーブルを表示します。
bdrdb=# \dt
List of relations
Schema | Name | Type | Owner
- -------+------+-------+--------
public | ping | table | barman
(1 row)
\d ping を実行すると、
pingを作成するDDLがkaboomサーバー上にあることが示されます。
edb_notranlate_7
このテーブルがレプリケートされていることを確認したい場合は、クラスター内の別のノードに接続して確認できます。
psqlの\c コマンドを使用すると、別のサーバーに接続できます。
kaftanノードに接続するには、次を実行します。
\c - - kaftan
これに似たログインメッセージが表示されます。
psql.bin (15.2.0 (Debian 15.2.0-2.buster), server 15.2.0 (Debian 15.2.0-2.buster)) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
You are now connected to database "bdrdb" as user "enterprisedb" on host "kaftan" (address "10.33.25.233") at port "5444".
bdrdb=#
\dt および\d ping
を実行すると、kaftanノードで同じ結果が表示されます。
kaboomノードに再接続するには、次のコマンドを実行します。
\c - - kaboom
モニターのセットアップ#
次に、pingテーブルのアクティビティを監視します。最新の10エントリを表示するには、次のSQLを入力します。
select * from ping order by timestamp desc limit 10;
このコマンドを複数回実行するには、シェルで\watch
コマンドを使用します。これは、定期的な間隔で最後の照会を実行します。
1秒ごとに更新するには、次のように入力します。
\watch 1
これまでのところ、見るものは何もありません。すぐにアクティビティを追加します。
pingの作成#
Control-b ↓を使用して、 Barmanホストカポックに戻ります。 Control-b → または Control-b q 3 。
このセッションはまだpsqlセッションにログインしています。次にシェルスクリプトを実行するため、 psqlを終了する必要があります。 Control-d を押します。
シェルプロンプトは次のようになります。
barman@kapok:~$
admin@kapok またはroot@kapok と表示されている場合は、
sudo -iu barman を実行してBarmanユーザーに戻ります。
作成するアプリケーションは簡単です。書き込むノードとpingのタイムスタンプを取得します。次に、できるだけ早く新しいpingをpingテーブルに書き込みます。
シェルに、次のように入力します。
while true; do psql -h kaftan,kaolin,kaboom -p 6432 bdrdb -c "INSERT INTO ping(node, timestamp) select node_name, current_timestamp from bdr.local_node_summary;"; done
より読みやすい形式、つまり
while true;
do psql -h kaftan,kaolin,kaboom -p 6432 bdrdb -c \
"INSERT INTO ping(node, timestamp) select node_name, current_timestamp from bdr.local_node_summary;"
done
定数ループでは、
psqlコマンドを呼び出し、3つのプロキシのいずれかにホストとして接続するように指示し、プロキシポートを指定して、bdrdbデータベースを選択します。また、2つの値をpingテーブルに挿入するコマンドも渡します。値の1つはbdr.local_node_summary
からのもので、これには、実際に接続しているノードの名前が含まれています。もう1つの値は現在時刻です。
ループが実行されると、新しいエントリがテーブルに表示されます。モニタを設定する左上のペインに表示されます。
これで、フェイルオーバーのテストを開始できます。
書き込みリーダーの表示#
プロセスのこの部分では、左下隅にあるホストkaftanに切り替えます。 Control-b ← または Control-b q 2 を使用して、フォーカスを切り替えます。
pgd を実行するための適切な特権を取得するには、
PGDコマンドラインインターフェイスで、次のコマンドを実行します。
sudo -iu enterprisedb
クラスターの状態を確認するには、次のコマンドを実行します。
pgd show-groups
次のような出力が表示されます。
Group Group ID Type Parent Group Location Raft Routing Write Leader
- ---- -------- ---- ------------ -------- ---- ------- ------------
democluster 1935823863 global true false
dc1_subgroup 1302278103 data democluster dc1 true true kaboom
グローバルグループdemocluster
には、すべてのサブグループが含まれます。 dc1_subgroup
は、作業しているデータクラスターです。そのグループ名の値は、このクラスターを構成するときにクイックスタートで指定された場所から取得されます。各ロケーションは独自のサブグループを取得するため、他のロケーションまたはクラスターとは無関係に管理できます。
テーブルの右側にスキップすると、グループの現在の書き込みリーダー-すべてのプロキシが更新を送信するサーバー-がkaboomであることがわかります。
switchover
コマンドをクラスターグループに送信して、リーダーを変更します。次のコマンドを実行します。
edb_notranlate_33 ノード名は、dc1_subgroupグループ内の別のデータノードのホスト名です。
2つの応答のいずれかが表示されます。 show-groups
コマンドを実行したときに、書き込みリーダーとしてkaolinが表示された場合、次の情報が表示されます。
Error: "kaolin" is already a write leader
これは、カオリンが既に書き込みリーダーに選出されているため、切り替えは効果がないことを意味します。この演習では、ノード名としてkaboomまたはkaftanに置き換えて、別のホストへのスイッチオーバーを再試行します。
現在の書き込みリーダーではないホストを選択すると、他の応答が表示されます。
switchover is complete
左上のペインを見ると、スクリプトからの挿入が切り替わり、切り替えたばかりのノードに書き込まれているのがわかります。
!!!情報 ID番号を観察します 生成されるID番号も、完全に異なる値の範囲であることに注意してください。これは、システムがIDを生成するシーケンスを透過的にグローバルシーケンスにしたためです。グローバルシーケンスとそれらが bdr.sequences でどのように動作するかについての詳細を読んでください。
ノードの損失#
リーダーを切り替えられることは、計画的なメンテナンスに役立ちます。クラスターに構成を変更するように指示します。予期せぬ変化が起こったらどうしますか？これからそのシナリオを作成します。
左下のペインで、リーダーをkaolinに設定します。
pgd switchover --group-name dc1_subgroup --node-name kaolin
次に、 Control-b &uar;を使用してフォーカスを右上ペインに変更します。 Control-b → または Control-b q 1 、これはカオリンホスト上のセッションです。
次のコマンドを実行して、Postgresサーバーの電源をオフにします。
sudo systemctl stop postgres.service
左上のペインには、クラスターサブグループが新しいリーダーを選択すると、監視対象テーブルがカオリンから別のノードに切り替わるのが表示されます。更新がキャンセルされると、右下ペインのスクリプトにいくつかのエラーが表示される場合があります。ただし、新しいリーダーが選出されると、そのリーダーへのトラフィックのルーティングを開始します。
ノードの状態の表示#
Control-b ↓を使用して左下のペインに切り替えます。 Control-b ← または Control-b q 2 を押して、次を実行します。
pgd show-nodes
次のようなものが表示されます。
Node Node ID Group Type Current State Target State Status Seq ID
- --- ------- ----- ---- ------------- ------------ ------ ------
kaboom 2710197610 dc1_subgroup data ACTIVE ACTIVE Up 3
kaftan 3490219809 dc1_subgroup data ACTIVE ACTIVE Up 2
kaolin 2111777360 dc1_subgroup data ACTIVE ACTIVE Unreachable 1
カオリンノードはダウンしており、更新は別の書き込みリーダーに送られます。
モニタリングラグ#
カオリンがダウンしている間、PGDの中心部の論理レプリケーションは、カオリンがクラスターとどの程度同期していないかを追跡しています。それを自分の目で確認するには、次を実行します。
psql bdrdb -c "select * from bdr.node_replication_rates;"
このコマンドは、サーバー間の現在のレプリケーションレートを表示します。
peer_node_id | target_name | sent_lsn | replay_lsn | replay_lag | replay_lag_bytes | replay_lag_size | apply_rate | catchup_interval
- -------------+-------------+-----------+------------+-----------------+------------------+-----------------+------------+------------------
2710197610 | kaboom | 0/769F650 | 0/769F650 | 00:00:00 | 0 | 0 bytes | 1861 | 00:00:00
| kaolin | 0/7656648 | 0/7656648 | 00:03:07.252266 | 299016 | 292 kB | |
(2 rows)
この出力を見ると、kaolinには3分の再生ラグと、今戻った場合にキャッチアップする約292KBのデータがあることがわかります。カオリンのダウンが長くなると、再生遅延が大きくなります。モニタリングコマンドを再実行すると、数値が増加したことがわかります。
peer_node_id | target_name | sent_lsn | replay_lsn | replay_lag | replay_lag_bytes | replay_lag_size | apply_rate | catchup_interval
- -------------+-------------+-----------+------------+-----------------+------------------+-----------------+------------+------------------
2710197610 | kaboom | 0/76B1D28 | 0/76B1D28 | 00:00:00 | 0 | 0 bytes | 1743 | 00:00:00
| kaolin | 0/7656648 | 0/7656648 | 00:03:53.045704 | 374496 | 366 kB | |
(2 rows)
さらに46秒が経過し、遅延は74KB増加しました。次に、ノードを元に戻し、システムがどのように復旧するかを確認します。
ノードの再起動#
kaolinにPostgresサービスを戻すことができます。 Control-b &uar;を使用して、右上ペインに戻ります。 Control-b → または Control-b q 1 を押して、次を実行します。
sudo systemctl start postgres.service
変化は表示されません。データベースサービスはバックアップして実行されていますが、クラスターは選挙を行っていないため、リーダーはそのままです。 Control-b ↓を使用して左下のペインに切り替えます。 Control-b ← または Control-b q 2 を押して、次を実行します。
pgd show-nodes
これで、次のものが表示されます。
Node Node ID Group Type Current State Target State Status Seq ID
- --- ------- ----- ---- ------------- ------------ ------ ------
kaboom 2710197610 dc1_subgroup data ACTIVE ACTIVE Up 3
kaftan 3490219809 dc1_subgroup data ACTIVE ACTIVE Up 2
kaolin 2111777360 dc1_subgroup data ACTIVE ACTIVE Up 1
カオリンがクラスターに戻ると、クラスターとの同期が開始されます。これは、リプレイデータをキャッチすることにより行われます。実行します
psql bdrdb -c "select * from bdr.node_replication_rates;"
出力は次のとおりです。
peer_node_id | target_name | sent_lsn | replay_lsn | replay_lag | replay_lag_bytes | replay_lag_size | apply_rate | catchup_interval
- -------------+-------------+-----------+------------+------------+------------------+-----------------+------------+------------------
2710197610 | kaboom | 0/8092938 | 0/8092938 | 00:00:00 | 0 | 0 bytes | 2321 | 00:00:00
2111777360 | kaolin | 0/8092938 | 0/8092938 | 00:00:00 | 0 | 0 bytes | 337426 | 00:00:00
(2 rows)
ご覧のとおり、カオリンは完全に自動的に追いついたため、再生ラグはありません。
カオリンが完全にサービスに戻ったので、すべてをそのままにしておくことができます。書き込みリーダーであるサーバーを変更する必要はありません。フェールオーバーメカニズムは、必要に応じて別のサーバーを書き込みリーダーに起動する準備が常にできています。
必要に応じて、次のコマンドを実行してカオリンリーダーを再度作成できます。
pgd switchover --group-name dc1_subgroup --node-name kaolin
このコマンドは、書き込みリードにカオリンを結果ます。プロキシが書き込みリーダーを追跡すると、アプリケーションの更新が続きます。
プロキシフェイルオーバー#
プロキシもフェイルオーバーできます。これを体験するには、フォーカスがまだ左下のペインにあることを確認し、実行します。
pgd show-proxies
次のものが表示されます。
Proxy Group Listen Addresses Listen Port
- ---- ----- ---------------- -----------
kaboom dc1_subgroup [0.0.0.0] 6432
kaftan dc1_subgroup [0.0.0.0] 6432
kaolin dc1_subgroup [0.0.0.0] 6432
exit と入力してenterprisedbユーザーを終了し、
admin/rootシェルに戻ります。次のコマンドを実行して、このノードのプロキシサービスを停止できるようになりました。
systemctl stop pgd-proxy.service
スクリプトが別のプロキシに切り替わると、右下のウィンドウに簡単なエラーが表示されます。ただし、書き込みリーダーは変更されないため、プロキシのスイッチは、監視クエリが実行されている左上のペインに表示されません。
次のコマンドを実行して、kaftanのプロキシサービスを元に戻します。
systemctl start pgd-proxy.service
!!!ヒント Tmuxの終了
Tmuxおよび関連するすべてのセッションをすばやく終了できます。最初に実行中のプロセスを終了します。それ以外の場合、セッションが強制終了された後も実行を継続します。
Control-B を押して、 :kill-session
と入力します。このアプローチは、 Control-D またはexit
を使用して各ペインのセッションを1つずつ終了するよりも簡単です。
この例では、3つのデータノードと1つのバックアップノードのクイックスタート構成を使用します。 2つのデータノードと1つの監視ノードを持つようにクラスターを構成できます。監視ノードは、ノードに障害が発生した場合の復元力が低くなります。または、5つのデータノードを構成することもできます。これにより、ノードに障害が発生した場合の復元力が大幅に向上します。この構成では、アプリケーションのフェイルオーバーがどのように動作するかを調べることができます。複数の場所を持つクラスターの場合、同じ基本的なルールが適用されます。サーバーをダウンすると、プロキシがポイントする新しい書き込みリーダーが選択されます。
さらに読む#
PGD CLIを使用する の管理機能の詳細をご覧ください。
monitoring replication using SQL の詳細についてはこちらをご覧ください。