Takatoshi MATSUO
matsu****@gmail*****
2013年 11月 19日 (火) 22:42:34 JST
松島さん お久しぶりです。松尾です。 2013年11月19日 19:19 Takehiro Matsushima <takeh****@gmail*****>: > 中平さん > > いつもOSCではお世話になっております。 > 大変わかり易いご説明を賜り、ありがとうございます。 > > おおかた理解できましたが、疑問がわいてきました。 > > pgsql RAの中で synchronous_standby_names の指定を 1node 分に限定していましたが、 > 「Sync Slave以外はAsync Slaveとなる」ため、「recovery.confにもあえて書き出していない」 > との理解で宜しいでしょうか。 「recovery.confにもあえて書き出していない」ではなく、データロスが発生するため 「recovery.confにはわざと書き出していない」が正解になります。 元々は書き出していたのですが、以下のパッチで書き出さないように変更されました。 https://github.com/ClusterLabs/resource-agents/commit/55494b5052f540030938733ec4729cc37ac64a8c なぜデータロスが発生するかは、以下に少し解説がありますので、 https://github.com/t-matsuo/resource-agents/issues/24 これをベースに解説すると以下のような場合です。 --------------------------------------------------------- 以下3つのノードがあるとします。 node1 : Master (PRI) node2 : Slave (HS:sync) node3 : Slave (HS:potential) node2のレプリケーションのネットワークダウンが発生したとします。 -> node1のPostgreSQLはnode3がいるので、node3を自動的にsyncに昇格させて、 コミットOKをクライアントに返します。 -> しかしPacemakerはまだnode2がsync、node3がpotentialと思っています。 このタイミングでnode1がダウンしたとします。 -> Pacemakerは、sync 状態と思っている node2 を promoteしてしまいます。 -> 結果データロスが発生。 --------------------------------------------------------- recovery.conf に1ノードしか書き出さないようにすると、node2 が ダウンした場合、PostgreSQLのコミットの応答が返らないため、 この時にnode1が故障しても、データロスを防ぐことができます。 > > PacemakerをかませずにSRを使った場合、StatusにはSync/Potential/Asyncの3種類があると > 思いますが、pgsql RAではSync/Asyncしか目にしないものですから... > > よろしくお願いいたします。 > > > 2013年11月19日 14:02 NAKAHIRA Kazutomo <nakahira_kazutomo_b1****@lab*****>: >> TO：松島さん >> >> 中平です。前回のOSC東京ではお世話になりました。 >> >> PostgreSQLのストリーミングレプリケーションで、sync状態の >> Slaveが 1つである理由ですが、以下の MLでのやりとりに >> 書かれています。 >> >> http://www.gossamer-threads.com/lists/linuxha/pacemaker/85077?do=post_view_threaded#85077 >> >> 確か同期レプリケーションの場合、Master側が受け付けた >> DB書き込み結果をクライアント側に返却するタイミングが、 >> Master側の synchronous_standby_names の先頭に記述 >> された Slaveから応答が返されたときになるかと思います。 >> # 全ての Slaveからの応答を待ってはいなかったと思いますが >> # もし間違っていればご指摘ください。 >> >> このため、synchronous_standby_names の先頭に記述された >> Slaveについては同期が保証されますが、その他の Slaveに >> ついては、きちんと WALが転送されたことが保障されない >> まま Masterからクライアントに応答が返されてしまいます。 >> >> そのため、synchronous_standby_names の先頭に記述された >> Slaveのみが "Sync Slave"として信用することができ、 >> その他は "Async Slave"の扱いになる、と理解しています。 >> >> 以上です。 >> よろしくお願い致します。 >> >> (2013/11/18 23:02), Takehiro Matsushima wrote: >>> 皆様 >>> >>> お世話になっております、松島と申します。 >>> この度、皆様に教えていただきたいことが御座います。 >>> >>> PostgreSQL9.3 + Pacemaker, Corosync(Nightly)で実験を行っています。 >>> >>> 3ノード構成で、ストリーミングレプリケーションを使ってMaster/Slave構成で >>> 同期レプリケーションを行いたいのですが、実際の動作もpgsql RAの記述も >>> 1 Master + 1 Sync Slave + 1 Async Slaveとなっています。 >>> >>> 1 Master + 2 Sync Slaveではなにか問題があるためにこのような動きを >>> するようにしているように見えるのですが、この背景につきまして、なにか >>> ご存知の方いらっしゃいましたら教えて頂けますでしょうか。 >>> >>> 恥ずかしながら、見当がつきませんでしたので、よろしくお願いいたします。 >>> >> >> >> -- >> NTTデータ先端技術株式会社 >> 中平 和友 >> TEL: 03-5860-5135 FAX: 03-5463-6490 >> Mail: nakahira_kazutomo_b1****@lab***** >> >> _______________________________________________ >> Linux-ha-japan mailing list >> Linux****@lists***** >> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan > > > > -- > Regards, > Takehiro Matsushima > > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
Fork