[pgsql-jp: 41435] Re: ストリーミング・レプリケーションでデータの同期が行われなくなった
Keiji Yoshida
k.yoshida @ onemore.co.jp
2013年 6月 17日 (月) 20:58:19 JST
Suzuki様
吉田です。
ありがとうございます。
>pcp_node_infoコマンドで、2台のpgpool-IIの状況を調べてみては?
>例えば、それぞれのpgpool-IIが稼働しているサーバ上で、以下のコマンドを実 行するとか。
># pcp_node_info 10 server port user password 0
># pcp_node_info 10 server port user password 1
上記コマンドを実行したところ、アプリケーションサーバ2号機のノード番号0のみステータスが「3:ダウン」でした。
(他は全て「2:稼働中接続あり」でした。)
#このノードが原因で、今回のslaveの昇格が発生したのでしょうか?
これから、問題のノードを切り離した上、再度ノード追加を行います。
データ復旧は、おっしゃる通りですね。
今回は、手作業でデータ復元、シーケンスの調整を行おうと思います。
吉田
On 2013/06/17, at 20:27, Suzuki Hironobu <hironobu @ interdb.jp> wrote:
> 16日16:03に、slaveがマスタに昇格してしまったようですね。
> #WALログの番号と生成時刻にちょっと疑問が残りますが…
>
>
> pcp_node_infoコマンドで、2台のpgpool-IIの状況を調べてみては?
> 例えば、それぞれのpgpool-IIが稼働しているサーバ上で、以下のコマンドを実 行するとか。
> # pcp_node_info 10 server port user password 0
> # pcp_node_info 10 server port user password 1
>
> 故障の原因がわかるかもしれません。
>
>
>
> データの復旧は、データの内容に依存すると思います。
>
> SNSの投稿のように(文章を投稿時刻でソートすればよいなど)データ間でコンフ リクトが起きないと保証できているのなら機械的にできるかもしれ ませんが、 普通は(ツールを作るなどふくめ)手作業でデータを突き合わせることになると思 います。
>
>
>
> On 2013年06月17日 20:02, Keiji Yoshida wrote:
>> Suzuki様
>>
>> 吉田です。
>> ご返信くださいましてありがとうございます。
>>
>> 以下、ご回答差し上げます。
>>
>> >Railsはpgpool-IIに更新系SQL+検索系SQLどちらも発行しているのでしょうか?
>> >それとも直接PostgreSQLにアクセスする場合もあるのでしょうか?
>>
>> pgpool-IIに更新系SQL+検索系SQLどちらも発行しています。
>> 直接PostgreSQLにアクセスする場合はございません。
>>
>> >pgpool-IIは1台だけ稼働でしょうか?
>> >pgpool-IIは(レプリケーションモードではなく)「マスタースレーブモード」で 稼働しているのでしょうか?
>>
>> アプリケーションサーバが2台あり、pgpool-IIが各サーバ上で1本ずつ動いています。
>> pgpool-IIは「マスタースレーブモード」で 稼働しています。
>>
>>
>> >(2)slaveサーバのデータベースクラスタに
>> >recovery.confもしくはrecovery.doneというファイルはあるでしょうか?
>>
>> ございます。
>> #自動的にリカバリが走った、ということでしょうか?
>>
>> >(3)masterとslaveの,以下のディレクトリの中身(存在するファイル名)を知るこ とはできるでしょうか?
>> >ls pg_xlog
>> >ls pg_xlog/archive_status
>>
>> 下記の通りです。
>> =============================================================================
>> ★ masterのpg_xlog
>> drwx------ 2 postgres postgres 4096 7月 23 14:10 2012 archive_status
>> -rw------- 1 postgres postgres 16777216 6月 12 08:13 2013 000000010000000000000049
>> -rw------- 1 postgres postgres 16777216 6月 17 18:09 2013 00000001000000000000004A
>> -rw------- 1 postgres postgres 16777216 6月 17 19:58 2013 000000010000000000000048
>>
>> ★ masterのpg_xlog/archive_status
>> (なし)
>>
>> ★ slaveのpg_xlog
>> -rw------- 1 postgres postgres 16777216 6月 12 08:13 2013 000000010000000000000048
>> -rw------- 1 postgres postgres 16777216 6月 16 15:58 2013 000000010000000000000047
>> -rw------- 1 postgres postgres 56 6月 16 16:03 2013 00000002.history
>> drwx------ 2 postgres postgres 4096 6月 16 16:03 2013 archive_status
>> -rw------- 1 postgres postgres 16777216 6月 16 16:03 2013 000000020000000000000048
>> -rw------- 1 postgres postgres 16777216 6月 17 19:53 2013 000000020000000000000047
>>
>> ★ slaveのpg_xlog/archive_status
>> -rw------- 1 postgres postgres 0 6月 16 16:03 2013 00000002.history.ready
>> =============================================================================
>>
>> 以上、何卒よろしくお願い申し上げます。
>>
>> 吉田
>>
>>
>> On 2013/06/17, at 19:49, Suzuki Hironobu<hironobu @ interdb.jp> wrote:
>>
>>> こんにちは
>>>
>>>
>>> (1)この説明が気になるので、念のため確認ですが:
>>>
>>>> 更新系SQLは、両方のサーバへ発行される構造となっておりましたため、
>>> Railsはpgpool-IIに更新系SQL+検索系SQLどちらも発行しているのでしょうか?
>>> それとも直接PostgreSQLにアクセスする場合もあるのでしょうか?
>>>
>>> ついでに確認ですが、
>>> pgpool-IIは1台だけ稼働でしょうか?
>>> pgpool-IIは(レプリケーションモードではなく)「マスタースレーブモード」で 稼働しているのでしょうか?
>>>
>>>
>>> (2)slaveサーバのデータベースクラスタに
>>> recovery.confもしくはrecovery.doneというファイルはあるでしょうか?
>>>
>>>
>>> (3)masterとslaveの,以下のディレクトリの中身(存在するファイル名)を知るこ とはできるでしょうか?
>>> ls pg_xlog
>>> ls pg_xlog/archive_status
>>>
>>>
>>> 以上、よろしくお願いします。
>>>
>>>
>>>
>>> On 2013年06月17日 19:23, Keiji Yoshida wrote:
>>>> 朝倉様
>>>>
>>>> 吉田です。
>>>> お世話になります。
>>>>
>>>> 先ほどのメールに追記させて頂きます。
>>>>
>>>> >②Master側で、「SELECT * FROM pg_stat_replication」を実行して、
>>>> >レプリケーションの状態を確認する
>>>> >といった調査方法があると思います。
>>>>
>>>> Master、Slaveの両方で「SELECT * FROM pg_stat_replication」を実行したところ、
>>>> どちらもレコードが存在しませんでした。(0件の結果が返却されました。)
>>>>
>>>> #レプリケーションの状態が解除されてしまっている、ということでしょうか?
>>>>
>>>> 吉田
>>>>
>>>>
>>>> On 2013/06/17, at 19:11, Keiji Yoshida<k.yoshida @ onemore.co.jp> wrote:
>>>>
>>>>> 朝倉様
>>>>>
>>>>> 吉田です。
>>>>> ご返信くださいまして、誠にありがとうございます。
>>>>>
>>>>> >DBサーバは2台で構成され、1台がMaster、もう1台がSlaveで、
>>>>> >ストリーミングレプリケーションを組んでいた、
>>>>> >であっていますか?
>>>>>
>>>>> はい、おっしゃる通りです。
>>>>> アプリケーションサーバからは、pgpool-II(マスタースレーブモード)経由でデータベースサーバへアクセスしております。
>>>>>
>>>>>
>>>>> >更新系SQLは、両方のサーバへ発行される構造となっておりましたため、
>>>>> >この部分が分かりません。
>>>>> >ストリーミングレプリケーション + ホットスタンバイの構成だと、
>>>>> >そもそもSlave側は参照専用で、更新はMaster側にだけしか
>>>>> >発行できないのですが。。。
>>>>>
>>>>> そもそもMasterへしか発行されないはずの更新系SQLが、現在はSlaveへも発行されるようになってしまっております。
>>>>>
>>>>> このようなことになってしまったことの原因を突き止めようしておりますが、調査に苦戦している状況でございます。
>>>>>
>>>>> ご多用のところ大変恐縮でございますが、何卒よろしくお願い申し上げます。
>>>>>
>>>>>
>>>>> 吉田
>>>>>
>>>>>
>>>>> On 2013/06/17, at 18:57, 朝倉 佑貴<asakura.yuuki @ nttcom.co.jp> wrote:
>>>>>
>>>>>> 朝倉と申します。
>>>>>>
>>>>>> サーバ構成がよくわからないので、教えてください。
>>>>>> DBサーバは2台で構成され、1台がMaster、もう1台がSlaveで、
>>>>>> ストリーミングレプリケーションを組んでいた、
>>>>>> であっていますか?
>>>>>>
>>>>>>
>>>>>>> 更新系SQLは、両方のサーバへ発行される構造となっておりましたため、
>>>>>> この部分が分かりません。
>>>>>> ストリーミングレプリケーション + ホットスタンバイの構成だと、
>>>>>> そもそもSlave側は参照専用で、更新はMaster側にだけしか
>>>>>> 発行できないのですが。。。
>>>>>>
>>>>>>
>>>>>> Master側に発行した更新が、Slave側に反映されなくなった、
>>>>>> ということなら、Slave側がpromoteされてしまった可能性を
>>>>>> 考えます。
>>>>>>
>>>>>> この線で調査するなら、
>>>>>> ①それぞれのサーバで、「pg_controldata<PGDATA>」を実行して、
>>>>>> TimeLineIDを確認する
>>>>>> ②Master側で、「SELECT * FROM pg_stat_replication」を実行して、
>>>>>> レプリケーションの状態を確認する
>>>>>> といった調査方法があると思います。
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> (2013/06/17 18:25), Keiji Yoshida wrote:
>>>>>>> 吉田と申します。
>>>>>>> お世話になります。
>>>>>>> 初めて投稿させて頂きます。
>>>>>>>
>>>>>>> 現在、Rails+PostgreSQL(9.1.4)で構築されたWEBアプリケーションを、約半年間運用しています。
>>>>>>>
>>>>>>> DBサーバは2台あり、ストリーミング・レプリケーションでデータの同期を行っています。
>>>>>>>
>>>>>>> 今までは問題なかったのですが、昨日急に、サーバ間でのデータの同期が行われなくなってしまいました(片方のサーバのみデータが更新される状態となってしまいました)。
>>>>>>> 更新系SQLは、両方のサーバへ発行される構造となっておりましたため、
>>>>>>> あるデータは1号機のみに存在し、またあるデータは2号機のみ存在するという、どちらのDBサーバも、独自のデータを抱える状態となってしまいました。
>>>>>>>
>>>>>>> どちらのDBサーバへ発行されたSQLも正常終了しているため、両方ともPostgreSQLのプロセスは正常に稼働していると認識しています。
>>>>>>>
>>>>>>> 現在、以下の不明点を抱えております。
>>>>>>>
>>>>>>> (1)なぜ同期できなくなったのか?
>>>>>>> (2)どのように同期処理を再開させるか?
>>>>>>> (3)どのようにデータを復旧させるか?
>>>>>>>
>>>>>>> 上記不明点の解消を試みておりますが、どのように調査を進めたら良いかが分からず、作業が止まっている状態です。
>>>>>>>
>>>>>>> 「こう調査すべき」、「このログを確認すべき」、「このようなことが原因として考えられるため、この点を確認すべき」など、もし考えられる点がございましたら、お知恵をお借りできませんでしょうか?
>>>>>>>
>>>>>>> お忙しいところお手数おかけ致しますが、何卒よろしくお願い申し上げます。
>>>>>>>
>>>>>>> 吉田
>>>>>>>
>>>>>>>
>
pgsql-jp メーリングリストの案内