You shouldn’t need to start over; if it’s not replicating it likely doesn’t have the triggers in place (look at the \d <tablename> to verify).
You can run `bucardo validate sync <syncname>` to force it to rebuild the triggers (assuming it’s correctly added in the sync itself). Adding a new table to an existing sync has tended to be a little bit of a weak spot IMHO; there may be ways of accomplishing it from the `bucardo` tool, but I’ve tended to just mixup the “bucardo” database. :-) HTH, David > On Aug 28, 2019, at 5:45 PM, Jeff Ross <[email protected]> wrote: > > Hi all, > > In my initial set up of bucardo to test, I missed adding a table to one of > the relgroups. The table is metro.load_det. > > First to show it isn't yet in the relgoup: > > [postgres@aeneas MetroReplication]$ bucardo list herds > Relgroup: cargotel_common DB: cargotel_cargotel_dev Members: > cargotel_common.load_classes, cargotel_common.ref_msa_code, > cargotel_common.zip_loc > Used in syncs: cargotel_common_sync > Relgroup: load DB: cargotel_cargotel_dev Members: > metro.carrier_rating, metro.carrier_rating_id_seq, metro.client_flags, > metro.client_flags_id_seq, metro.client_profile, metro.client_profile_id_seq, > metro.driver, metro.driver_id_seq, metro.insp_flags, metro.insp_flags_id_seq, > metro.insp_gm_area, metro.insp_gm_data, metro.insp_gm_data_id_seq, > metro.insp_gm_severity, metro.insp_gm_severity_id_seq, metro.insp_gm_what, > metro.insp_gm_what_id_seq, metro.insp_gm_where, metro.insp_gm_where_id_seq, > metro.lang, metro.lang_id_seq, metro.link_load_det, > metro.link_load_det_id_seq, metro.load, metro.load_cmt, > metro.load_cmt_id_seq, metro.load_events, metro.load_events_id_seq, > metro.load_flags, metro.load_flags2, metro.load_flags2_id_seq, > metro.load_flags_id_seq, metro.load_id_seq, metro.load_log, metro.load_log2, > metro.load_log2_pg_id_seq, metro.load_log_pg_id_seq, metro.loadacct_batch, > metro.loadacct_batch_id_seq, metro.quote, metro.quote_id_seq, metro.railcar, > metro.railcar_id_seq, metro.ref_client_status, metro.ref_client_status_old, > metro.ref_client_status_pg_id_seq, metro.ref_employment_type, > metro.ref_employment_type_id_seq, metro.ref_load_status, > metro.ref_load_status_pg_id_seq, metro.ref_quote_status, > metro.ref_quote_status_id_seq, metro.ref_quote_type, > metro.ref_quote_type_id_seq, metro.ref_sched_status, metro.trailer, > metro.trailer_id_seq, metro.truck, metro.truck_id_seq, metro.users, > metro.users_id_seq > Used in syncs: load_sync > > So I tried adding it with: > > bucardo add table -t metro.load_det relgroup=load db=cargotel_cargotel_dev > > and then adding it's sequence with: > > bucardo add sequence -t metro.load_det_id_seq relgroup=load > db=cargotel_cargotel_dev > > But it doesn't show up in the herd list at all. > > > postgres@aeneas MetroReplication]$ bucardo list herds > Relgroup: cargotel_common DB: cargotel_cargotel_dev Members: > cargotel_common.load_classes, cargotel_common.ref_msa_code, > cargotel_common.zip_loc > Used in syncs: cargotel_common_sync > Relgroup: load DB: cargotel_cargotel_dev Members: > metro.carrier_rating, metro.carrier_rating_id_seq, metro.client_flags, > metro.client_flags_id_seq, metro.client_profile, metro.client_profile_id_seq, > metro.driver, metro.driver_id_seq, metro.insp_flags, metro.insp_flags_id_seq, > metro.insp_gm_area, metro.insp_gm_data, metro.insp_gm_data_id_seq, > metro.insp_gm_severity, metro.insp_gm_severity_id_seq, metro.insp_gm_what, > metro.insp_gm_what_id_seq, metro.insp_gm_where, metro.insp_gm_where_id_seq, > metro.lang, metro.lang_id_seq, metro.link_load_det, > metro.link_load_det_id_seq, metro.load, metro.load_cmt, > metro.load_cmt_id_seq, metro.load_events, metro.load_events_id_seq, > metro.load_flags, metro.load_flags2, metro.load_flags2_id_seq, > metro.load_flags_id_seq, metro.load_id_seq, metro.load_log, metro.load_log2, > metro.load_log2_pg_id_seq, metro.load_log_pg_id_seq, metro.loadacct_batch, > metro.loadacct_batch_id_seq, metro.quote, metro.quote_id_seq, metro.railcar, > metro.railcar_id_seq, metro.ref_client_status, metro.ref_client_status_old, > metro.ref_client_status_pg_id_seq, metro.ref_employment_type, > metro.ref_employment_type_id_seq, metro.ref_load_status, > metro.ref_load_status_pg_id_seq, metro.ref_quote_status, > metro.ref_quote_status_id_seq, metro.ref_quote_type, > metro.ref_quote_type_id_seq, metro.ref_sched_status, metro.trailer, > metro.trailer_id_seq, metro.truck, metro.truck_id_seq, metro.users, > metro.users_id_seq > Used in syncs: load_sync > > After attempting to add that table to the sync I did a "bucardo reload > config" followed by a "bucardo stop" and a "bucardo start" but that also has > no effect on beginning replication of this table. > > Nor does it sync so any new rows or updates entered into > cargotel_dev.metro.load_det do not ever appear on the target. When I first > tried to add the table to the load relgroup I did copy it's data to the > target server with pg_dump and as always that worked great. > > Do I need to drop the bucardo schemas and the bucardo database and start > over? Hopefully I'm just missing something simple! > > Thanks! > > Jeff Ross > > > -- > The contents of this e-mail and any attachments are intended solely for the > use of the named addressee(s) and may contain confidential and/or privileged > information. Any unauthorized use, copying, disclosure, or distribution of > the contents of this e-mail is strictly prohibited by the sender and may be > unlawful. If you are not the intended recipient, please notify the sender > immediately and delete this e-mail. > _______________________________________________ > Bucardo-general mailing list > [email protected] > https://bucardo.org/mailman/listinfo/bucardo-general
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Bucardo-general mailing list [email protected] https://bucardo.org/mailman/listinfo/bucardo-general
