MySQLとPostgreSQLの基本的なレプリケーション設定比較

Compared Version
MySQL PostgreSQL
root@localhost [mysql]> select @@version,now();
+-----------+---------------------+
| @@version | now() |
+-----------+---------------------+
| 8.0.18 | 2019-11-04 01:50:06 |
+-----------+---------------------+
1 row in set (0.00 sec)
postgres=# select version();
version
--------------------------------------
PostgreSQL 12.0 on x86_64-pc-linux-gnu,
compiled by gcc (GCC) 4.8.5 20150623
(Red Hat 4.8.5-39), 64-bit
(1 行)
PostgreSQL 12 Release date: 2019-10-03
https://www.postgresql.org/docs/12/release-12.html
MySQL 8.0.18 Release date: 2019-10-14
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-18.html

Replication Basic Configuration (アカウント)
MySQL PostgreSQL
mysql> CREATE USER 'replication_user'@'%' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'%';
postgres=# CREATE USER replication_user WITH REPLICATION;
CREATE ROLE
postgres=# ALTER ROLE replication_user WITH PASSWORD 'password';
ALTER ROLE
postgres=# du
-bash-4.2$ cat /var/lib/pgsql/12/data/pg_hba.conf | grep replication_user
host replication replication_user 192.168.56.112/24 trust
-bash-4.2$
MySQLはアカウント名＋ホスト(アドレス)＝ユーザーアカウントなので、
ホストの部分には特定スレーブのIPやIPセグメントを指定してあげるとより
セキュアにすることが出来る。
アカウントは、REPLICATION SLAVE権限のみ設定すればOK
PostgreSQLはアカウント(ROLE)とpg_hba.confにてアクセス設定をしているので、
ユーザーアカウントには、REPLICATION権限を設定して、pg_hba.confには
SLAVE(Secondary)のIPかセグメントを指定してあげる。
アカウントは、REPLICATION権限を設定すればOK
後名
据接続可能
作成
pg_hba.confにて接続可能がデータベースやホストを設定

Replication Basic Configuration(バックアップ)
MySQL PostgreSQL
❶ マスター若しくは、稼働中のスレーブにてバックアップを取得
-bash-4.2$ mysqldump --user=root --password=password --all-databases --
default-character-set=utf8mb4 --flush-logs --single-transaction --hex-blob
--triggers --routines --events --master-data=2 > all_dbs_20200105.sql
❷ ダンプをSlaveでリストア。(ディスク容量等が枯渇している場合はログをOFFにしておくと良い)
-bash-4.2$ mysql -u root -p < all_dbs_20200105.sql
❸ 正常に起動していれば、マスターに接続し更新をもらってくる（ダンプファイル確認)
mysql> CHANGE MASTER TO MASTER_HOST='Host or IP', # LOGポジションベースの場合
-> MASTER_USER='replication_user', MASTER_PASSWORD='password',
-> MASTER_LOG_FILE='recorded_log_file_name', MASTER_LOG_POS=recorded_log_position;
mysql> CHANGE MASTER TO MASTER_HOST='Host or IP',　　　# GTIDモードの場合
-> MASTER_USER=‘replication user',MASTER_PASSWORD=‘password',
-> MASTER_AUTO_POSITION=1;
❹　Start Slave; コマンドにてレプリケーション開始
新スタンバイサーバーにてバックアップを実行してマスターからデータを取得
pg_basebackup -R -D ${PGDATA} -h プライマリーサーバー -p 5432
pg_basebackup -R -h 192.168.56.104 -p 5432 -U replication_user -D "/var/lib/pgsql/12/data"
例）既に古いデータがある場合はフォルダーを空にしてからバックアップしてください。
-bash-4.2$ systemctl stop postgresql-12
-bash-4.2$ systemctl status postgresql-12
-bash-4.2$ pwd
/var/lib/pgsql/12
-bash-4.2$ rm -rf data/
-bash-4.2$ mkdir data
-bash-4.2$ pg_basebackup -R -D ${PGDATA} -h 192.168.56.104 -p 5432 -U replication_user
-bash-4.2$ chown -R postgres:postgres data/
-bash-4.2$ chmod -R 700 data/
■ GTIDベースOFF＝ログポジションベースの場合のダンプ
-bash-4.2$ zcat ALLDB_20200105.sql.gz | grep -A5 "Position to start replication or point-
in-time recovery from"
-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.001403', MASTER_LOG_POS=155;
■ GTIDモードがONの場合のダンプ
-bash-4.2$ cat dbs_20200105.sql | grep -A5 "GTID state at the beginning of the backup"
-- GTID state at the beginning of the backup
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '50fca08e-5a35-11e8-a4f2-06db798d79c8:1';
※　MySQLの場合もmysqlbackup(商用)かxtrabackup(無償)を利用する事で物理バックアップ取得可能
上記は物理バックアップにｰRオプションを付けているので、postgres.confの設定を
"hot_standby = on"に変更してあげれば基本的なレプリケーション設定が完了し、
"bash-4.2$ systemctl restart postgresql-12" で起動すればスレーブとして起動してきます。
この時点で参照のみが可能な状態となっているので間違えて更新する心配はありません。
パラメータは次のページ以降を参照
上記Slaveを起動時に更新処理を実行してみるとリードオンリーモードになっていることを確認出来る
-bash-4.2$ psql app -c "insert into memo(id,data,data2) values(5,'PostgreSQL
Replication','Insert at Slave')";
ERROR: リードオンリーのトランザクションでは INSERT を実行できません
-bash-4.2$

