システム開発
ミドルウェア

PostgreSQLのバックアップとリストア～pg_basebackupを駆使して主系副系復帰を目指す～

PostgreSQLのバックアップとリストア～pg_basebackupを駆使して主系副系復帰を目指す～

今すぐ無料ダウンロード！(スポンサーリンク)


中山テック 代表の中山です。

さて、前回で最終回だった確認事項ですが、PostgreSQLのバックアップ・リストアをまだやっておりませんでした（汗

というわけで早速始めたいと思います。

※PostgreSQL × pgpoolの組み合わせでを前提とします







  • VMware × CentOS関連索引

バックアップ前準備

正直どこでも良いのですが、postgresユーザが実施するのでホームディレクトリに用意しました。

/home/postgres/bkup
/home/postgres/bkup_tmp

2つ用意したのは理由があります。

「pg_basebackup」の実行結果を格納する場所にファイルが入っているとエラーが発生するためです。

なので「bkup_tmp」に実行結果を入れ、リネームして「bkup」に、その後tmp内のファイルを全消しします。

作成したらpostgresユーザでログインします。

バックアップ

pg_basebackup実行

pg_basebackup -D /home/postgres/bkup_tmp -Ft -z --progress

「pg_basebackup」が用意されているので実行します。

オプションは

-D 格納ディレクトリ

-Ft tar形式のフォーマットで格納します。

-z gzip形式での圧縮も行います

--progress 進捗状況を表示します

詳しくはこちらのページもご覧ください。

バックアップディレクトリ確認

-rw------- 1 postgres postgres  182175  2月 29 20:06 backup_manifest
-rw------- 1 postgres postgres 4248372  2月 29 20:06 base.tar.gz
-rw------- 1 postgres postgres   17072  2月 29 20:06 pg_wal.tar.gz

3つファイルが出力されました。

ファイル何のファイルか
base.tar.gzdata配下をgzip圧縮でtar化したものです。
解凍するとpostgresql.conf等大量のファイルが出てくるので
ご利用はリストア時に。
pg_wal.tar.gz最新のWALファイルが格納されています。
backup_manifestバックアップしたファイル一覧です。
特に使用はしませんが、一覧で見たい時便利です。

バックアップ退避

仮に1日1回バックアップを取るとして、ファイルを積み上げていきたいですよね。

先述しましたが、pg_basebackupは指定ディレクトリ内にファイルがあるとエラーが発生するのでリネームの上別の場所に格納します。

※積み上げない場合は無理してリネームする必要はありません。

-bash-4.2$ mv backup_manifest ../bkup/20240229_backup_manifest
-bash-4.2$ mv base.tar.gz ../bkup/20240229_base.tar.gz
-bash-4.2$ mv pg_wal.tar.gz ../bkup/20240229_pg_wal.tar.gz

ちなみにアーカイブファイルの最新は以下になります。

-rw------- 1 postgres postgres 16777216  2月 29 20:06 000000010000000000000021
  • システム開発関連記事

レコード追加

バックアップ時との差分を取るためにテーブル＆レコード追加しておきます。

※画面からめっちゃ登録してました！

nakayama=# select * from login_table ;
         mail_address         |   password
------------------------------+--------------
 a_nakayama@nakayama-tech.com | nakayamatest
 nakayamatech2017@gmail.com   | riben731
 nakayama                     | nakayama
 aho1496                      | riben731
 aaaaaa                       | bbbbbb
 cccccc                       | ddddd
 dddddd                       | eeeeee
 eeeeee                       | ffffff
 ffffff                       | gggggg
 gggggg                       | hhhhhh
 hhhhhh                       | hhhhhh
 hhhhhh                       | hhhhhh
 zako                         | zako
 aho                          | aho
 kora                         | kora
 kore                         | kore
 koro                         | koro
 za-ko                        | za-ko
 nanto                        | nanto
 iiiiii                       | iiiiii
 manuke                       | manuke
 baho                         | baho
(22 行)

リストア

pgpoolを止める(主系・副系)

sudo systemctl stop pgpool-II.service

※実行コマンドは環境によって変えましょう

トランザクションが入ってこないように一旦止めると良いでしょう。

データ不整合（差分）が発生するのを防ぎます。

PostgreSQLを止める(主系・副系)

