Write db connection details in .pgpass file.Restart postgresql and bucardo.Disable firewall. It shall work. RegardsOm PrakashBangalore
Sent from Yahoo Mail on Android On Sat, Sep 22, 2018 at 17:30, [email protected]<[email protected]> wrote: Send Bucardo-general mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://mail.endcrypt.com/mailman/listinfo/bucardo-general or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Bucardo-general digest..." Today's Topics: 1. Re: Trouble shooting db connections (David Christensen) 2. Re: Trouble shooting db connections (Paul Tader) ---------------------------------------------------------------------- Message: 1 Date: Fri, 21 Sep 2018 15:06:50 -0500 From: David Christensen <[email protected]> To: Paul Tader <[email protected]> Cc: [email protected] Subject: Re: [Bucardo-general] Trouble shooting db connections Message-ID: <[email protected]> Content-Type: text/plain; charset=utf-8 > On Sep 21, 2018, at 2:40 PM, Paul Tader <[email protected]> wrote: > > On Sep 21, 2018, 2:13 PM -0500, David Christensen <[email protected]>, wrote: >>> On Sep 21, 2018, at 1:45 PM, Paul Tader <[email protected]> wrote: >>> >>> On Sep 21, 2018, 1:28 PM -0500, David Christensen <[email protected]>, >>> wrote: >>>>> On Sep 21, 2018, at 12:36 PM, Paul Tader <[email protected]> wrote: >>>>> >>>>> Is there a way to troubleshoot why the "add sync" command fails? >>>>> >>>>> This is the second sync I've run from this host between a different set >>>>> of hosts (DEV and QA environments). The hosts have been added and a psql >>>>> connection from the command line works fine but when I try to setup a >>>>> sync it connections to one of the databases times out. >>>>> >>>>> $ bucardo add sync qasync tables=all dbs=qadbs --verbose >>>>> DBD::Pg::st execute failed: ERROR: DBI >>>>> connect('dbname=mydb;host=123.123.123.123;port=5432','migration',...) >>>>> failed: could not connect to server: Connection timed out >>>>> Is the server running on host "123.123.123.123" and accepting >>>>> TCP/IP connections on port 5432? at line 63. >>>>> CONTEXT: PL/Perl function "validate_goat" at /usr/local/bin/bucardo line >>>>> 5209. >>>> >>>> Is the ?bucardo? database running on a different server as the Bucardo >>>> daemon? Some database connections are made from the server that the >>>> Bucardo daemon runs on and some are made directly from the database in >>>> plperl functions, so I suspect the ?bucardo? database is the piece having >>>> connection issues, potentially due to firewalls or other access. If you >>>> can run a test psql connection from the database server itself then that >>>> may help in debugging this issue. >>>> >>> Sorry, I should have clarified. Yes, the bucardo database, daemon and >>> commands are all run from a ?admin? node. Connections from the admin node >>> to the two database I want to be apart of the sync are successful. I also >>> checked the connection to the local (bucardo) database and it was fine. >> >> Hmm, if it were SELinux issues or something I?d expect a connection denied >> not a timeout. Can you raise your log_level to DEBUG and see what it logs >> for the DSN? Looking for the output of this line: >> >> elog(DEBUG, "Connecting in validate_goat as $db{dsn} user=$db{user} pid=$$ >> for table $schema.$table"); >> >> Then could have a test perl script which just tries to do a DBI->connect as >> so: >> >> $dbh = DBI->connect($db{dsn}, $db{user}, $db{pass}, >> {AutoCommit=>0, RaiseError=>1, PrintError=>0}); >> >> with those corresponding logged values. >> >> If that works then we can see about next steps. >> -- >> David Christensen >> End Point Corporation >> [email protected] >> 785-727-1171 >> >> >> > Hmm nothing. I set the log_level to debug in ~/.bucardorc and restarted but > saw nothing logged before/during/after the command. Sorry, that would be Postgres? ?log_min_messages? parameter, and it will show up in the PostgreSQL log file. You could probably just change on the validate_goat function via running the following in your ?bucardo? database: ALTER FUNCTION bucardo.validate_goat() SET log_min_messages = ?DEBUG?; (Hand-waving syntax here; if you want to just change globally you can as well, it?ll just introduce a lot more noise.) -- David Christensen End Point Corporation [email protected] 785-727-1171 ------------------------------ Message: 2 Date: Fri, 21 Sep 2018 15:56:41 -0500 From: Paul Tader <[email protected]> To: David Christensen <[email protected]> Cc: [email protected] Subject: Re: [Bucardo-general] Trouble shooting db connections Message-ID: <1cadf6b6-72d2-4b89-b52b-ddf65749a539@Spark> Content-Type: text/plain; charset="utf-8" On Sep 21, 2018, 3:06 PM -0500, David Christensen <[email protected]>, wrote: > > On Sep 21, 2018, at 2:40 PM, Paul Tader <[email protected]> wrote: > > > > On Sep 21, 2018, 2:13 PM -0500, David Christensen <[email protected]>, > > wrote: > > > > On Sep 21, 2018, at 1:45 PM, Paul Tader <[email protected]> wrote: > > > > > > > > On Sep 21, 2018, 1:28 PM -0500, David Christensen <[email protected]>, > > > > wrote: > > > > > > On Sep 21, 2018, at 12:36 PM, Paul Tader <[email protected]> wrote: > > > > > > > > > > > > Is there a way to troubleshoot why the "add sync" command fails? > > > > > > > > > > > > This is the second sync I've run from this host between a different > > > > > > set of hosts (DEV and QA environments). The hosts have been added > > > > > > and a psql connection from the command line works fine but when I > > > > > > try to setup a sync it connections to one of the databases times > > > > > > out. > > > > > > > > > > > > $ bucardo add sync qasync tables=all dbs=qadbs --verbose > > > > > > DBD::Pg::st execute failed: ERROR: DBI > > > > > > connect('dbname=mydb;host=123.123.123.123;port=5432','migration',...) > > > > > > failed: could not connect to server: Connection timed out > > > > > > Is the server running on host "123.123.123.123" and accepting > > > > > > TCP/IP connections on port 5432? at line 63. > > > > > > CONTEXT: PL/Perl function "validate_goat" at /usr/local/bin/bucardo > > > > > > line 5209. > > > > > > > > > > Is the ?bucardo? database running on a different server as the > > > > > Bucardo daemon? Some database connections are made from the server > > > > > that the Bucardo daemon runs on and some are made directly from the > > > > > database in plperl functions, so I suspect the ?bucardo? database is > > > > > the piece having connection issues, potentially due to firewalls or > > > > > other access. If you can run a test psql connection from the database > > > > > server itself then that may help in debugging this issue. > > > > > > > > > Sorry, I should have clarified. Yes, the bucardo database, daemon and > > > > commands are all run from a ?admin? node. Connections from the admin > > > > node to the two database I want to be apart of the sync are successful. > > > > I also checked the connection to the local (bucardo) database and it > > > > was fine. > > > > > > Hmm, if it were SELinux issues or something I?d expect a connection > > > denied not a timeout. Can you raise your log_level to DEBUG and see what > > > it logs for the DSN? Looking for the output of this line: > > > > > > elog(DEBUG, "Connecting in validate_goat as $db{dsn} user=$db{user} > > > pid=$$ for table $schema.$table"); > > > > > > Then could have a test perl script which just tries to do a DBI->connect > > > as so: > > > > > > $dbh = DBI->connect($db{dsn}, $db{user}, $db{pass}, > > > {AutoCommit=>0, RaiseError=>1, PrintError=>0}); > > > > > > with those corresponding logged values. > > > > > > If that works then we can see about next steps. > > > -- > > > David Christensen > > > End Point Corporation > > > [email protected] > > > 785-727-1171 > > > > > > > > > > > Hmm nothing. I set the log_level to debug in ~/.bucardorc and restarted but > > saw nothing logged before/during/after the command. > > Sorry, that would be Postgres? ?log_min_messages? parameter, and it will show > up in the PostgreSQL log file. You could probably just change on the > validate_goat function via running the following in your ?bucardo? database: > > ALTER FUNCTION bucardo.validate_goat() SET log_min_messages = ?DEBUG?; > > (Hand-waving syntax here; if you want to just change globally you can as > well, it?ll just introduce a lot more noise.) > > -- > David Christensen > End Point Corporation > [email protected] > 785-727-1171 > > > Well it seems as if the local PostgreSQL Bucardo database was having problems. I logged in and ALTERed the function with no problem but still decided to restart the database before re-running the command. All worked and the process completed fine. So yea?, the fix was to restart the local Bucardo Postgres database. Thanks David, Paul Tader -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20180921/1a34cf73/attachment-0001.html> ------------------------------ _______________________________________________ Bucardo-general mailing list [email protected] https://mail.endcrypt.com/mailman/listinfo/bucardo-general End of Bucardo-general Digest, Vol 128, Issue 2 ***********************************************
_______________________________________________ Bucardo-general mailing list [email protected] https://mail.endcrypt.com/mailman/listinfo/bucardo-general
