Re: logical replication - still unstable after all these months

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: logical replication - still unstable after all these months
Date: 2017-05-26 23:35:56
Message-ID: 8986f6ad-315d-8754-caba-e3efb7e7433a@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 26/05/17 20:09, Erik Rijkers wrote:

>
> The idea is simple enough:
>
> startup instance1
> startup instance2 (on same machine)
> primary: init pgbench tables
> primary: add primary key to pgbench_history
> copy empty tables to replica by dump/restore
> primary: start publication
> replica: start subscription
> primary: run 1-minute pgbench
> wait till the 4 md5's of primary pgbench tables
> are the same as the 4 md5's of replica pgbench
> tables (this will need a time-out).
> log 'ok' or 'not ok'
> primary: clean up publication
> replica: clean up subscription
> shutdown primary
> shutdown replica
>
> this whole thing 100

I might have a look at scripting this up (especially if it keeps raining
here)...

Some questions that might help me get it right:
- do you think we need to stop and start the instances every time?
- do we need to init pgbench each time?
- could we just drop the subscription and publication and truncate the
replica tables instead?
- what scale pgbench are you running?
- how many clients for the 1 min pgbench run?
- are you starting the pgbench run while the copy_data jobs for the
subscription are still running?
- how exactly are you calculating those md5's?

Cheers

Mark

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2017-05-27 00:13:08 Re: ALTER SUBSCRIPTION ..SET PUBLICATION <no name> refresh is not throwing error.
Previous Message Jeff Janes 2017-05-26 23:25:14 logical replication busy-waiting on a lock