tom__bo’s Blog

MySQL!! MySQL!! @tom__bo

トップ > PostgreSQL > PostgreSQL　レプリケーション構成を組んでみる

PostgreSQL　レプリケーション構成を組んでみる

PostgreSQL

WAL, アーカイブログ, PITLもなんとなくわかってきたことなので、ようやくレプリケーションを試してみようと思う。
pg-poolⅡとかHA化のためのツールも有るようだが、今回はPostgreSQLの機能だけを使って構築してみようと思う。


毎回出しているが、以下のリンクの「PostgreSQL全機能バイブル」を読んで試して、メモを残したエントリ。www.amazon.co.jp


今回は上の本の2-11章、3-20, 3-22~3-23章の内容を読んだ内容です。


＜環境＞

＜やること＞

  1. 前回作成したインスタンス(pg93_1) をvagrant box化
  2. レプリケーションを設定
  3. レプリケーション構成その２

 

1. インスタンスのvagrant box化

NICのマッピングを削除しておく

sudo ln -s -f /dev/nul /etc/udev/rules.d/70-persistent-cd.rules


exitしてインスタンスをシャットダウン。
ボックスの作成と登録

user> vagrant halt
user> vagrant package
vagrant box add pg93 package.box

ここで作成したboxを使ってpg_93_1, pg93_2, pg93_3, pg93_4にインスタンス作成する。



2. レプリケーションを設定

3-22章の構成と同様に、マスタとスレーブ3台を作成します。

上記でvagrant box化したpg93を使って、残りのスレーブslave1, slave2, slave3を作成します。
vagrant-hostsupdateやvagrant-hostmanagerを使って、インスタンスにホスト名をつけようと苦戦したが、上手く行かず断念。
レプリケーションの実験をしたいだけなので、不便だけどIPアドレスで頑張る

listen_addresses = '*'
wal_level = hot_standby
max_wal_senders = 10
wal_keep_segments = 5
synchronous_standby_names = 'slave1,slave2' # 左が優先度高く、slave1は同期レプリになる
    • pg_hba.confを設定
# TYPE DATABASE    USER     CIDR-ADDRESS    METHOD
   host  replication postgres 192.168.33.0/24   trust
    • 起動

ベースバックアップを取得するためm1を起動。
とくに意味は無いがユーザを適当に追加しておく。

postgres> pg_ctl start
  • スレーブの準備
    • pg_basebackup

参考書に従って、pg_basebackupコマンドによるバックアップ取得をする。
スレーブ側ではすでにデータベースクラスタが存在しているとバックアップが出来ないので、削除しておく

s1> rm -rf /usr/local/pgsql/data

スレーブ側で、pg_basebackupコマンドを実行する。

s1> pg_basebackup -h 192.168.33.101 -p 5432 -D /usr/local/pgsql/data --xlog --progress --verbose
 # -h: マスタのホスト名
 # -p: マスタのポート番号
 # -D: スレーブ側で作成するディレクトリ指定
 # --xlog: マスタ側のpg_xlog以下のWALもバックアップする。
 # --progress: バックアップの進捗状況を表示する
 # --verbose: 詳細なメッセージ出力

他のオプションは参考書のp.192やドキュメント参照

/dataディレクトリをバックアップしてきたので、/usr/local/pgsql/dataディレクトリにマスタと同様のpostgresql.conf, pg_hba.confが存在する。
マスタの設定のままでは行けないので、最低限の変更をする。

postgresql.conf

synchronous_standby_names = '' 
hot_standby = on

recovery.confは/usr/local/pgsql/share/recovery.conf.sampleがあるので、これに書き加える。
recovery.conf

standby_mode = on
primary_conninfo = 'host=192.168.33.101 port=5432 application_name=slave1'
# application_nameはslave2, slave3の場合はそれ
    • それぞれのスレーブを起動
pg_ctl -D /usr/local/pgsql/data start

マスターノードでスレーブの状態を確認してみる

dvdrental=# SELECT application_name, client_addr, state, sync_priority, sync_state FROM pg_stat_replication;
 application_name |  client_addr   |   state   | sync_priority | sync_state
------------------+----------------+-----------+---------------+------------
 slave1           | 192.168.33.102 | streaming |             1 | sync
 slave2           | 192.168.33.103 | streaming |             2 | potential
 slave3           | 192.168.33.104 | streaming |             0 | async
(3 rows)

上のコマンドで、

という風にそれぞれの方法でレプリケーション構成が組めていることが確認できた。

適当なデータをマスタに入れればslave側に更新が反映されていることが確認できる。

# masterにて
dvdrental=# INSERT INTO actor (first_name, last_name) VALUES ('tom', 'bo');
dvdrental=# SELECT * FROM actor WHERE first_name LIKE 'tom';


次回は、実際にslave1を落とすとslave2が自動で同期レプリになるの？とかmasterが落ちた場合の昇格はどうするの？といった部分を試してみようと思います。





終わり　⊂ﾟＵ┬───┬~