こちらもトランザクションが入ってこないように一旦止めましょう（pgpoolもそうですが、再起動も必要ですし）。

もちろんroot権限で。

sudo systemctl stop postgresql-15.service

※実行コマンドは環境によって変えましょう

データディレクトリの退避(主系・副系)

mv /var/lib/pgsql/15/data /var/lib/pgsql/15/data_20240229

念のためですかね。

元に戻ったら消しちゃいましょう（案外容量多い）。

そして新たにdataを作ってあげます。

mkdir /var/lib/pgsql/15/data
chmod 700 /var/lib/pgsql/15/data # これやらないとエラー出る

バックアップファイルを格納(主系)

先ほど取得したtar.gzのファイルを解凍・格納してあげます。

tar zxvf 20240229_base.tar.gz -C /var/lib/pgsql/15/data

touch /var/lib/pgsql/15/data/recovery.signal

ついでにrecovery.signalってのも入れてますが、これがあることでPITR(Point In Time Recovery)が出来ます。

実行後は勝手に消えるので作ってそのままでOKです。

postgresql.conf(主系)

restore_command = 'cp /var/lib/pgsql/15/archivedir/%f %p'

ファイル内に記述しましょう。

これがないと「どのポイントからリストアすればよい？」となり、エラーが起きるからです。

postgresql起動＆実行後確認(主系)

systemctl start postgresql-15.service

～～～～～～～～～～～～～～　以下ログ　～～～～～～～～～～～～～～～
2024-03-05 07:39:07.828 JST [4699] LOG:  PostgreSQL 15.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit を起動しています
2024-03-05 07:39:07.829 JST [4699] LOG:  IPv4アドレス"0.0.0.0"、ポート5432で待ち受けています
2024-03-05 07:39:07.829 JST [4699] LOG:  IPv6アドレス"::"、ポート5432で待ち受けています
2024-03-05 07:39:07.833 JST [4699] LOG:  Unixソケット"/run/postgresql/.s.PGSQL.5432"で待ち受けています
2024-03-05 07:39:07.837 JST [4699] LOG:  Unixソケット"/tmp/.s.PGSQL.5432"で待ち受けています
2024-03-05 07:39:07.849 JST [4704] LOG:  データベースシステムは中断されました: 2024-03-04 02:04:43 JST まで動作していたことは確認できます
2024-03-05 07:39:07.882 JST [4704] LOG:  ログファイル"00000005.history"をアーカイブからリストアしました
2024-03-05 07:39:07.890 JST [4704] LOG:  ログファイル"00000006.history"をアーカイブからリストアしました
cp: `/var/lib/pgsql/15/archivedir/00000007.history' を stat できません: そのようなファイルやディレクトリはありません
2024-03-05 07:39:07.898 JST [4704] LOG:  アーカイブリカバリを開始しています
2024-03-05 07:39:07.898 JST [4704] LOG:  タイムラインID 4上でREDO LSN 0/39000028、チェックポイントLSN 0/39000098からのバックアップ・リカバリを開始しました
2024-03-05 07:39:07.906 JST [4704] LOG:  ログファイル"00000006.history"をアーカイブからリストアしました
2024-03-05 07:39:08.056 JST [4704] LOG:  ログファイル"000000040000000000000039"をアーカイブからリストアしました
2024-03-05 07:39:08.117 JST [4704] LOG:  ログファイル"00000004.history"をアーカイブからリストアしました
2024-03-05 07:39:08.125 JST [4704] LOG:  ログファイル"00000005.history"をアーカイブからリストアしました
2024-03-05 07:39:08.129 JST [4704] LOG:  REDOを0/39000028から開始します
cp: `/var/lib/pgsql/15/archivedir/00000004000000000000003A' を stat できません: そのようなファイルやディレクトリはありません
2024-03-05 07:39:08.138 JST [4704] LOG:  REDO LSN0/39000028、終了LSN 0/39000138のバックアップ・リカバリが完了しました
2024-03-05 07:39:08.138 JST [4704] LOG:  0/39000138 でリカバリの一貫性が確保されました
2024-03-05 07:39:08.138 JST [4699] LOG:  データベースシステムはリードオンリー接続の受け付け準備ができました
cp: `/var/lib/pgsql/15/archivedir/00000004000000000000003A' を stat できません: そのようなファイルやディレクトリはありません
2024-03-05 07:39:08.145 JST [4704] LOG:  REDOが0/39000138で終了しました、システム使用状況: CPU: ユーザー: 0.00秒、システム: 0.00秒、経過時間: 0.01秒
2024-03-05 07:39:08.281 JST [4704] LOG:  ログファイル"000000040000000000000039"をアーカイブからリストアしました
cp: `/var/lib/pgsql/15/archivedir/00000007.history' を stat できません: そのようなファイルやディレクトリはありません
2024-03-05 07:39:08.333 JST [4704] LOG:  新しいタイムラインIDを選択: 7
2024-03-05 07:39:08.367 JST [4704] LOG:  ログファイル"00000006.history"をアーカイブからリストアしました
2024-03-05 07:39:08.368 JST [4704] LOG:  アーカイブリカバリが完了しました
2024-03-05 07:39:08.370 JST [4702] LOG:  チェックポイント開始: end-of-recovery immediate wait
2024-03-05 07:39:08.376 JST [4702] LOG:  チェックポイント完了: 3個のバッファを出力 (0.0%); 0個のWALファイルを追加、0個を削除、1個を再利用; 書き出し=0.003秒, 同期=0.001秒, 全体=0.008秒; 同期
したファイル=2, 最長=0.001秒, 平均=0.001秒; 距離=16384 kB, 予測=16384 kB
2024-03-05 07:39:08.382 JST [4699] LOG:  データベースシステムの接続受け付け準備が整いました
～～～～～～～～～～～～～～　以上ログ　～～～～～～～～～～～～～～～