Replication Basic Configuration(パラメタ)
MySQL Master(Primary) PostgreSQL Master (Primary)
$ cat /etc/my.cnf
server-id
log-bin
gtid-mode=on 　　　　　　 #GTIDモードを利用する場合のオプション
enforce-gtid-consistency=on　#GTIDモードを利用する場合のオプション
log-slave-updates #Slaveになった場合にマスターからの伝搬を記録
-bash-4.2$ cat postgresql.conf | grep -e wal -e archive -e synchronous | grep -v ^#
wal_level = replica # minimal, replica, or logical
max_wal_size = 1GB
min_wal_size = 80MB
archive_mode = on # enables archiving; off, on, or always
archive_command = 'cp %p /var/lib/pgsql/12/data/archive/%f' # archive a logfile segment
max_wal_senders = 10 # max number of walsender processes
wal_keep_segments = 10 # in logfile segments; 0 disables
wal_sender_timeout = 60s # in milliseconds; 0 disables
synchronous_standby_names = '*' # standby servers that provide sync rep
Server-idはレプリケーショングループメンバー内で競合が発生しないように一意の値を設定
GTIDモード:
- GTIDはレプリケーション構成および管理が非常にシンプルで運用しやすい
- マスター/スレーブ共に、非トランザクションストレージエンジンンに対する更新を
同一のトランザクション内に混在できない(InnoDB/MyISAM等)
- CREATE TABLE ... SELECT“ が使用できない
- CREATE TEMPORARY TABLEおよびDROP TEMPORARY TABLEをトランザクション中で使用できない
InnoDB Cluseter等は、GTIDが必須となっている。まだレプリケーション設定していなければ、
GTIDモードで良いかと思います。ただ、ログポジションベースの運用に慣れている場合は、
ログポジションベースで運用することで工数削減できるのであればOKかと。
wal_level
選択できる出力レベルは9.5までminimal、archive、hot_standby、logicalの4段階
9.6からarchiveとhot_standbyが統合されminimal、replica、logicalの3段階
ストリーミング・レプリケーションを構成するにはminimal以外に設定。
max_wal_senders
WALを転送するスタンバイサーバの最大数を指定
max_connections以上の値は指定できません。
wal_keep_segments
pg_xlog配下に保持する最小WALセグメント数を指定するパラメータ。
レプリケーション遅延が発生した場合、マスタ側で転送前のWALが削除されることを防ぐために設定。
synchronous_standby_names
同期レプリケーション対象のスタンバイサーバを指定。カンマ区切りで複数指定でき、リスト内で
先頭に書かれているサーバが同期レプリケーション対象となる。同期レプリケーション対象のサー
バと通信が途切れた場合、リスト内で次に指定されたサーバが同期レプリケーション対象に変わる。
*を指定した場合は全てのスタンバイサーバが対象となります。ここでは*を指定してます。

