Movatterモバイル変換

PostgreSQLレプリケーション【T1】 SQLの基本【T2】 PostgreSQLチューニング【T3】データベース監視の基本【T4】 PostgreSQLレプリケーション解説PostgreSQL Conference Japan 2017 2017.11.3株式会社アシストデータベース技術本部日本PostgreSQLユーザ会喜田紘介

【T4】PostgreSQLレプリケーションJapan PostgreSQL User's Group 2 セッションテーマ安定稼働を使命とするデータベースでは、障害が発生した場合もすぐに再稼働できるよう様々な工夫を凝らして設計されます。このような高可用システムを実現する機能としてPostgreSQLではレプリケーションが用いられます。 内容、対象者PostgreSQLのレプリケーション機能の解説と、実機でレプリケーションを構築するデモをご覧いただきます。インフラ担当や高可用システムの設計を担当する方を対象に、PostgreSQLで何ができるかを解説します。株式会社アシスト日本PostgreSQLユーザ会理事喜田紘介氏入社時よりOracle Databaseの構築、運用、サポート等を経験。2011年よりPostgreSQLチームに所属し「EDB Postgres」担当としてユーザー自身で活用できるデータベースを目指して技術支援や情報発信に務めています。日本PostgreSQLユーザ会にも所属し、PostgreSQLやデータベース技術の普及に向けて積極的な活動を心がけています。

アジェンダデータベースの安定稼働について考えるデータベースをとりまくいろいろな「可用性」複製（レプリケーション）でDBの障害に備えようPostgreSQLのレプリケーション機能解説レプリケーション構築実践（デモ）Japan PostgreSQL User's Group 3

DBに期待する「安定稼働」アプリケーションの要求に対して結果を返すJapan PostgreSQL User's Group 4データベースに期待する機能とは？Click！DBへの問合せ

DBに期待する「安定稼働」アプリケーションの要求に対して結果を返すJapan PostgreSQL User's Group 5データベースに期待する機能とは？Click！DBへの問合せ応答がありませんサービスは年間●●時間しか停止できないという要件があり、データベースにアクセスできない状態（＝DBの障害）はその時間にさらに余裕を持たせ、対策されなければいけません。

DBに期待する「安定稼働」アプリケーションの要求に対して結果を返すJapan PostgreSQL User's Group 6データベースに期待する機能とは？Click！DBへの問合せ応答がありませんサービスは年間●●時間しか停止できないという要件があり、データベースにアクセスできない状態（＝DBの障害）はその時間にさらに余裕を持たせ、対策されなければいけません。可用性とは・年間で1日停止して良いシステム364日/365日=99.7%の稼働率・1時間しか停止を許さないシステム8759時間/8760時間=99.998%（99.999%なら約50分）

DBに期待する「安定稼働」複数のアプリケーションが共通のデータを利用Japan PostgreSQL User's Group 7もうひとつの可用性DBへの問合せ

DBに期待する「安定稼働」複数のアプリケーションが共通のデータを利用Japan PostgreSQL User's Group 8もうひとつの可用性DBへの問合せ一部分の障害に対して、他のサービスは継続して動き続けるように保つ。

複製（レプリケーション）システムの構成要素は必ず故障しうるものとして対策機器の二重化などではデータは？Japan PostgreSQL User's Group 9データベースの障害に備えるにはClick！DBへの問合せ?

複製（レプリケーション）システムの構成要素は必ず故障しうるものとして対策機器の二重化などではデータは？Japan PostgreSQL User's Group 10データベースの障害に備えるにはClick！DBへの問合せ? 複数のユーザーがリアルタイムに更新をかけ続けるDBは、完全に同じ状態の複製を用意することが難しい

複製（レプリケーション）システムの構成要素は必ず故障しうるものとして対策機器の二重化などではデータは？Japan PostgreSQL User's Group 11データベースの障害に備えるにはClick！DBへの問合せ全ての更新を担当するプライマリ（マスター）ノードプライマリから更新を受け取るスタンバイ（スレーブ）ノードPostgreSQLでは「ストリーミングレプリケーション」で実現

複製（レプリケーション）平常時の参照負荷分散数秒遅れでも構わないRead Onlyな処理アプリ側でスタンバイノードに問合せ障害時に新マスターに昇格データベースに対し「昇格」を指示アプリの向き先を変更仮想IPDNSの書き換えアプリの接続先修正Japan PostgreSQL User's Group 12「よくある」レプリケーションで実現できる機能参照・更新が可能参照のみ可能数秒のタイムラグを許容

アジェンダデータベースの安定稼働について考えるPostgreSQLのレプリケーション機能解説バックアップと変更履歴（WAL）について変更履歴を伝播するレプリケーションレプリケーションスロットレプリケーション構築実践（デモ）Japan PostgreSQL User's Group 13

前提知識リアルタイムなバックアップは難しい常に更新されるDBは「ある時点」のバックアップが前提バックアップ以降の更新を「変更履歴」として保持変更履歴を適用するリカバリの考え方Japan PostgreSQL User's Group 14バックアップと変更履歴（WAL）の役割を知っておく時間表表表UPDATE表表バックアップ領域・・・ある時点のバックアップバックアップ以降の連続したWALファイル表

レプリケーションの仕組みある時点のバックアップに変更履歴をリアルタイムに適用基本的な考え方はリカバリと同じWAL送受信用のプロセスが起動(≠ファイル単位のコピー)Japan PostgreSQL User's Group 15変更履歴を順次適用するレプリケーションstartupWALを送信WALを要求recovery.confーーーーーーーー※起動時に存在するとstartupプロセスによるリカバリモードで起動・standby_mode = on・primary_conninfo= マスターへの接続情報参照・更新参照のみWAL適用（リカバリ）wal sender wal reciever

