[pgsql-jp: 41803] Re: Replication状態について

2015年 7月 10日 (金) 10:51:21 JST

海藤さん

こんにちは。

PostgreSQLのStreaming Replicationって、WALを送って同期を取っているのは、ご理解してられますよね。
最初に質問されてた、 sent_location,write_location,flush_location,replay_locationで管理されてます。順に、マスタが送ったWAL番号、スタンバイが書き込んだWAL番号、スタンバイのディスクに出力されたWAL番号、スタンバイ側で再生されたWAL番号です。
つまり、スタンバイ側には、マスタ側での更新順に変更が送られてスタンバイ側でその変更を再生しているので、変更の途中が抜けるというのは、ないのです。
Standby2が処理の途中でエラーになってるのだとしたら、それは回復できないかもしれません。すでに、レプリケーションの問題ではないのではないでしょうか？
レプリケーションが正しく動作していたら、 Standby2がsent_location が2000で replay_locationが1998の状態でStandby1がダウンしても、Standby2は replay_locationが2000まで問題なく進みますよということを言ってます。

海藤 廣一 <kaidou.hirokazu ＠ jp.panasonic.com>: 

>海藤です。
>いつもお世話になっております。
>コメントありがとうございます。
>
>少々イレギュラー的な話になると思うのですが、レプリケーション
>の動作について教えてください。
>サーバー構成を
>・Master
> （synchronous_commit=on、synchronous_standby_names="Standby1,Standby2"）
>・Standby1（同期）
>・Standby2（非同期）
>で動作中にクライアントからのデータ書き込みが数千回の間に
>100回目あたりでStandby2へのStreaming書き込みが失敗していたとして
>（Standby1は同期なので当然成功している）2000回目位にStandby1が
>ダウンするとStandby2が非同期⇒同期にシフトして2000回前後の
>書き込みデータは当然同期されるものと思いますが、過去に失敗
>していた100目のデータも”時間の問題”で”遡って同期”してくれ
>るのでしょうか？
>
>上記の通り過去に非同期で動作していた間に受け取り損ねた又は
>WAL書き込み失敗したデータも遡って同期してくれるならStandby2
>の導入は”非常に有効な手段”になりますので是非検討したいと
>思います。
>
>> 　レプリケーションをする目的は何ですか？何が一番大事かを明確にすることが
>> 必要だと思います。
>
>Debian+PostgreSQLでレプリケーションを行うという時点で
>コストを抑えた中で最善策を模索しているということは
>ご理解いただけるのではないでしょうか？
>
>> 　非同期でレプリケーションを行うのなら、マスタがダウンしたときに、スタン
>> バイが同期した状態にあることは期待できないと思います。
>
>レプリケーション状態の監視という観点でご相談させていただいて
>おりますが、別途Pacemaker+Corosync（又はHeartbeat）でクラスタ
>リングも検討しております。こちらで上手くいけば
>○定常状態では同期レプリケーション
>○スタンバイがダウンしたらマスターは非同期のつもり
>○マスターがダウンした際はスタンバイがマスターへのフェイルオーバー
>という動作をしてくれるものと思ってます。
>
>いずれにしてもどれかがダウンしたらASAPで復旧作業は必要なので
>監視する必要があり、クラスタリング導入前に有効な監視方法を
>検討中というのが現段階です。
>
>以上です。
>
>On Thu, 09 Jul 2015 20:53:17 +0900
>shige ＠ kobe.email.ne.jp wrote:
>
>> 海藤さん
>> 
>> 　こんばんは。
>> 
>> > 同期レプリケーションで動作中のスタンバイサーバがダウンした
>> > 場合を考慮すると非同期で動作している（２台目以降の）データ
>> > がマスターと一致しているかどうかが重要になってきます。
>> 　synchronous_standby_namesにスタンバイサーバを列挙すると、1台目のsyncス
>> タンバイサーバがダウンした折には、2台目のpotentialサーバがsyncサーバにな
>> ります。potentialからsyncになった時点で完全に同期できていなくても、時間の
>> 経過により同期することになります。
>> 
>> 　どれだけのデータを溜め込んで、どれだけの頻度でデータが追加・更新するか
>> 分からないのですが、通常の運用において、スタンバイサーバがマスタサーバの
>> 更新に追いついてない状況が発生することは(運用の仕方により)ありえますし、
>> それは時間が解決する(サーバの負荷が下がり、同期する)ものだと思います。
>> 
>> 　レプリケーションをする目的は何ですか？何が一番大事かを明確にすることが
>> 必要だと思います。
>> 
>> 　非同期でレプリケーションを行うのなら、マスタがダウンしたときに、スタン
>> バイが同期した状態にあることは期待できないと思います。
>> 
>> 海藤 廣一 <kaidou.hirokazu ＠ jp.panasonic.com>さん：
>> > Ｔｏ：石橋様
>> > Ｃｃ：PostgreSQLメーリングリスト会員様
>> > 
>> > 海藤です。
>> > いつもお世話になっております。
>> > 早速のコメントありがとうございます。
>> > 
>> > スタンバイサーバを複数にした場合、コストアップになるので
>> > コストアップを避けたいというのが一番の理由ですが、
>> > 同期レプリケーションで動作中のスタンバイサーバがダウンした
>> > 場合を考慮すると非同期で動作している（２台目以降の）データ
>> > がマスターと一致しているかどうかが重要になってきます。
>> > 
>> > 現在考えている方法としては
>> > ①pg_stat_replicationビュー等で差分検出が確認できるなら、
>> > 　自動ないし手動でBasebackupを取り直してデータを一致させる。
>> > ②pg_stat_replicationビュー等で差分がないはずの状態におい
>> > 　ても１回／月（又は週）程度はテーブル内容をチェックして
>> > 　もし差分が検出されたら（程度にもよりますが）Basebackupを
>> > 　取り直してデータを一致させる。
>> > ③マスター又はスタンバイサーバのどちらかがダウンした際には
>> > 　ASAP（現実的には１Ｗ以内位）でダウンしたサーバの復旧作業
>> > 　にあたる。
>> > 
>> > 上記に致命的なところ、又はもっとこうした方が良いと言う
>> > アドバイスを頂けると助かります。
>> > 
>> > 以上です。
>> > 
>> > 
>> > On Wed, 08 Jul 2015 18:38:24 +0900
>> > 石橋 茂政 / ISHIBASHI,Shigemasa <shige ＠ kobe.email.ne.jp> wrote:
>> > 
>> > > 海藤さん、こんにちは。
>> > > 
>> > > 問題なく同期が取れていても、一時的にそこの値が違うことはありえると思
>> います。
>> > > 
>> > > スタンバイサーバを複数台準備して、synchronous_commit=onにして、
>> synchronous_standby_namesに複数台指定するという方法は取れないですか？
>> > > 
>> > > 海藤 廣一 <kaidou.hirokazu ＠ jp.panasonic.com>: 
>> > > 
>> > > >PostgreSQLメーリングリスト会員様
>> > > >
>> > > >海藤と申します。
>> > > >いつもお世話になっております。
>> > > >
>> > > >下記環境でStreamingReplicationにより二重化した
>> > > >データベースを構築しようとしております。
>> > > >
>> > > >[環境]
>> > > >OS:Debain7.8
>> > > >DB:PostgreSQL 9.1
>> > > >
>> > > >そこで、マスター側でpg_stat_replicationビューを
>> > > >確認することでreplication状態を確認できるのですが、
>> > > >このビューでマスターとスタンバイで差異が出ていないか
>> > > >確認することは出来るのでしょうか？
>> > > >
>> > > >例えば
>> > > >sent_location,write_location,flush_location,replay_location
>> > > >の値が全て同じ場合は差異が出ていないとか、
>> > > >
>> > > >スタンバイ側のサーバーに障害が出た場合に、マスター側が
>> > > >一時的にSQLの応答不能になるのを防ぐ目的で
>> > > >synchronous_commit = local
>> > > >で動作させることを想定している為、逆にスタンバイのデータが
>> > > >マスターと同じかどうかを確認する必要が出てしまっています。
>> > > >
>> > > >常時監視をしたいので簡単に確認できる方法がありましたら
>> > > >アドバイス願います。
>> > > >
>> > > >以上です。
>> > > >
>> > > >
>> > 
>> > 
>> > 
>> > ===================================================
>> >  パナソニック システムネットワークス株式会社
>> >  インフラシステム事業部
>> >  システムプロダクト部  プロダクト技術課
>> >  海藤 廣一
>> >  E-mail:kaidou.hirokazu ＠ jp.panasonic.com
>> >  TEL:050-3686-3682       内線:7-375-8945
>> > ===================================================
>> 
>> 
>> ---
>> いしばし　しげまさ
>
>
>
>===================================================
> パナソニック システムネットワークス株式会社
> インフラシステム事業部
> システムプロダクト部  プロダクト技術課
> 海藤 廣一
> E-mail:kaidou.hirokazu ＠ jp.panasonic.com
> TEL:050-3686-3682       内線:7-375-8945
>===================================================
>