[Bucardo-general] Long delay before changes on remote master propogate to local

[Paul Theodoropoulos]

So, after many many fits and starts, we have a successful 
single-controller bucardo multimaster setup in a dev environment. It 
took forever for me to recognize that doing initial setup with the 
remote  as a 'target', doing one-time-copy, then changing the remote to 
also be 'source', simply didn't work - the controller master still 
considered the remote db's as targets (probably me coding the deploy 
script incorrectly). Switched to setting it up as source/source, and 
then manually copying the db data across did the trick. Never could get 
a dual-controller (criss-cross) multimaster setup to work - though it 
was probably related to the above setup problems.

That said. We did a test this morning of resilience to outage - I turned 
off bucardo on the local master, then on the remote master, we did 1000 
inserts into a table.  Two hours later, I turned Bucardo back on.  We 
have three syncs, the changes were made to only one database.

Eliding lots of repetitious log output, the times are bothersome:

start Bucardo:
(23733) [Thu Sep 19 12:12:02 2013] MCP Starting Bucardo version 5.0.0
Almost ten minutes later, Bucardo begins inspecting the local db groups 
on one dbgroup:
(23734) [Thu Sep 19 12:21:31 2013] MCP   Inspecting source table 
"public.alarm_notification_history" on database "local_trumgr_group"
Bucardo goes quiet again, then begin inspecting another dbgroup seven 
minutes later:
(23734) [Thu Sep 19 12:28:16 2013] MCP   Inspecting source table 
"public.admin_permissions" on database "local_trumgr_main"
Then finally Bucardo actually brings the databases into sync:
(23869) [Thu Sep 19 12:29:14 2013] KID Delta count for 
remote_trumgr_group.public.int_unit_moves                  : 1000
etc etc
(23869) [Thu Sep 19 12:29:18 2013] KID Totals: deletes=100 inserts=1200 
conflicts=0

Below are my current settings - what am I missing? I don't understand 
these very long quiescent periods in between Bucardo doing its work. I 
can of course post the full logs and lists of relgroups, syncs, etc 
separately.

autosync_ddl              = newcol
bucardo_current_version   = 5.0.0
bucardo_vac               = 1
bucardo_version           = 5.0.0
ctl_checkonkids_time      = 10
ctl_createkid_time        = 0.5
ctl_sleep                 = 0.2
default_conflict_strategy = bucardo_latest
default_email_from        = bucardo at anastrophe.com
default_email_host        = localhost
default_email_to          = sysadmin at anastrophe.com
email_debug_file          =
endsync_sleep             = 1.0
flatfile_dir              = .
host_safety_check         =
isolation_level           = read uncommitted
kid_deadlock_sleep        = 0.5
kid_nodeltarows_sleep     = 0.5
kid_pingtime              = 30
kid_restart_sleep         = 1
kid_serial_sleep          = 0.5
kid_sleep                 = 0.5
log_conflict_file         = bucardo_conflict.log
log_level                 = normal
log_microsecond           = 0
log_showlevel             = 0
log_showline              = 0
log_showpid               = 1
log_showtime              = 3
mcp_dbproblem_sleep       = 0.5
mcp_loop_sleep            = 0.2
mcp_pingtime              = 30
mcp_vactime               = 60
piddir                    = /var/run/bucardo
reason_file               = bucardo.restart.reason.txt
semaphore_table           = bucardo_status
statement_chunk_size      = 1000
stats_script_url          = http://www.bucardo.org/
stopfile                  = fullstopbucardo
syslog_facility           = local6
tcp_keepalives_count      = 0
tcp_keepalives_idle       = 0
tcp_keepalives_interval   = 0
vac_run                   = 30
vac_sleep                 = 120
warning_file              = bucardo.warning.log




-- 
Paul Theodoropoulos
www.anastrophe.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20130919/a63edac0/attachment.html>