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
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 |