Replication Basic Configuration(パラメタ)
MySQL Slave(Secondary) PostgreSQL Slave (Secondary)
$ cat /etc/my.cnf
server-id
gtid-mode=on　　　　　　　　　　#GTIDモードを利用する場合のオプション
enforce-gtid-consistency=on　　#GTIDモードを利用する場合のオプション
log-bin 　　　　　 #必須ではないがマスターになるのであれば
log-slave-updates 　　　#必須ではないがマスターにんるのであれば
relay_log_recovery 　　 #リレーログ破損時のリカバリーオプション
read_only　　　　　　　　　　　#Superユーザー以外は参照のみ可能
super_read_only #全てのユーザーが参照のみ可能
slave_parallel_workers #レプリケーション高速化オプション
slave_parallel_type　　　　　　 #parallel処理する場合に変更
slave_preserve_commit_order #parallel処理する場合の処理順序を担保
-bash-4.2$ cat postgresql.conf | grep standby
# Set these on the master and on any standby that will send replication data.
# These settings are ignored on a standby server.
# synchronous_standby_names = '*' # standby servers that provide sync rep
hot_standby = on # "off" disallows queries during recovery
#max_standby_archive_delay = 30s # max delay before canceling queries
#max_standby_streaming_delay = 30s # max delay before canceling queries
#hot_standby_feedback = off # send info from standby to prevent
-bash-4.2$
[root@CL-SLAVE01 data]# cat postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
primary_conninfo = 'user=replication_user passfile=''/var/lib/pgsql/.pgpass''
host=192.168.56.104 port=5432 sslmode=prefer sslcompression=0 gssencmode=prefer
krbsrvname=postgres target_session_attrs=any'
[root@CL-SLAVE01 data]#
-bash-4.2$ ls -l standby.signal
-rwx------. 1 postgres postgres 0 1月 11 10:32 standby.signal
-bash-4.2$
Server-idはレプリケーショングループメンバー内で競合が発生しないように一意の値を設定
MySQLパラメータのバージョン毎の違いは、こちらが非常に参考になります
https://mysql-params.tmtms.net/mysqld/?vers=5.6.38,5.7.21,8.0.19&diff=true
※ PostgreSQL12からrecovery.confがpostgresql.confに統合されています。
postgresql.auto.confが自動生成されていればprimary_conninfoは追加設定は不要
※ pg_basebackupで-Dオプションを指定する事で、standby.signalが作成され、
SlaveがPrimaryとして起動することを回避する事が出来るようになっています。
touch でファイルを作成してもStandbyサーバとして起動可能
レプリケーションやSUPERユーザーだけのアクセスを許可する
offline_mode等もあります。これ以外にもいろいろとオプション
があるのと、バージョンによっても変わるので念のためチェック
しておくと良いです。

Replication Status & Read Only On Secondary
PostgreSQLにてSecondaryはRead Onlyになっている
MySQLに関しては、"read_only", "super_read_only"
パラメータを設定するとSecondaryを参照のみ可能に出来る。

