I did not receive any other responses on this. Can I get this logged as a bug?
And if so, how do I go about doing that. Thanks, Rob On 2/29/16, 10:28 AM, "slony1-general-boun...@lists.slony.info on behalf of Rob Brucks" <slony1-general-boun...@lists.slony.info on behalf of rob.bru...@rackspace.com> wrote: >Only errors connecting to the node I intentionally brought down as part of the >test. > >No errors in the origin daemon connecting to the subscriber that is still up >and running. If I check pg_stat_activity I see connections from both daemons >on both DB instances. > >Thanks, >Rob > > > > >On 2/29/16, 10:25 AM, "Jan Wieck" <j...@wi3ck.info> wrote: > >>On 02/29/2016 10:49 AM, Rob Brucks wrote: >>> 1. Yes, the sl_confirm data is showing up on the subscriber. >>> >>> 2. No, the origin node is not getting back the sl_confirm data from the >>> active subscriber. >> >>Does the origin node log any errors that it cannot connect to that >>subscriber node? >> >> >>Jan >> >> >> >>> >>> >>> Thanks, >>> Rob >>> >>> >>> >>> On 2/26/16, 8:38 PM, "Steve Singer" <st...@ssinger.info> wrote: >>> >>>>On Fri, 26 Feb 2016, Rob Brucks wrote: >>>> >>>>> >>>>> But, if I insert some test data into the master DB, I see the data show up >>>>> on the remaining active slave. So replication to the remaining slave DB >>>>> is obviously working. >>>> >>>>Replication with slony has two parts >>>> >>>>1. Does the data replicate from the origin to the subscriber. When this >>>>happens a row is added to the subscriber's sl_event table with >>>>ev_origin=$origin_node and a confirm is added to the subscribers sl_confirm >>>>table with con_origin=$origin_node and con_received=$subscriber_node >>>> >>>>2. The sl_confirm row mentioned above needs to then get picked up by the >>>>slon for the origin node and brought back from the subscriber to the origin. >>>> >>>>Are your confirms making it back? >>>> >>>> >>>>> >>>>> We use sl_status to monitor replication so we need it to accurately >>>>> report lag if there's an issue. The Slony 1.2 version we used before did >>>>> not behave this way, it accurately reported which slave was not >>>>> replicating. >>>>> >>>>> Why does sl_status report lag on the active slave even though replication >>>>> appears to be working fine? >>>>> >>>>> Do I have a misconfiguration somewhere? >>>>> >>>>> Thanks, >>>>> Rob >>>>> >>>>> >>>>> Here's my slony config: >>>>> >>>>> >>>>> CLUSTER NAME = slony; >>>>> NODE 1 ADMIN CONNINFO = 'dbname=test_db host=/tmp port=5432 >>>>> user=slony'; >>>>> NODE 2 ADMIN CONNINFO = 'dbname=test_db host=/tmp port=5433 >>>>> user=slony'; >>>>> NODE 3 ADMIN CONNINFO = 'dbname=test_db host=/tmp port=5434 >>>>> user=slony'; >>>>> >>>>> ############ CLUSTERS >>>>> >>>>> INIT CLUSTER (ID = 1, COMMENT = 'Master'); >>>>> >>>>> >>>>> ############ NODES >>>>> >>>>> STORE NODE (ID = 2, COMMENT = 'Slave1', EVENT NODE = 1); >>>>> STORE NODE (ID = 3, COMMENT = 'Slave2', EVENT NODE = 1); >>>>> >>>>> >>>>> ############ PATHS >>>>> >>>>> STORE PATH (SERVER = 1, CLIENT = 2, CONNINFO = 'dbname=test_db >>>>> host=/tmp port=5432 user=slony'); >>>>> STORE PATH (SERVER = 1, CLIENT = 3, CONNINFO = 'dbname=test_db >>>>> host=/tmp port=5432 user=slony'); >>>>> STORE PATH (SERVER = 2, CLIENT = 1, CONNINFO = 'dbname=test_db >>>>> host=/tmp port=5433 user=slony'); >>>>> STORE PATH (SERVER = 2, CLIENT = 3, CONNINFO = 'dbname=test_db >>>>> host=/tmp port=5433 user=slony'); >>>>> STORE PATH (SERVER = 3, CLIENT = 1, CONNINFO = 'dbname=test_db >>>>> host=/tmp port=5434 user=slony'); >>>>> STORE PATH (SERVER = 3, CLIENT = 2, CONNINFO = 'dbname=test_db >>>>> host=/tmp port=5434 user=slony'); >>>>> >>>>> >>>>> ############ SETS >>>>> >>>>> CREATE SET (ID = 1, ORIGIN = 1, COMMENT = 'TEST Set 1'); >>>>> >>>>> ############ SEQUENCES >>>>> >>>>> SET ADD SEQUENCE (SET ID = 1, ORIGIN = 1, ID = 1, FULLY QUALIFIED >>>>> NAME = '"public"."test_seq"'); >>>>> >>>>> ############ TABLES >>>>> >>>>> SET ADD TABLE (SET ID = 1, ORIGIN = 1, ID = 2, FULLY QUALIFIED NAME >>>>> = '"public"."test"'); >>>>> >>>>> ############ SUBSCRIPTIONS >>>>> >>>>> SUBSCRIBE SET (ID = 1, PROVIDER = 1, RECEIVER = 2, FORWARD = YES); >>>>> SUBSCRIBE SET (ID = 1, PROVIDER = 1, RECEIVER = 3, FORWARD = YES); >>>>> >>>>> >>>>> _______________________________________________ >>>>> Slony1-general mailing list >>>>> Slony1-general@lists.slony.info >>>>> http://lists.slony.info/mailman/listinfo/slony1-general >>>>> >>>> >>> _______________________________________________ >>> Slony1-general mailing list >>> Slony1-general@lists.slony.info >>> http://lists.slony.info/mailman/listinfo/slony1-general >>> >> >> >>-- >>Jan Wieck >>Database Architect >_______________________________________________ >Slony1-general mailing list >Slony1-general@lists.slony.info >http://lists.slony.info/mailman/listinfo/slony1-general _______________________________________________ Slony1-general mailing list Slony1-general@lists.slony.info http://lists.slony.info/mailman/listinfo/slony1-general
