TECH BLOG
技術ブログ

ARTICLE

  • 2021-03-03 PostgreSQL

    PostgreSQLのストリーミングレプリケーションとPacemakerによるクラスター構築方法(2)

本ブログでは『PostgreSQLのストリーミングレプリケーションとPacemakerによるクラスター構築方法(1)』で構築したストリーミングレプリケーション環境に
Pacemakerを導入し、クラスター構築を行います。
前回のブログでの環境構築を前提に手順が進むため、まだご覧になっていない方は上記リンクより閲覧ください。

5. Pacemakerの導入と設定

※前提条件として、公開鍵認証で両サーバともパスワード無しでSSH接続出来る状態とします。
※サーバ『testcentos01』をPrimary、サーバ『testcentos02』をStandbyとします。

Pacemakerの導入(2台共通)
# yum -y install https://osdn.net/projects/linux-ha/downloads/70298/pacemaker-repo-1.1.19-1.1.el7.x86_64.rpm
# yum install -y pacemaker-all
corosyncの設定(2台共通)
# vi /etc/corosync/corosync.conf
 

以下のテキストをcorosync.conf内に記述します。(クリックで展開)

totem {
version: 2
cluster_name: pgcluster
rrp_mode: passive
secauth: off
transport: udpu
token: 30000
token_retransmits_before_loss_const: 10
join: 5000
}

logging {
to_syslog: yes
to_logfile: yes
logfile: /var/log/cluster/corosync.log
}

nodelist {
node {
name: testcentos01
ring0_addr: 192.168.33.11
nodeid: 1
}
node {
name: testcentos02
ring0_addr: 192.168.33.12
nodeid: 2
}
}

quorum {
provider: corosync_votequorum
two_node: 1
}

corosync用の鍵の作成(Primary側)
(testcentos01)# corosync-keygen -l
(testcentos01)# scp -p /etc/corosync/authkey root@testcentos02:/etc/corosync/authkey
Pacemakerの起動とリソースの適用

Pacemakerの起動時にPostgreSQLも起動するため、各サーバのPostgreSQLは停止させておきます。
ただし、Pacemakerは先に起動が完了したサーバをPrimaryと見なすためPrimaryとするサーバで先にPacemakerを起動します。
その後、Primaryが完全に起動したことを確認してからStandbyのPacemakerを起動します。

※上記手順を踏まないとPrimaryとStandbyが意図した通りにならない可能性があります。
※PacemakerにStandbyと判断されたサーバにはPacemaker起動時に recovery.conf が作成されるため、あらかじめ削除しておきます。

(testcentos01)# su - postgres

(testcentos01)$ pg_ctl stop #PostgreSQLが起動している場合に実行します。
(testcentos01)$ exit

(testcentos01)# systemctl start pacemaker
(testcentos02)# su - postgres

(testcentos02)$ pg_ctl stop #PostgreSQLが起動している際に実行します
(testcentos02)$ rm -f $PGDATA/recovery.conf
(testcentos02)$ exit

(testcentos02)# systemctl start pacemaker #Primaryの起動が完了していることを確認してから実行します
(testcentos02)# crm_mon

crm_mon コマンドを実行してPrimaryとStandbyが両方とも Online となっていることを確認します。

問題ないことを確認出来たらPrimary側でリソースの適用を行います。

(testcentos01)# vi /var/lib/pacemaker/cib/cib.txt #ファイル内のリソース内容は後述の『リソース設定例』を参照
(testcentos01)# crm configure load update /var/lib/pacemaker/cib/cib.txt
 

cib.txt リソース設定例(クリックで展開)

### Cluster Option ###

property \
no-quorum-policy="ignore" \
stonith-enabled="false" \
startup-fencing="false" \
pe-error-series-max="100" \
pe-input-series-max="100" \
pe-warn-series-max="100"

### Resource Defaults ###
rsc_defaults resource-stickiness="INFINITY" \
migration-threshold="2"

### Primitive Configuration ###
primitive master-vip IPaddr2 \
params cidr_netmask=24 iflabel=master ip=192.168.160.250 nic=eth2 \
op monitor interval=5s \
op start interval=0s timeout=20s \
op stop interval=0s timeout=20s

primitive pgsql pgsql \
params check_wal_receiver=true config="/pgsql/data/postgresql.conf" crm_attr_timeout=5 master_ip=192.168.160.250 node_list="testcentos01 testcentos02" pgctl="/usr/pgsql-11/bin/pg_ctl" pgdata="/pgsql/data" primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5 keepalives_count=5" psql="/usr/pgsql-11/bin/psql" rep_mode=sync repuser=rep restart_on_promote=true restore_command="/usr/bin/scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /home/postgres/.ssh/id_rsa postgres@192.168.160.250:/pgsql/arclog/%f %p" stop_escalate=5 xlog_check_count=3 \
op demote interval=0s timeout=120s \
op methods interval=0s timeout=5s \
op monitor interval=11s \
op monitor interval=10s role=Master \
op notify interval=0s timeout=90s \
op promote interval=0s timeout=120s \
op start interval=0s timeout=120s \
op stop interval=0s timeout=120s

primitive ping ocf:pacemaker:ping \
params dampen=5s host_list=10.0.2.3 multiplier=100 \
op monitor interval=10 timeout=60 \
op start interval=0s timeout=60 \
op stop interval=0s timeout=20

primitive connect-master-vip IPaddr2 \
params cidr_netmask=24 iflabel=replica ip=192.168.33.250 nic=eth1 \
op monitor interval=5s \
op start interval=0s timeout=20s \
op stop interval=0s timeout=20s

### Clone Configuration ###
clone ping-clone ping