レプリケーションの仕組みスタンバイが停止した場合の問題受信者がいない変更履歴をいつまで貯める？無限に持つ：ディスク容量を消費一定量で削除：復旧後に変更履歴が繋がらないレプリケーションスロットで、適用済みの（不要な）WALを判断し、自動で削除することができるJapan PostgreSQL User's Group 16レプリケーションスロットを使ったスタンバイの状態管理startupWALを送信WALを要求参照・更新参照のみwal sender wal recieverslotxxx番まで適用完了したよ

アジェンダデータベースの安定稼働について考えるPostgreSQLのレプリケーション機能解説レプリケーション構築実践（デモ）レプリケーションの作成自体はとても簡単実機でレプリケーションの動作を見てみましょうJapan PostgreSQL User's Group 17

デモ環境PostgreSQLのインストール（両ノードで実施）データベース作成（プライマリのみ）Japan PostgreSQL User's Group 182台の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 PostgreSQL10export PGDATA=/home/postgres/dataexport PATH=/usr/pgsql-10/bin:.:$PATHサンプルテーブルも作成$ psql -U demo demodbdemodb=> create table sample (a int,b text);demodb=> insert into sample values (1,'test1');

プライマリ側の設定ユーザー作成$PGDATA/pg_hba.confの編集Japan PostgreSQL User's Group 19①レプリケーション用のユーザーを作成$ createuser --replication rep_user$ vi $PGDATA/pg_hba.confTYPE DB USER CIDR-ADDRESS METHODhost replication rep_user 192.168.10.0/24 trusthost all rep_user 0.0.0.0/0 reject

プライマリ側の設定$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 senderslot ※ここまで進んだら再起動しておく$ sudo systemctl start postgresql-10.service

プライマリ側の設定$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 recieverhost port user application_namenode2 5432 rep_user node1wal senderslot2recovery.conf自身がスタンバイになる際の相手への接続情報

スタンバイの作成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 $PGDATAdrwx------. 3 postgres postgres 60 Oct 28 15:44 pg_waldrwx------. 6 postgres postgres 54 Oct 28 15:44 basedrwx------. 2 postgres postgres 4096 Oct 28 15:44 globaldrwx------. 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.confpg_hba.confpostgresql.confrecovery.conf.node1pg_basebackup pg_hba.confpostgresql.confrecovery.conf.node1 ※slot以外をコピー

スタンバイの作成$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.confwal recieverpg_hba.confpostgresql.confrecovery.conf.node1パラメータ設定説明standby_mode on 起動時にスタンバイモードになるprimary_conninfo プライマリへの接続情報primary_slot_name slot1 プライマリのレプリケーションスロット名recovery_target_timeline latest 最新のマスターに追従する設定host port user application_namenode1 5432 rep_user node2

スタンバイ側の設定プライマリでレプリケーションスロットを作成systemctlでスタンバイを起動Japan PostgreSQL User's Group 24③スタンバイを起動$ sudo systemctl start postgresql-10.service$ su - postgres$ ps x11089 ? Ss 0:00 /usr/pgsql-10/bin/postmaster -D /home/postgres/data/11093 ? Ss 0:00 postgres: startup process recovering 00000001000000000000000511097 ? Ss 0:00 postgres: wal receiver process streaming 0/5000140:wal recieverrecovery.confwal senderslot1WALを送信WALを要求$ su - postgres$ psql -h <node1_ip> -U postgres postgrespostgres=# select pg_create_physical_replication_slot('slot1');

デモプライマリを正常停止スタンバイを新プライマリに昇格旧プライマリを新スタンバイとしてクラスタに参加Japan PostgreSQL User's Group 25スイッチオーバー$ su - postgres$ pg_ctl promote$ psql -U postgres postgrespostgres=# 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 postgrespostgres=# select pg_drop_replication_slot('slot1'); -- 旧スロットを削除

デモスタンバイを強制的に新プライマリに昇格旧プライマリを停止、削除「スタンバイの作成」からやり直し新プライマリのバックアップ取得recovery.confは上記でコピーしておいたものを再利用新スタンバイを起動Japan PostgreSQL User's Group 26フェイルオーバー$ su - postgres$ pg_ctl promote$ psql -U postgres postgrespostgres=# 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

想定Q&AJapan 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ベースであることは同じだが、設定方法や用途は異なるテーブル単位で作成する

【T4】PostgreSQLレプリケーションJapan PostgreSQL User's Group 28 セッションテーマ安定稼働を使命とするデータベースでは、障害が発生した場合もすぐに再稼働できるよう様々な工夫を凝らして設計されます。このような高可用システムを実現する機能としてPostgreSQLではレプリケーションが用いられます。 まとめシステムを構成する機器は故障しうることを前提に対策をするべき。常に更新されているデータベース層を守るには、リアルタイムに変更履歴を伝播する「レプリケーション」が簡単・確実startupWALを送信WALを要求参照・更新参照のみWAL適用（リカバリ）wal sender wal reciever

Movatterモバイル変換

Change Language

PostgreSQLレプリケーション（pgcon17j_t4）

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to PostgreSQLレプリケーション（pgcon17j_t4）

More from Kosuke Kida

PostgreSQLレプリケーション（pgcon17j_t4）