データベースのレプリケーションの話
えーと本日は、データベースのレプリケーションの話をしようと思う。データベースといってもRDBMSである。30年前からRDBMSは存在している。その当時もレプリケーションと呼ばれる技術は存在した。しかし、30年前は高速な通信環境が整備されていなかったからあまり積極的に使われていなかったかも。せいぜい、バックアップを自動的にやるしくみ程度の扱いだったかなぁ。だって、通信回線がISDNで128Kbpsっていう感じだからまる一日かかっても同期しないみたいな。LANでやるにしても10base-Tとかの時代なので10Mbpsしか出ない。
今や10Gbpsの時代である。うちにもあるよ10Gのスイッチ。データセンター内では100Gbpsっていうのもあるらしい。
でね。高速通信が可能になるとレプリケーションも便利なわけですよ。簡単に負荷分散ができる。AWSのAuroraでもリードレプリカを作成すれば負荷分散もできるし耐障害性も上がる。コストも増えるけどね。
というわけで、AWS Auroraでレプリケーションやってみたいけど、コストが倍になってしまうので、ローカル環境で実験してみたという話である。前回のNodeJSの同期、非同期の比較でイマイチな結果になったのでリベンジしたいという思いもある。
自宅で仕事をしているので、家にサーバーがある。サーバーではProxmox基盤上に各種RDBMSやファイルサーバなんかが、UbuntuやCentOSのVM上で稼働している。RDBMSはSQLの検証用。ファイルサーバはNASとして普通に使用している。CentOSはアプリケーションの開発用。DockerとかNodeJSとかが入っている。
実は、Postgresについては、既にマスターとレプリカの2台構成で稼働している。
ct-postgres-mstがマスターで、ct-postgres-rr3がレプリカである。
レプリカにするには?
レプリカとして稼働させるには設定が必要である。その設定方法を見ていこう。
replication通信を許可する
まず、マスターとレプリカ間でIP通信ができないと同期することができないので、マスター側のpg_hba.confを編集して通信を許可する。ファイルの場所は色々あると思うがたいていは/etc/postgresql以下にあると思うので検索してみて欲しい。
うちの場合以下のようにした。
pg_hba.conf
# permit local network
host replication all 192.168.0.0/24 password
# Accept all IPv4 connections - CHANGE THIS!!!
#host all all 0.0.0.0/0 md5
host all all 192.168.0.0/24 md5
プライベートネットワークアドレスだけreplicationを許可。
下の1行はpsqlコマンドで外部から接続するときに必要。
マスター、レプリカの両方で設定しておく。
synchronous_standby_namesを設定する
マスター側のpostgresql.confを編集してsynchronous_standby_namesを'*'にする。
マスター側のpostgresql.conf
# - Master Server -
# These settings are ignored on a standby server.
#synchronous_standby_names = '' # standby servers that provide sync rep
# method to choose sync standbys, number of sync standbys,
# and comma-separated list of application_name
# from standby(s); '*' = all
synchronous_standby_names = '*'
名前からもわかるように、スタンバイ状態のレプリカサーバーを指定するもの。*を設定しておくことで、すべてのレプリカサーバーが対象になる。
hot_standbyをonにする
レプリカ側のpostgresql.confを編集してhot_standby機能をonにする。
レプリカ側のpostgresql.conf
hot_standby = on # "off" disallows queries during recovery
# (change requires restart)
試験してみる
驚くことに「たったこれだけ」でマスターとレプリカの2台構成ができてしまう。いやいや便利。
本当にできているのか確かめてみよう。設定できたら、再起動する。立ち上がったらマスターとレプリカの両方に接続してみて欲しい。
マスター
$ psql -h 192.168.0.53 -U postgres postgres
ユーザ postgres のパスワード:
psql (13.7、サーバ 13.20 (Debian 13.20-0+deb11u1))
SSL 接続 (プロトコル: TLSv1.3、暗号化方式: TLS_AES_256_GCM_SHA384、ビット長: 256、圧縮: オフ)
"help"でヘルプを表示します。
postgres=#
レプリカ
$ psql -h 192.168.0.56 -U postgres postgres
ユーザ postgres のパスワード:
psql (13.7、サーバ 13.20 (Debian 13.20-0+deb11u1))
SSL 接続 (プロトコル: TLSv1.3、暗号化方式: TLS_AES_256_GCM_SHA384、ビット長: 256、圧縮: オフ)
"help"でヘルプを表示します。
postgres=#
何かテーブルを作成するが、ますばレプリカの方からやってみて。
レプリカ
postgres=# create table foo (a integer);
ERROR: cannot execute CREATE TABLE in a read-only transaction
レプリカはread onlyになってるので、書き込みはできない。
マスターの方で何かテーブルを作成する。
マスター
postgres=# create table foo (a integer);
CREATE TABLE
マスターはread onlyではないのでちゃんとテーブルを作成できる。マスターとレプリカは瞬時に同期されるのでレプリカ側にもテーブルが作成されている。
レプリカ
postgres=# select * from foo;
a
------------
(0 行)
おーこれは便利。
マスター側でレコードを作成してみる。
マスター
postgres=# insert into foo values(1);
INSERT 0 1
postgres=# select * from foo;
a
------------
1
(1 行)
レプリカ
postgres=# select * from foo;
a
-------------
1
(1 行)
ちゃんとできてるじゃない。
※ 最初にpg_basebackupで同期する必要があったかも。後で気付いた。以下サイトを参考にして欲しい。
投稿者プロフィール

-
システムエンジニア
喋れる言語:日本語、C言語、SQL、JavaScript
最新の投稿
コンピューター関係の記事2025年4月30日データベースのレプリケーションの話
コンピューター関係の記事2025年4月29日Nodejsの同期、非同期について【Promiseとか】
コンピューター関係の記事2025年4月26日アイキャッチ画像にSQLアイコンとJSONアイコンが欲しい
コンピューター関係の記事2025年4月23日AdSense審査に無事パス