[root@study_02 pg_wal]# ls -ltr /var/lib/pgsql/15/data/pg_wal
合計 32784
-rw------- 1 postgres postgres      214  3月  5 07:39 00000006.history
-rw------- 1 postgres postgres      128  3月  5 07:39 00000004.history
-rw------- 1 postgres postgres      171  3月  5 07:39 00000005.history
-rw------- 1 postgres postgres 16777216  3月  5 07:39 00000007000000000000003B
-rw------- 1 postgres postgres      257  3月  5 07:39 00000007.history
drwx------ 2 postgres postgres      122  3月  5 07:39 archive_status
-rw------- 1 postgres postgres 16777216  3月  5 07:39 00000007000000000000003A


nakayama=# select * from login_table ;
         mail_address         |   password
------------------------------+--------------
 a_nakayama@nakayama-tech.com | nakayamatest
 nakayamatech2017@gmail.com   | riben731
 nakayama                     | nakayama
 aho1496                      | riben731
 aaaaaa                       | bbbbbb
 cccccc                       | ddddd
 dddddd                       | eeeeee
 eeeeee                       | ffffff
 ffffff                       | gggggg
 gggggg                       | hhhhhh
 hhhhhh                       | hhhhhh
 hhhhhh                       | hhhhhh
 zako                         | zako
 aho                          | aho
 kora                         | kora
 kore                         | kore
 koro                         | koro
 za-ko                        | za-ko
 nanto                        | nanto
 iiiiii                       | iiiiii
 manuke                       | manuke
 baho                         | baho
 papuwa                       | papuwa
 uhaha                        | uhaha
 masaka                       | masaka
 bbbbbbb                      | bbbbbbb
 ahoahoaho                    | ahoahoaho
 ahoahoahoaho                 | ahoahoahoaho
(28 行)

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

nakayama=# select * from login_table ;
         mail_address         |   password
------------------------------+--------------
 a_nakayama@nakayama-tech.com | nakayamatest
 nakayamatech2017@gmail.com   | riben731
 nakayama                     | nakayama
 aho1496                      | riben731
 aaaaaa                       | bbbbbb
 cccccc                       | ddddd
 dddddd                       | eeeeee
 eeeeee                       | ffffff
 ffffff                       | gggggg
 gggggg                       | hhhhhh
 hhhhhh                       | hhhhhh
 hhhhhh                       | hhhhhh
 zako                         | zako
 aho                          | aho
 kora                         | kora
 kore                         | kore
 koro                         | koro
 za-ko                        | za-ko
 nanto                        | nanto
 iiiiii                       | iiiiii
 manuke                       | manuke
 baho                         | baho
(22 行)

はい、主系が元に戻りました！（6レコード減）

pg_basebackupで主系から物理データコピー（副系）

