Re: [HACKERS] Logical replication existing data copy
От | Erik Rijkers |
---|---|
Тема | Re: [HACKERS] Logical replication existing data copy |
Дата | |
Msg-id | 93d02794068482f96d31b002e0eb248d@xs4all.nl обсуждение исходный текст |
Ответ на | Re: [HACKERS] Logical replication existing data copy (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Logical replication existing data copy
Re: [HACKERS] Logical replication existing data copy Re: Logical replication existing data copy |
Список | pgsql-hackers |
On 2017-03-08 10:36, Petr Jelinek wrote: > On 07/03/17 23:30, Erik Rijkers wrote: >> On 2017-03-06 11:27, Petr Jelinek wrote: >> >>> 0001-Reserve-global-xmin-for-create-slot-snasphot-export.patch + >>> 0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch+ >>> 0003-Prevent-snapshot-builder-xmin-from-going-backwards.patch + >>> 0004-Fix-xl_running_xacts-usage-in-snapshot-builder.patch + >>> 0005-Skip-unnecessary-snapshot-builds.patch + >>> 0001-Logical-replication-support-for-initial-data-copy-v6.patch >> >> I use three different machines (2 desktop, 1 server) to test logical >> replication, and all three have now at least once failed to correctly >> synchronise a pgbench session (amidst many succesful runs, of course) > > yes waldump would be useful, the last segment should be enough, but > possibly all segments mentioned in the log. I've inserted a pg_waldump call in the program when the md5s remain the same (on both master and replica) for 5 wait-cycles (= 5 * 5 seconds + the time it takes to run (8x) the md5s + select count(*), which is more than a minute on this slow disk (at least the first time)) > > The other useful thing would be to turn on log_connections and > log_replication_commands. done. (so output will be in the log files.) > pg_subscription_rel, pg_replication_origin_status on subscriber and > pg_replication_slots on publisher done. (added to logs) The attached bz2 contains - an output file from pgbench_derail2.sh (also attached, as it changes somewhat all the time); the - the pg_waldump output from both master (file with .1. in it) and replica (.2.). - the 2 logfiles. file Name: logrep.20170309_1021.1.1043.scale_25.clients_64.NOK.log 20170309_1021 is the start-time of the script 1 is master (2 is replica) 1043 is the time, 10:43, just before the pg_waldump call The tail of the logfiles and of the output file will be a little ahead of the pg_waldump (not more than a few minutes) because I didn't stop the script while gathering the files manually. HTH! Let me know if more is needed (more wal, for instance) thanks, Erik Rijkers PS the attached script now contains some idiosyncrasies of my setup so it will probably complain here and there when run unaltered elsewhere) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: