Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

608 views

Published on

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

Published in: Software
  • Be the first to comment

  • Be the first to like this

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

  1. 1. 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
  2. 2. 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にて接続可能がデータベースやホストを設定
  3. 3. 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$
  4. 4. 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 同期レプリケーション対象のスタンバイサーバを指定。 カンマ区切りで複数指定でき、リスト内で 先頭に書かれているサーバが同期レプリケーション対象となる。 同期レプリケーション対象のサー バと通信が途切れた場合、リスト内で次に指定されたサーバが同期レプリケーション対象に変わる。 *を指定した場合は全てのスタンバイサーバが対象となります。ここでは*を指定してます。
  5. 5. 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等もあります。これ以外にもいろいろとオプション があるのと、バージョンによっても変わるので念のためチェック しておくと良いです。
  6. 6. Replication Status & Read Only On Secondary PostgreSQLにてSecondaryはRead Onlyになっている MySQLに関しては、"read_only", "super_read_only" パラメータを設定するとSecondaryを参照のみ可能に出来る。
  7. 7. 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
  8. 8. 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 -rw-------. 1 postgres postgres 16777216 1月 13 10:11 000000010000000000000006 -rw-------. 1 postgres postgres 16777216 1月 13 10:11 000000010000000000000007 -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;"
  9. 9. 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の時は、 同期出来るまで書き込み処理が待ちになる
  10. 10. その他 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

×