Replication Status
MySQL PostgreSQL
mysql> show slave status¥G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.56.104
Master_User: replication_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.001403
Read_Master_Log_Pos: 155
Relay_Log_File: slave-relay-bin.000001
Relay_Log_Pos: 575287
Relay_Master_Log_File: binlog.001403
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
<SNIP>
Seconds_Behind_Master: 0
<SNIP>
Retrieved_Gtid_Set: 50fca08e-5a35-11e8-a4f2-06db798d79c8:1-244
Executed_Gtid_Set: 50fca08e-5a35-11e8-a4f2-06db798d79c8:1-244
Auto_Position: 1
<SNIP>
app=# select * from pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid | 2064
usesysid | 57347
usename | replication_user
application_name | walreceiver
client_addr | 192.168.56.112
client_hostname |
client_port | 32984
backend_start | 2020-01-12 19:56:41.843405+09
backend_xmin |
state | streaming
sent_lsn | 0/4002D58
write_lsn | 0/4002D58
flush_lsn | 0/4002D58
replay_lsn | 0/4002D58
write_lag |
flush_lag |
replay_lag |
sync_priority | 1
sync_state | sync
reply_time | 2020-01-12 20:29:18.639437+09
app=# select pg_wal_lsn_diff(sent_lsn,write_lsn)
write_diff_byte,pg_wal_lsn_diff(sent_lsn,flush_lsn)
flush_diff_byte,pg_wal_lsn_diff(sent_lsn,replay_lsn) replay_diff_byte from
pg_stat_replication;
-[ RECORD 1 ]----+--
write_diff_byte | 0
flush_diff_byte | 0
replay_diff_byte | 0

Replication Status (Log Position)
MySQL PostgreSQL
[Primary]
SHOW MASTER LOGS;
[Secondary]
SHOW SLAVE STATUS;
MySQLのPerformance_SchemaやSYSスキーマを利用して確認すると良いでしょう。
MySQLはMYSQLDはシングルプロセス、マルチスレッドで稼働しているので、
OSレベルのプロセスでの確認は不要・不可
詳細:
https://dev.mysql.com/doc/mysql-perfschema-excerpt/8.0/en/performance-schema-
replication-tables.html
10.11.1 The replication_connection_configuration Table
10.11.2 The replication_connection_status Table
10.11.3 The replication_applier_configuration Table
10.11.4 The replication_applier_status Table
10.11.5 The replication_applier_status_by_coordinator Table
10.11.6 The replication_applier_status_by_worker Table
10.11.7 The replication_applier_global_filters Table
10.11.8 The replication_applier_filters Table
10.11.9 The replication_group_members Table
10.11.10 The replication_group_member_stats Table
[Primary]
-bash-4.2$ ls -l archive/
合計 49152
-rw-------. 1 postgres postgres 16777216 1月 13 10:11 000000010000000000000005
-bash-4.2$ psql app -c "select
pg_current_wal_insert_lsn(),pg_walfile_name(pg_current_wal_lsn());"
pg_current_wal_insert_lsn | pg_walfile_name
---------------------------+--------------------------
0/8000E20 | 000000010000000000000008
(1 行)
-bash-4.2$ ps -ef | grep walsender
postgres 2129 973 0 12:33 ? 00:00:00 postgres: walsender replication_user
192.168.56.112(55778) streaming 0/8000F08
postgres 2458 2158 0 12:56 pts/0 00:00:00 grep --color=auto walsender
-bash-4.2$
[Secondary]
-bash-4.2$ ps -ef | grep recovering
postgres 1045 995 0 12:33 ? 00:00:00 postgres: startup recovering
000000010000000000000008
postgres 1207 1142 0 12:57 pts/0 00:00:00 grep --color=auto recovering
-bash-4.2$
-bash-4.2$ psql -c "select * from pg_stat_wal_receiver;"

