PostgreSQLレプリケーション（pgcon17j_t4）
8 likes7,615 views
PostgreSQL Conference Japan 2017（2017年11月3日） チュートリアルトラック4コマ目の発表資料です。
PostgreSQLレプリケーション（pgcon17j_t4）
- 1. PostgreSQL レプリケーション 【T1】 SQLの基本 【T2】 PostgreSQLチューニング 【T3】 データベース監視の基本 【T4】 PostgreSQLレプリケーション解説 PostgreSQL Conference Japan 2017 2017.11.3 株式会社アシスト データベース技術本部 日本PostgreSQLユーザ会 喜田 紘介
- 2. 【T4】PostgreSQLレプリケーション Japan PostgreSQL User's Group 2 セッションテーマ 安定稼働を使命とするデータベースでは、障害が発生した場合もすぐに再稼働で きるよう様々な工夫を凝らして設計されます。このような高可用システムを実現 する機能としてPostgreSQLではレプリケーションが用いられます。 内容、対象者 PostgreSQLのレプリケーション機能の解説と、実機でレプリケーションを構築 するデモをご覧いただきます。インフラ担当や高可用システムの設計を担当する 方を対象に、PostgreSQLで何ができるかを解説します。 株式会社アシスト 日本PostgreSQLユーザ会 理事 喜田 紘介氏 入社時よりOracle Databaseの構築、運用、サポート等を経験。 2011年よりPostgreSQLチームに所属し「EDB Postgres」担当と してユーザー自身で活用できるデータベースを目指して技術支援 や情報発信に務めています。 日本PostgreSQLユーザ会にも所属し、PostgreSQLやデータベー ス技術の普及に向けて積極的な活動を心がけています。
- 4. DBに期待する「安定稼働」 アプリケーションの要求に対して結果を返す Japan PostgreSQL User's Group 4 データベースに期待する機能とは？ Click！ DBへの問合せ
- 5. DBに期待する「安定稼働」 アプリケーションの要求に対して結果を返す Japan PostgreSQL User's Group 5 データベースに期待する機能とは？ Click！ DBへの問合せ 応答が ありません サービスは年間●●時間しか停止できないという要件があり、 データベースにアクセスできない状態（＝DBの障害）は その時間にさらに余裕を持たせ、対策されなければいけません。
- 6. DBに期待する「安定稼働」 アプリケーションの要求に対して結果を返す Japan PostgreSQL User's Group 6 データベースに期待する機能とは？ Click！ DBへの問合せ 応答が ありません サービスは年間●●時間しか停止できないという要件があり、 データベースにアクセスできない状態（＝DBの障害）は その時間にさらに余裕を持たせ、対策されなければいけません。 可用性とは ・年間で1日停止して良いシステム 364日/365日=99.7%の稼働率 ・1時間しか停止を許さないシステム 8759時間/8760時間=99.998% （99.999%なら約50分）
- 7. DBに期待する「安定稼働」 複数のアプリケーションが共通のデータを利用 Japan PostgreSQL User's Group 7 もうひとつの可用性 DBへの問合せ
- 8. DBに期待する「安定稼働」 複数のアプリケーションが共通のデータを利用 Japan PostgreSQL User's Group 8 もうひとつの可用性 DBへの問合せ 一部分の障害に対して、 他のサービスは継続して 動き続けるように保つ。
- 9. 複製（レプリケーション） システムの構成要素は必ず故障しうるものとして対策 機器の二重化など ではデータは？ Japan PostgreSQL User's Group 9 データベースの障害に備えるには Click！ DBへの問合せ ?
- 10. 複製（レプリケーション） システムの構成要素は必ず故障しうるものとして対策 機器の二重化など ではデータは？ Japan PostgreSQL User's Group 10 データベースの障害に備えるには Click！ DBへの問合せ ? 複数のユーザーが リアルタイムに更新を かけ続けるDBは、 完全に同じ状態の複製を 用意することが難しい
- 11. 複製（レプリケーション） システムの構成要素は必ず故障しうるものとして対策 機器の二重化など ではデータは？ Japan PostgreSQL User's Group 11 データベースの障害に備えるには Click！ DBへの問合せ 全ての更新を担当する プライマリ（マスター） ノード プライマリから更新を 受け取るスタンバイ （スレーブ）ノード PostgreSQLでは 「ストリーミングレプリケーション」 で実現
- 12. 複製（レプリケーション） 平常時の参照負荷分散 数秒遅れでも構わないRead Onlyな処理 アプリ側でスタンバイノードに問合せ 障害時に新マスターに昇格 データベースに対し 「昇格」を指示 アプリの向き先を変更 仮想IP DNSの書き換え アプリの接続先修正 Japan PostgreSQL User's Group 12 「よくある」レプリケーションで実現できる機能 参照・更新が可能 参照のみ可能 数秒のタイムラグを許容
- 14. 前提知識 リアルタイムなバックアップは難しい 常に更新されるDBは「ある時点」のバックアップが前提 バックアップ以降の更新を「変更履歴」として保持 変更履歴を適用するリカバリの考え方 Japan PostgreSQL User's Group 14 バックアップと変更履歴（WAL）の役割を知っておく 時間 表 表 表 UPDATE 表 表 バックアップ領域 ・・・ ある時点のバックアップ バックアップ以降の連続したWALファイル 表
- 15. レプリケーションの仕組み ある時点のバックアップに変更履歴をリアルタイムに適用 基本的な考え方はリカバリと同じ WAL送受信用のプロセスが起動(≠ファイル単位のコピー) Japan PostgreSQL User's Group 15 変更履歴を順次適用するレプリケーション startup WALを送信 WALを要求 recovery.conf ーーーーーーーー ※起動時に存在すると startupプロセスによる リカバリモードで起動 ・standby_mode = on ・primary_conninfo = マスターへの接続情報 参照・更新 参照のみ WAL適用 （リカバリ） wal sender wal reciever
- 16. レプリケーションの仕組み スタンバイが停止した場合の問題 受信者がいない変更履歴をいつまで貯める？ 無限に持つ ：ディスク容量を消費 一定量で削除：復旧後に変更履歴が繋がらない レプリケーションスロットで、適用済みの（不要な） WALを判断し、自動で削除することができる Japan PostgreSQL User's Group 16 レプリケーションスロットを使ったスタンバイの状態管理 startup WALを送信 WALを要求 参照・更新 参照のみ wal sender wal reciever slot xxx番まで 適用完了したよ
- 18. デモ環境 PostgreSQLのインストール（両ノードで実施） データベース作成（プライマリのみ） Japan PostgreSQL User's Group 18 2台のCentOSにyumでPostgreSQL 10.0を導入済み $ sudo yum install wget $ wget https://download.postgresql.org/pub/repos/yum/testing/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm $ sudo rpm -ivh pgdg-centos10-10-2.noarch.rpm $ sudo yum install postgresql10 postgresql10-server postgresql10-contrib postgresql10-devel $ sudo vi /usr/lib/systemd/system/postgresql-10.service $ su - postgres $ vi .bash_profile $ sudo systemctl start postgresql-10.service $ sudo systemctl status postgresql-10.service $ su – postgres $ createuser -d -r -l -P demo $ createdb -O demo demodb # Location of database directory # Environment=PGDATA=/var/lib/pgsql/10/data/ Environment=PGDATA=/home/postgres/data/ ### edit for PostgreSQL10 export PGDATA=/home/postgres/data export PATH=/usr/pgsql-10/bin:.:$PATH サンプルテーブルも作成 $ psql -U demo demodb demodb=> create table sample (a int,b text); demodb=> insert into sample values (1,'test1');
- 19. プライマリ側の設定 ユーザー作成 $PGDATA/pg_hba.confの編集 Japan PostgreSQL User's Group 19 ①レプリケーション用のユーザーを作成 $ createuser --replication rep_user $ vi $PGDATA/pg_hba.conf TYPE DB USER CIDR-ADDRESS METHOD host replication rep_user 192.168.10.0/24 trust host all rep_user 0.0.0.0/0 reject
- 20. プライマリ側の設定 $PGDATA/postgresql.confの編集 Japan PostgreSQL User's Group 20 ②レプリケーション用のパラメータ設定 $ vi $PGDATA/postgresql.conf パラメータ 設定 説明 listen_addresses * （通常はDB作成後にほぼ必須で実施） wal_level replica レプリケーションに必要なWAL情報を生成 max_wal_senders 10 起動可能なwal senderプロセスの上限 max_replication_slots 10 作成可能なレプリケーションスロットの上限 synchronous_standby_names 任意 同期スタンバイの名前を指定 synchronous_commit on 同期レベルを指定 hot_standby on 自身がスタンバイの時に参照可能とする hot_standby_feedback on 自身の情報をプライマリに送信 wal sender slot ※ここまで進んだら再起動しておく $ sudo systemctl start postgresql-10.service
- 21. プライマリ側の設定 $PGDATA/recovery.conf.node1の作成 Japan PostgreSQL User's Group 21 ③自身がスタンバイになる際のrecovery.confを作成 $ vi $PGDATA/recovery.conf.node1 パラメータ 設定 説明 standby_mode on 起動時にスタンバイモードになる primary_conninfo プライマリへの接続情報 primary_slot_name slot2 プライマリのレプリケーションスロット名 recovery_target_timeline latest 最新のマスターに追従する設定 wal reciever host port user application_name node2 5432 rep_user node1 wal sender slot2 recovery.conf 自身がスタンバイになる際の 相手への接続情報
- 22. スタンバイの作成 pg_basebackupで＄PGDATA配下を一括取得 Japan PostgreSQL User's Group 22 ①プライマリのバックアップを取得 $ pg_basebackup -U rep_user -h <node1_ip> -p 5432 -D /home/postgres/data $ ls -ltr $PGDATA drwx------. 3 postgres postgres 60 Oct 28 15:44 pg_wal drwx------. 6 postgres postgres 54 Oct 28 15:44 base drwx------. 2 postgres postgres 4096 Oct 28 15:44 global drwx------. 2 postgres postgres 32 Oct 28 15:44 log -rw-------. 1 postgres postgres 22844 Oct 28 15:44 postgresql.conf -rw-------. 1 postgres postgres 88 Oct 28 15:44 postgresql.auto.conf -rw-rw-r--. 1 postgres postgres 169 Oct 28 15:44 recovery.conf.node1 -rw-------. 1 postgres postgres 4760 Oct 28 15:44 pg_hba.conf pg_hba.conf postgresql.conf recovery.conf.node1 pg_basebackup pg_hba.conf postgresql.conf recovery.conf.node1 ※slot以外をコピー
- 23. スタンバイの作成 $PGDATA/recovery.confを作成 Japan PostgreSQL User's Group 23 ②recovery.confを作成（コピーしたものを編集） $ cp $PGDATA/recovery.conf.node1 $PGDATA/recovery.conf.node2 $ vi $PGDATA/recovery.conf.node2 $ cp $PGDATA/recovery.conf.node2 $PGDATA/recovery.conf wal reciever pg_hba.conf postgresql.conf recovery.conf.node1 パラメータ 設定 説明 standby_mode on 起動時にスタンバイモードになる primary_conninfo プライマリへの接続情報 primary_slot_name slot1 プライマリのレプリケーションスロット名 recovery_target_timeline latest 最新のマスターに追従する設定 host port user application_name node1 5432 rep_user node2
- 24. スタンバイ側の設定 プライマリでレプリケーションスロットを作成 systemctlでスタンバイを起動 Japan PostgreSQL User's Group 24 ③スタンバイを起動 $ sudo systemctl start postgresql-10.service $ su - postgres $ ps x 11089 ? Ss 0:00 /usr/pgsql-10/bin/postmaster -D /home/postgres/data/ 11093 ? Ss 0:00 postgres: startup process recovering 000000010000000000000005 11097 ? Ss 0:00 postgres: wal receiver process streaming 0/5000140 : wal reciever recovery.conf wal sender slot1 WALを送信 WALを要求 $ su - postgres $ psql -h <node1_ip> -U postgres postgres postgres=# select pg_create_physical_replication_slot('slot1');
- 25. デモ プライマリを正常停止 スタンバイを新プライマリに昇格 旧プライマリを新スタンバイとしてクラスタに参加 Japan PostgreSQL User's Group 25 スイッチオーバー $ su - postgres $ pg_ctl promote $ psql -U postgres postgres postgres=# select pg_create_physical_replication_slot('slot2'); $ sudo systemctl stop postgresql-10.service $ su - postgres $ cp $PGDATA/recovery.conf.node1 $PGDATA/recovery.conf $ exit $ sudo systemctl start postgresql-10.service $ su - postgres $ psql -U postgres postgres postgres=# select pg_drop_replication_slot('slot1'); -- 旧スロットを削除
- 26. デモ スタンバイを強制的に新プライマリに昇格 旧プライマリを停止、削除 「スタンバイの作成」からやり直し 新プライマリのバックアップ取得 recovery.confは上記でコピーしておいたものを再利用 新スタンバイを起動 Japan PostgreSQL User's Group 26 フェイルオーバー $ su - postgres $ pg_ctl promote $ psql -U postgres postgres postgres=# select pg_create_physical_replication_slot('slot1'); $ sudo systemctl stop postgresql-10.service $ su - postgres $ cp $PGDATA/recovery.conf.node2 /home/postgres/recovery.conf.node2 $ rm -rf $PGDATA
- 27. 想定Q&A Japan PostgreSQL User's Group 27 今日のデモ＋どこまでやれば実用レベルになる？ Question Answer 基本の作り方はわかったけど、 この後どうしたら実用レベルになるの？ ・レプリ関連パラメータを全部ちゃんと読みこむ ・pg_hba.confやpostgresql.confはちゃんと設定する （レプリ関連では本資料で紹介したものでOK） ・フェイルオーバー/スイッチオーバーをたくさん練習する フェイルオーバー後はバックアップから 取り直し？ その通り。バックアップの取り直しが必要 上記の「練習」でリアルな所要時間まで把握すること pg_rewindを使えると救えるケースもある（要事前設定） 完全同期レプリケーションが出来るって 聞いたんだけど ※完全同期=スタンバイで参照した 結果がマスターと完全に同じ 完全同期、準同期（2段階）、非同期が選択可能 以下の2つのパラメーターの組合せで指定する ・synchronous_commit ・synchronous_standby_names フェイルオーバーの自動化はできる？ Pgpool-IIやpacemakerなどのツールと組み合わせて実現 主に「死活監視」「マスター昇格or障害ノード切り離し」 「仮想IPなどを制御しアプリの向き先変更」の要素が必要 ロジカルレプリケーションが出来るって 聞いたんだけど PostgreSQL10からロジカルレプリケーションが可能 WALベースであることは同じだが、設定方法や用途は異なる テーブル単位で作成する
- 28. 【T4】PostgreSQLレプリケーション Japan PostgreSQL User's Group 28 セッションテーマ 安定稼働を使命とするデータベースでは、障害が発生した場合もすぐに再稼働で きるよう様々な工夫を凝らして設計されます。このような高可用システムを実現 する機能としてPostgreSQLではレプリケーションが用いられます。 まとめ システムを構成する機器は故障しうることを前提に対策をするべき。 常に更新されているデータベース層を守るには、リアルタイムに 変更履歴を伝播する「レプリケーション」が簡単・確実 startup WALを送信 WALを要求 参照・更新 参照のみ WAL適用 （リカバリ） wal sender wal reciever