### MS Configuration ###
ms pgsql-master pgsql \
meta clone-max=3 clone-node-max=1 master-max=1 master-node-max=1 notify=true target-role=Started

### Resource Location ###
location location-pgsql-master pgsql-master \
rule -inf: pingd lt 1 or not_defined pingd

location location-connect-master-vip connect-master-vip \
rule 200: pgsql-status eq HS:sync

location location-connect-master-vip-1 connect-master-vip \
rule 100: pgsql-status eq PRI

location location-connect-master-vip-2 connect-master-vip \
rule -inf: not_defined pgsql-status

location location-connect-master-vip-3 connect-master-vip \
rule -inf: pgsql-status ne HS:sync and pgsql-status ne PRI

### Resource Colocation ###
colocation colocation-master-vip-pgsql-master-INFINITY inf: master-vip:Started pgsql-master:Master

### Resource Order ###
order order-pgsql-master-master-vip-0 0: pgsql-master:demote master-vip:stop symmetrical=false

order order-pgsql-master-master-vip-INFINITY inf: pgsql-master:promote master-vip:start symmetrical=false

6.確認とテスト

(testcentos01)# crm configure show #cib.txt に記述した内容と同じかどうかを確認します(実行結果は後述)
(testcentos01)# crm_mon #リソースの適用がうまくいっていることを確認します(下記画像を参照)

※環境によっては成功画面が表示されるまでに〜5分ほどかかる場合があります。

crm_mon 実行時の成功画面

crm configure show の実行結果

フェイルオーバーテスト

testcentos01のPacemakerを停止させ、testcentos02がPrimaryに昇格するか確認します。

(testcentos01)# systemctl stop pacemaker
(testcentos02)# crm_mon

※Primary(VIP)側のコンソールで crm_mon を実行していた場合はPacemakerが停止したタイミングで状態の確認が出来なくなります。
そのためフェイルオーバーテスト時にはStandby側から crm_mon を実行することを推奨します。

旧Primary(testcentos01)で crm_mon 実行後、上記成功画面のMasters項目に旧Standby(testcentos02)のホスト名が表記されていればフェイルオーバーが成功しています。

クラスターの再構築方法

フェイルオーバーで切り替わった旧Primary(testcentos01)をStandbyとしてクラスターの再構築を行います。
ストリーミングレプリケーションのやり直しが必要となるため、testcentos01で pg_basebackup コマンドを使用して再構築を行います。

まずストリーミングレプリケーション環境を再構築するためにtestcentos01で pg_basebackup コマンドを実行します。

(testcentos01)# su - postgres
(testcentos01)$ cd $PGDATA && rm -rf $(ls) #Primary時の$PGDATAが残っているため削除します
(testcentos01)$ pg_basebackup -h test_rep02 -U rep -D $PGDATA --progress #「recovery.conf」が作成されないよう「-R」オプションは使いません
(testcentos01)$ exit
(testcentos01)# rm -f /var/lib/pgsql/tmp/PGSQL.lock #理由は後述
(testcentos01)# systemctl start pacemaker #Pacemakerを起動することでPostgreSQLも起動します

※pg_basebackupコマンドで指定している test_rep02 はレプリケーション用のIPアドレスです。(各IPアドレスの詳細については前半記事の構築イメージを参照してください。)

クラスターの再構築後、testcentos02のPacemakerを停止させ同様の手順を踏むことによりtestcentos01を再度Primaryとして稼働させることが出来ます。(フェイルバック)

クラスターの再構築が正常に行われた場合、 crm_mon コマンドの表示が以下のようになります。

※PostgreSQLが起動した時に、Primary側に、 PGSQL.lock という名前のファイルが作成されます。
このファイルはPacemakerの停止によってPrimaryが停止した場合も残り続けるため、新しくPostgreSQLを起動し、
クラスター構築を行う際に以前のPostgreSQLで生成された情報が残っているということでエラーが発生してしまいます。
そのため、PGSQL.lock ファイルによるエラーを起こさないようにするため、 pg_basebackup コマンド実行後に PGSQL.lock ファイルを削除する必要があります。
このエラーは crm_mon コマンドによって確認できます。以下エラー内容です。このエラーが出力されたら PGSQL.lock ファイルの削除を行なってください。

* pgsql_start_0 on testcentos01 'unknown error' (1): call=31, status=complete, exitreason='My data may be inconsistent. You have to remove /var/lib/pgsql/tmp/PGSQL.lock file to force start.'

終わりに

株式会社インサイトはPostgrteSQLのパフォーマンス改善を事業の柱の1つとしています。
そのためパフォーマンスチューニングやシステムチューニングは勿論のこと、
今回ご紹介したようにクラスター構成による高可用性や冗長化などの本番運用を考えたアーキテクチャに関する検証や知識の蓄積、技術の向上にも日々力を入れております。
直近で公開している様々なクラスター構成関連の記事だけでなく、今後はPostgreSQLのパフォーマンス改善の参考となるような
内部動作やモジュールについても検証した結果や情報を発信していこうと思いますので、どうぞよろしくお願い致します。

お問い合わせ

https://www.insight-ltd.co.jp/contact/

関連記事

PostgreSQLにおけるレプリケーション機能とPgpool-IIについて
PostgreSQLミドルウェア Pgpool-IIの便利機能3選
Pgpool-II+PostgreSQL+Zabbbixの組み合わせ構築
Pacemaker+DRBD+PostgreSQLの構築の流れ

CATEGORY

ARCHIVE

データベースの
パフォーマンス・チューニングのご相談は
株式会社インサイトまで
お気軽にお問い合わせください。

CONTACT