Replication Basic Configuration (非同期同期)
MySQL (Defaultは準同期, 準同期は以下の設定) PostgreSQL
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
【マスター側】
rpl_semi_sync_master_enabled = ON
rpl_semi_sync_master_wait_no_slave = ON
rpl_semi_sync_master_timeout = 10000 rpl_semi_sync_master_wait_for_slave_count = 1
rpl_semi_sync_master_wait_point = AFTER_SYNC　　#AFTER_COMMITか選択可能
【スレーブ側】
rpl_semi_sync_slave_enabled = ON
-bash-4.2$ cat /var/lib/pgsql/12/data/postgresql.conf | grep synchronous
# - Asynchronous Behavior -
synchronous_commit = on
# synchronization level (off, local, remote_write, on, remote_apply)
synchronous_standby_names = '*' # standby servers that provide sync rep
#PostgreSQL9.6からは複数スタンバイを同期として設定可能
-bash-4.2$
postgres=# select name,setting,unit,context,category,short_desc
postgres-# from pg_settings where name like '%synchronous_%';
-[ RECORD 1 ]----------------------------------------------------
name | synchronous_commit
setting | on　
unit |
context | user
category | 先行書き込みログ / 設定
short_desc | 現在のトランザクションの同期レベルを設定。
-[ RECORD 2 ]----------------------------------------------------
name | synchronous_standby_names
setting | *
unit |
context | sighup
category | レプリケーション / マスタサーバ
short_desc | 同期スタンバイの数と同期スタンバイ候補の名前の一覧。
プラグインはマスター、スレーブ共にプラグインを両方インストールしても問題はない、もちろん
マスター用、スレーブ用それぞれに必要なプラグインのみインストールしてもOK。
有効にするかどうかはオプションファイルで設定
AFTER_SYNCはMySQL5.7から実装された、より安全にデータ保護出来るオプション。
マスターサーバーのログの書き込みも適切に設定。
- synchronous_commit = remote_write
このオプションは、データがスタンバイサーバー上のディスクキャッシュに書き込まれるまで、
マスター上のトランザクションを待機させる事を可能にします。
- synchronous_commit = remote_apply
このオプションは COMMIT が同期スタンバイサーバーがトランザクションをディスクに書き終えて
いない間で、かつ 'applied' である間、マスターサーバーをやや長く待機させます。
MySQLもPostgreSQLも複数サーバーからのデータ同期のACKを待つ設定が可能
＝ SYNC設定が入っている時は、Secondaryがダウンしている間はタイムウトま
でマスターへの書き込みが待たされる。書き込みが待たされる事が許容できな
かったり、データ同期がASYNCでも良い場合は無理に同期にしなくても良いかと。
サーバーやネットワークの負荷にもよるが,どちらもほぼ同期に近い
ASYNCにしたい時は,local等に設定を変更
設定が入っていて、synchronous_commitがONの時は、
同期出来るまで書き込み処理が待ちになる

その他
MySQL, PostgreSQL共
方法等設定出来必要応細動作
色調整出来適宜見調整最適
運用出来
高可用性構成関 MySQL 関 InnoDB Cluster等高可用性構成
組事出来 PostgreSQL PGPool 設定高可用性構成組
出来十分設計検証事安定稼働運用必須
https://dev.mysql.com/doc/refman/8.0/en/replication.html
https://www.postgresql.jp/document/11/html/logical-replication.html
https://lets.postgresql.jp/documents/technical/replication/1
https://www.enterprisedb.com/de/ja/blog/cheat-sheet-configuring-streaming-synchronous-replication-postgresql
https://www.slideshare.net/masahikosawada98/postgresql-86891271
https://www.slideshare.net/ShinyaSugiyama/mysql-57
https://www.slideshare.net/ShinyaSugiyama/db-tech-showcasetokyo2018locondo

MySQLとPostgreSQLの基本的なレプリケーション設定比較

More Related Content

What's hot (20)

Similar to MySQLとPostgreSQLの基本的なレプリケーション設定比較 (20)

More from Shinya Sugiyama (20)

MySQLとPostgreSQLの基本的なレプリケーション設定比較