Hi Masao. Thank you for suggestion. In deed that could occure. Most probably while I was testing split-brain situation. In that case I turned off network card on one node and on both nodes DRBD was in primary role. But after the split-brain occurred I resync DRBD so from two primaries I promoted one as "primary" (winner) and second one as "secondary" (victim). Data should be consistent by that moment. But probably it wasn't consistent. I am using DRBD only in one technical center. Data are syncing by streaming replication to the secondary technical center where is another DRBD instance. It's like this: TC1: --- node1: DRBD (primary), pgsql --- node2: DRBD (secondary), pgsql TC2: --- node1: DRBD (primary), pgsql --- node2: DRBD (secondary), pgsql Within one technical center only one pgsql runs only on one node. This is done by pacemaker/corosync. >From the outside perspective it looks like only one postgresql server is running in one TC. TC1 (master) ==== streaming replication =====> TC2 (slave) If one node in technical center fails, the fail-over to secondary node is really quick. It's because fast network within technical center. Between TC1 and TC2 there is a WAN link. If something goes wrong and TC1 became unavailable I can switch manually / automatically to TC2. Is there more appropriate solution? Would you use something else? Best regards, Michal Mistina On Mon, Aug 26, 2013 at 9:53 PM, Mistina Michal <Michal.Mistina@xxxxxxxx> wrote: > Hi there. > > I didn't find out why this issue happened. Only backup and format of > the filesystem where corrupted postmaster.pid file existed helped to > get rid of it. Hopefully the file won't appear in the future. I have encountered similar problem when I broke the filesystem by a double mount. You may have gotten the same problem. > Master/Slave Set: ms_drbd_pg [drbd_pg] > > Masters: [ tstcaps01 ] > > Slaves: [ tstcaps02 ] Why do you use DRBD with streaming replicatin? If you locates the database cluster on DRBD, it's better to check the status of DRBD filesystem. Regards, -- Fujii Masao
<<attachment: smime.p7s>>
