[Postgre sql9.4新機能]レプリケーション・スロットの活用

第4回 PostgreSQLアンカンファレンス2014/09/06
9.4新機能
レプリケーション・スロットの使いどころ
株式会社アシスト　喜田紘介
Copyright © 2014 K.K.Ashisuto All Rights Reserved. 1

自己紹介
● 名前
● 喜田紘介(きだこうすけ)
● 所属
● 株式会社アシスト　データベース技術本部
● 日本PostgreSQLユーザ会　広報・企画担当
● 近況
● 仕事では、新規構築するシステムのDBをどうすべきか？というRDBMS選択支援や、
商用DBからOSSへの移行の前段階として、オブジェクトやSQL差異のレクチャーや、
データベースの診断・評価を行う移行アセスメント支援を主に担当しています。
● 2014年度より、JPUGの理事になりました。こちらもよろしくお願いします。
● この夏やりたいことやったこと
PG9.4の検証、マラソンとトライアスロンの練習、歌とギターの練習(初心者)

本日お話すること
● PostgreSQL 9.4で追加されたレプリケーション・スロットの概要
● レプリケーション・スロットに期待されること
● レプリケーション・スロットがあるとこう変わる！
● みなさんの意見をきかせてください

レプリケーション・スロットの概要
● レプリケーション・スロット
● 新しいDB内のオブジェクトでもあるし、レプリケーションスロットという考え方、ともとれる
● ストリーミング・レプリケーションのマスタ側に存在し、スレーブの状態を管理している
slot1
slot2
slot3
wal_sender
wal_reciever

止まってるな～
● スレーブの状態　とは？
● スレーブが生きているかどうか、転送がどこまで完了しているか
● スロットの先には、何らかのアプリケーション(それが、スレーブだったり、logical walを見る人)
slot1
slot2
slot3
wal_sender
wal_reciever
遅れてるな～
よし！正常！

レプリケーション・スロットに期待される効果
● logical_decodingを実現するための要素(9.4新機能)
● logical decodingは、walを読み取れる状態で吐く機能で、今後様々な拡張の基盤に　　
logical decodingは外部ツールに
データを渡せる機能なので
「誰」が「いつ」「何回」取りに来るかは
外部ツールの作り次第
update 給与 set 月給*1.1
where 喜田 ;
where 喜田 ;
where 喜田 ;
もっと
ちょーだい
え、さっき
ログスイッチ
しちゃった
泣
なるとされている。
● レプリケーション・スロットがあれば、postgres側で↓を発生させないようにできる。
● こんなlogical decodingはイヤだ
update 給与 set 月給*1.1 where 喜田 ;
ブラックボックスな
ツール
ぐへへ
もっと
俺も！僕もほしい
いや
俺でしょ
はい
どうぞ
しゃーないな
みんなにデータあげちゃう欲しいデータが消えちゃってる何度でもデータあげちゃう

レプリケーション・スロットに期待される効果
● これまでのストリーミング・レプリケーションの課題を解決
● レプリケーション競合の発生
● wal_keep_segments もしくはアーカイブ転送を考慮
②ロング
トランザクション
walファイル
wal_keep_seg分
まで持っておける
wal_sender
アーカイブファイル
最悪の場合に備え、
スタンバイに転送または領域を共有
ファイルコピー
など
①更新が伝搬
③vacuum ④vacuumも
　伝搬②’失敗！！！
レプリケーション競合walの消失に備えて対策を検討

ここまでは、マニュアルレベル
●従来の方法でもレプリケーションは
組むことができる。
●では、スロットの活用シーンは？
● logicalは、まだ実用段階ではないので
ここではストリーミングレプリを考えます。
● 競合の解消？他には？
● 皆さんの案もお聞きしたいです。

活用シーン1　複数台のスレーブがある場合(追記)
● wal_keep_segmentsの設定が困難なことが、きっとある
● もしくは、ホットスタンバイ用に全スレーブにアーカイブを転送する？
wal_sender
wal_reciever
貧弱なマシンだから
バッチとかの同期に
時間がかかる
この2台は同期が
追いついてるのに
walファイル
wal_keep_seg分
　　　　の都合によりwal_keep_segを多めに
設定しておかなければならない。最適値の検討が
けっこう大変。
アンカンファレンス参加者や、自身の経験でも、wal_keep_segmentsの
不適切な設定により必要なwalが消失し、レプリケーションが崩れていた
という問題が確認でき、このような点ではスロットが活きると考えられる。
2014/09/09追記

活用シーン2　遅延レプリケーションの場合(追記)
● 9.4の新機能で、レプリケーションの同期タイミングを遅らせることが可能
● 障害時、スレーブに障害が伝搬する前に対処が可能となるため、
バックアップとしての利用などが期待される
wal_sender
wal_reciever
遅延なしでレプリケーション
30分間の遅延を設定
walファイル
wal_keep_seg分
　　　　更新量にばらつきがある場合、walファイル
の数ではなく、30分という遅延時間内で必要とする
walが消失しないような管理機構が必要
＝>スロットで実現
遅延レプリケーションは、スレーブ側でWAL適用する際の設定であり、
マスターからスレーブに対するWAL転送までは遅延無く行われる。
つまり、本スライドに記載していたようなマスタ側でwal消失を防ぐことの
効果は薄く、遅延レプリケーション設定と、レプリケーション・スロットの
直接的な関連は少ないと考えられる。
2014/09/09追記
間違いなので注意！

1対1のレプリケーションの場合、どうする？
● 従来の方法でOK　(喜田の案)
● 最終的にアーカイブファイルでやり取りしていたほうが、安心感があるような。
● レプリケーション・スロットを使用した際のWALディレクトリの肥大化が問題になりそう。
● ただし、スロットの方が設定はシンプルのように見える。

wal_sender / wal_recieverの動作は変わる？(追記)
● どこまで送ったか、スロットに入ってはいるが。。。
● これまでのレプリケーションでは、recieverが次のwalを要求
● →senderが必要なwalを送る
● スロットは、必要なwalをpg_xlogに残しておくだけの設定であり、
sender/recieverの動きは変わらない？
正確な情報が確認でき次第、追記予定。
発表は以上です。ありがとうございました。
2014/09/09追記

[Postgre sql9.4新機能]レプリケーション・スロットの活用

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à [Postgre sql9.4新機能]レプリケーション・スロットの活用

Similaire à [Postgre sql9.4新機能]レプリケーション・スロットの活用 (20)

[Postgre sql9.4新機能]レプリケーション・スロットの活用