副系も同じ方法でリストアすれば良いのではと思うかもしれませんが、レプリケーション遅延が発生しまくりました（汗

なので物理データをpg_basebackupで主系データをコピーします。が、data配下にレコードがあるとpg_basebackupが失敗するので一旦退避。

mv /var/lib/pgsql/15/data /var/lib/pgsql/15/data_20240229
mkdir -p /var/lib/pgsql/15/data
chmod 700 /var/lib/pgsql/15/data

続いてコマンド実行します。

※主系のPostgreSQLが立ち上がってないとエラーが出ます

pg_basebackup -R -D /var/lib/pgsql/15/data/ -U repl -h [主系IP]

※ユーザが通らない場合は相手ノードのpg_hba.confに
host    replication     repl            0.0.0.0/0        scram-sha-256
を追加してるか確認

※アーカイブファイルが足りない場合は副系にコピー

cp -P 50022 * postgres@192.168.230.129:/var/lib/pgsql/15/archivedir/

postgresql起動＆実行後確認(副系)

systemctl start postgresql-15.service

～～～～～～～～～～～～～ ログ ～～～～～～～～～～～～～

2024-03-05 08:03:00.783 JST [6060] LOG:  PostgreSQL 15.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit を起動しています
2024-03-05 08:03:00.783 JST [6060] LOG:  IPv4アドレス"0.0.0.0"、ポート5432で待ち受けています
2024-03-05 08:03:00.783 JST [6060] LOG:  IPv6アドレス"::"、ポート5432で待ち受けています
2024-03-05 08:03:00.789 JST [6060] LOG:  Unixソケット"/run/postgresql/.s.PGSQL.5432"で待ち受けています
2024-03-05 08:03:00.791 JST [6060] LOG:  Unixソケット"/tmp/.s.PGSQL.5432"で待ち受けています
2024-03-05 08:03:00.800 JST [6066] LOG:  データベースシステムは中断されました: 2024-03-04 23:02:17 JST まで動作していたことは確認できます
cp: `/var/lib/pgsql/15/archivedir/00000006.history' を stat できません: そのようなファイルやディレクトリはありません
2024-03-05 08:03:00.831 JST [6066] LOG:  スタンバイモードに入ります
2024-03-05 08:03:00.831 JST [6066] LOG:  タイムラインID 5上でREDO LSN 0/4B000028、チェックポイントLSN 0/4B000060からのバックアップ・リカバリを開始しました
cp: `/var/lib/pgsql/15/archivedir/00000005.history' を stat できません: そのようなファイルやディレクトリはありません
cp: `/var/lib/pgsql/15/archivedir/00000005000000000000004B' を stat できません: そのようなファイルやディレクトリはありません
2024-03-05 08:03:00.872 JST [6066] LOG:  REDOを0/4B000028から開始します
cp: `/var/lib/pgsql/15/archivedir/00000005000000000000004C' を stat できません: そのようなファイルやディレクトリはありません
2024-03-05 08:03:00.881 JST [6066] LOG:  REDO LSN0/4B000028、終了LSN 0/4B000138のバックアップ・リカバリが完了しました
2024-03-05 08:03:00.881 JST [6066] LOG:  0/4B000138 でリカバリの一貫性が確保されました
2024-03-05 08:03:00.881 JST [6060] LOG:  データベースシステムはリードオンリー接続の受け付け準備ができました
cp: `/var/lib/pgsql/15/archivedir/00000005000000000000004C' を stat できません: そのようなファイルやディレクトリはありません
2024-03-05 08:03:00.975 JST [6072] LOG:  プライマリのタイムライン5の 0/4C000000からでWALストリーミングを始めます

nakayama=# select * from login_table ;
         mail_address         |   password
------------------------------+--------------
 a_nakayama@nakayama-tech.com | nakayamatest
 nakayamatech2017@gmail.com   | riben731
 nakayama                     | nakayama
 aho1496                      | riben731
 aaaaaa                       | bbbbbb
 cccccc                       | ddddd
 dddddd                       | eeeeee
 eeeeee                       | ffffff
 ffffff                       | gggggg
 gggggg                       | hhhhhh
 hhhhhh                       | hhhhhh
 hhhhhh                       | hhhhhh
 zako                         | zako
 aho                          | aho
 kora                         | kora
 kore                         | kore
 koro                         | koro
 za-ko                        | za-ko
 nanto                        | nanto
 iiiiii                       | iiiiii
 manuke                       | manuke
 baho                         | baho
(22 行)

OK！

pgpool

主⇒副の順で立ち上げました。

2024-03-04 23:09:00.710: main pid 4282: LOG:  memory cache initialized
2024-03-04 23:09:00.710: main pid 4282: DETAIL:  memcache blocks :64
2024-03-04 23:09:00.716: main pid 4282: LOG:  pool_discard_oid_maps: discarded memqcache oid maps
2024-03-04 23:09:00.725: main pid 4282: LOG:  waiting for watchdog to initialize
2024-03-04 23:09:00.726: watchdog pid 4293: LOG:  setting the local watchdog node name to "192.168.230.134:9999 Linux study_03"
2024-03-04 23:09:00.726: watchdog pid 4293: LOG:  watchdog cluster is configured with 1 remote nodes
2024-03-04 23:09:00.726: watchdog pid 4293: LOG:  watchdog remote node:0 on 192.168.230.135:9000
2024-03-04 23:09:00.726: watchdog pid 4293: LOG:  interface monitoring is disabled in watchdog
2024-03-04 23:09:00.727: watchdog pid 4293: LOG:  watchdog node state changed from [DEAD] to [LOADING]
2024-03-04 23:09:05.733: watchdog pid 4293: LOG:  watchdog node state changed from [LOADING] to [JOINING]
2024-03-04 23:09:09.739: watchdog pid 4293: LOG:  watchdog node state changed from [JOINING] to [INITIALIZING]
2024-03-04 23:09:10.741: watchdog pid 4293: LOG:  I am the only alive node in the watchdog cluster
2024-03-04 23:09:10.741: watchdog pid 4293: HINT:  skipping stand for coordinator state
2024-03-04 23:09:10.741: watchdog pid 4293: LOG:  watchdog node state changed from [INITIALIZING] to [LEADER]
2024-03-04 23:09:10.741: watchdog pid 4293: LOG:  Setting failover command timeout to 8
2024-03-04 23:09:10.741: watchdog pid 4293: LOG:  I am announcing my self as leader/coordinator watchdog node
2024-03-04 23:09:14.747: watchdog pid 4293: LOG:  I am the cluster leader node
2024-03-04 23:09:14.747: watchdog pid 4293: DETAIL:  our declare coordinator message is accepted by all nodes
2024-03-04 23:09:14.747: watchdog pid 4293: LOG:  setting the local node "192.168.230.134:9999 Linux study_03" as watchdog cluster leader
2024-03-04 23:09:14.747: watchdog pid 4293: LOG:  signal_user1_to_parent_with_reason(1)
2024-03-04 23:09:14.747: watchdog pid 4293: LOG:  I am the cluster leader node. Starting escalation process
2024-03-04 23:09:14.748: watchdog pid 4293: LOG:  escalation process started with PID:4298
2024-03-04 23:09:14.749: main pid 4282: LOG:  watchdog process is initialized
2024-03-04 23:09:14.749: main pid 4282: DETAIL:  watchdog messaging data version: 1.2
2024-03-04 23:09:14.750: main pid 4282: LOG:  Pgpool-II parent process received SIGUSR1
2024-03-04 23:09:14.750: main pid 4282: LOG:  Pgpool-II parent process received watchdog state change signal from watchdog
2024-03-04 23:09:14.751: main pid 4282: LOG:  unix_socket_directories[0]: /var/run/postgresql/.s.PGSQL.9999
2024-03-04 23:09:14.751: main pid 4282: LOG:  listen address[0]: *
2024-03-04 23:09:14.753: main pid 4282: LOG:  Setting up socket for 0.0.0.0:9999
2024-03-04 23:09:14.753: main pid 4282: LOG:  Setting up socket for :::9999
2024-03-04 23:09:14.776: watchdog_utility pid 4298: LOG:  watchdog: escalation started
2024-03-04 23:09:14.782: life_check pid 4299: LOG:  2 watchdog nodes are configured for lifecheck
2024-03-04 23:09:14.782: life_check pid 4299: LOG:  watchdog nodes ID:0 Name:"192.168.230.134:9999 Linux study_03"
2024-03-04 23:09:14.782: life_check pid 4299: DETAIL:  Host:"192.168.230.134" WD Port:9000 pgpool-II port:9999
2024-03-04 23:09:14.782: life_check pid 4299: LOG:  watchdog nodes ID:1 Name:"Not_Set"
2024-03-04 23:09:14.782: life_check pid 4299: DETAIL:  Host:"192.168.230.135" WD Port:9000 pgpool-II port:9999
+ POSTGRESQL_STARTUP_USER=postgres
+ SSH_KEY_FILE=id_rsa_pgpool
+ SSH_OPTIONS='-p 50022 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i ~/.ssh/id_rsa_pgpool'
+ PGPOOLS=(192.168.230.134 192.168.230.135)
+ VIP=192.168.230.100
+ DEVICE=ens33
+ for pgpool in '"${PGPOOLS[@]}"'
+ '[' study_03 = 192.168.230.134 ']'
+ ssh -T -p 50022 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i '~/.ssh/id_rsa_pgpool' postgres@192.168.230.134 '
        /usr/bin/sudo /sbin/ip addr del 192.168.230.100/24 dev ens33
    '
2024-03-04 23:09:14.880: main pid 4282: LOG:  find_primary_node_repeatedly: waiting for finding a primary node
Warning: Permanently added '[192.168.230.134]:50022' (ECDSA) to the list of known hosts.
2024-03-04 23:09:15.076: main pid 4282: LOG:  find_primary_node: primary node is 0
2024-03-04 23:09:15.076: main pid 4282: LOG:  find_primary_node: standby node is 1
2024-03-04 23:09:15.077: main pid 4282: LOG:  listen address[0]: localhost
2024-03-04 23:09:15.078: main pid 4282: LOG:  Setting up socket for ::1:9898
2024-03-04 23:09:15.078: main pid 4282: LOG:  Setting up socket for 127.0.0.1:9898
2024-03-04 23:09:15.089: health_check pid 4341: LOG:  process started
2024-03-04 23:09:15.093: pcp_main pid 4338: LOG:  PCP process: 4338 started
2024-03-04 23:09:15.094: sr_check_worker pid 4339: LOG:  process started
2024-03-04 23:09:15.096: health_check pid 4340: LOG:  process started
2024-03-04 23:09:15.099: main pid 4282: LOG:  pgpool-II successfully started. version 4.4.2 (nurikoboshi)
2024-03-04 23:09:15.099: main pid 4282: LOG:  node status[0]: 1
2024-03-04 23:09:15.099: main pid 4282: LOG:  node status[1]: 2
2024-03-04 23:09:15.816: heart_beat_sender pid 4313: LOG:  set SO_REUSEPORT option to the socket
2024-03-04 23:09:15.816: heart_beat_sender pid 4313: LOG:  creating socket for sending heartbeat
2024-03-04 23:09:15.816: heart_beat_sender pid 4313: DETAIL:  set SO_REUSEPORT
2024-03-04 23:09:15.817: heart_beat_receiver pid 4312: LOG:  set SO_REUSEPORT option to the socket
2024-03-04 23:09:15.818: heart_beat_receiver pid 4312: LOG:  creating watchdog heartbeat receive socket.
2024-03-04 23:09:15.818: heart_beat_receiver pid 4312: DETAIL:  set SO_REUSEPORT

～～　副系起動後　～～

RTNETLINK answers: Cannot assign requested address
+ for pgpool in '"${PGPOOLS[@]}"'
+ '[' study_03 = 192.168.230.135 ']'
+ ssh -T -p 50022 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i '~/.ssh/id_rsa_pgpool' postgres@192.168.230.135 '
        /usr/bin/sudo /sbin/ip addr del 192.168.230.100/24 dev ens33
    '
Warning: Permanently added '[192.168.230.135]:50022' (ECDSA) to the list of known hosts.
+ exit 0
2024-03-04 23:09:23.033: watchdog_utility pid 4298: LOG:  watchdog escalation successful
2024-03-04 23:09:27.343: watchdog_utility pid 4298: LOG:  successfully acquired the delegate IP:"192.168.230.100"
2024-03-04 23:09:27.343: watchdog_utility pid 4298: DETAIL:  'if_up_cmd' returned with success
2024-03-04 23:09:27.346: watchdog pid 4293: LOG:  watchdog escalation process with pid: 4298 exit with SUCCESS.
2024-03-04 23:09:53.126: watchdog pid 4293: LOG:  new watchdog node connection is received from "192.168.230.135:24249"
2024-03-04 23:09:53.126: watchdog pid 4293: LOG:  new node joined the cluster hostname:"192.168.230.135" port:9000 pgpool_port:9999
2024-03-04 23:09:53.126: watchdog pid 4293: DETAIL:  Pgpool-II version:"4.4.2" watchdog messaging version: 1.2
2024-03-04 23:09:53.127: watchdog pid 4293: LOG:  new outbound connection to 192.168.230.135:9000
2024-03-04 23:09:59.694: watchdog pid 4293: LOG:  adding watchdog node "192.168.230.135:9999 Linux study_04" to the standby list
2024-03-04 23:09:59.695: watchdog pid 4293: LOG:  signal_user1_to_parent_with_reason(3)
2024-03-04 23:09:59.696: main pid 4282: LOG:  Pgpool-II parent process received SIGUSR1
2024-03-04 23:09:59.696: main pid 4282: LOG:  Pgpool-II parent process received watchdog quorum change signal from watchdog
2024-03-04 23:09:59.698: watchdog pid 4293: LOG:  Setting failover command timeout to 8
2024-03-04 23:09:59.698: main pid 4282: LOG:  watchdog cluster now holds the quorum
2024-03-04 23:09:59.698: main pid 4282: DETAIL:  updating the state of quarantine backend nodes

そしてレプリケーション遅延の確認も（pgpool側）

 node_id |    hostname     | port | status | pg_status | lb_weight |  role   | pg_role | select_cnt | load_balance_node | replication_delay | replication_state | replication_sync_state | la
st_status_change
---------+-----------------+------+--------+-----------+-----------+---------+---------+------------+-------------------+-------------------+-------------------+------------------------+---
------------------
 0       | 192.168.230.136 | 5432 | up     | up        | 0.500000  | primary | primary | 0          | true              | 0                 |                   |                        | 20
24-03-04 23:11:05
 1       | 192.168.230.129 | 5432 | up     | up        | 0.500000  | standby | standby | 0          | false             | 0                 |                   |                        | 20
24-03-04 23:11:05
(2 行)

遅延なし！

pcp_attach_nodeを実施して遅延が発生することもあるので、このやり方がベストかと思います。

※個人の感想です



まとめ

専門のコマンドは「pg_basebackup」ぐらいで後はディレクトリ作り直しとconfファイルの修正程度でした。

やり方がわかるとそんなに難易度は高くないと思います。

他にもpg_databackupで相手ノードからデータをコピーするやり方もあります。

是非色々試してみてください！



  • VMware × CentOS関連索引

※中山テックに掲載しているゲーム画像の著作権、商標権、その他知的財産権は、当該コンテンツの提供元に帰属します


この記事を書いた人
中山テック代表
中山テック代表
個人事業のシステムエンジニアです
前職はゴリゴリの営業マン(保険売りまくってた)
大抵のプログラミングはこなせます
環境構築もそれなりに出来るかと思います
趣味はゲーム、競馬、食べ歩き、旅行など
備忘と記録を残すためにブログを執筆しております

お仕事のお話は問い合わせフォームからお気軽にお声掛けください♪
最近書いた記事
【バックエンド開発】代表の実績や経験をご紹介すると共に得た知識を技術コラムとして執筆
データベース
【バックエンド開発】代表の実績や経験をご紹介すると共に得た知識を技術コラムとして執筆
【PostgreSQL】えっ！？レプリカセットで3台以上を！？～PRIMARY基準に構築する～
データベース
【PostgreSQL】えっ！？レプリカセットで3台以上を！？～PRIMARY基準に構築する～
【Ball Blast】迫りくる岩を大量に打ち落とす爽快ゲームを攻略する～育成要素もあるョ～
ゲーム
【Ball Blast】迫りくる岩を大量に打ち落とす爽快ゲームを攻略する～育成要素もあるョ～
【Aurora7】独自の育成方法、操作性抜群の戦闘システムをご紹介～躍動感のあるアクションを楽しもう～
ゲーム
【Aurora7】独自の育成方法、操作性抜群の戦闘システムをご紹介～躍動感のあるアクションを楽しもう～
おすすめの記事