Re: Implementing Replication via pgAdmin - Mailing list pgadmin-support

>> All is fine except that these slons are running as
>> foreground processes and cannot be backgrounded and
>> killing the command window  will terminate the process!
>> How can I get the slons running without  resorting to
>> using command windows to start the replication processes?
>
>Install them as a service, eg.
>
>slon -regservice Slony-I
>
>The service can then be started from the services control panel
>applet or from the command line using:
>
>net start Slony-I
>
>It'll start automatically at next reboot as well.
>
>Regards, Dave
>

I think might I see what is happening and why I was not able to
get the nodes running for replication.

What I said before was that I grabbed a copy of slon.conf from
the CVS HEAD and used this file verbatim, i.e. no changes were
made at all to this file and I used this file as my engine.

First, I want to point out, that the slon service is using
LocalSystem account. I further note that I had to change the
password for the LocalSystem account to the password I am
using for the slon, then apply it.  Next, I had to define the
environment variable PGUSER=postgres and PGPASSWORD=***,
then start the service.  I found that if I did not do this,
then there is an error message reported that PostgreSQL
could not reach the local databases and pgAdmin was unable to
connect either as it was reporting TCP connection errors.

Anyway, after the service were started,

1) The Log Messages reported:
"INFO   started 0 slon engine(s)"

2) Followed with: "ERROR  Process for engine at 'E:\Program Files \PostgreSQL\8.2\Slony\slon.conf' died on startup. "

I had assumed all along that since the service was still running
all must be OK, but I assumed wrongly, I think.  The key point
here is that the slon.conf file has NO ENTRIES, they are ALL
COMMENTED OUT!

OK, with this line of thinking that *SOMETHING* has to be exposed
in the slon.conf file, then I proceeded to uncomment 2 lines.

More specifically:

# Set the cluster name that this instance of slon is running against
# default is to read it off the command line
cluster_name='MasterCluster'

# Set slon's connection info, default is to read it off the command line
conn_info='host=copper.cdkkt.com port=5432 dbname=MyTest user=postgres password=***'

Ok, then I restarted the slon service and then I get alot of slon Log
messages, but apparently at some intervals, I still get these errors
cropping up:
3) ERROR  slon_connectdb: PQconnectdb("host=raider.cdkkt.com dbname=MyTest  user=postgres") failed - fe_sendauth: no
passwordsupplied 

OK, seems that I finally was able to get at least the slon.conf files to be
accepted.  I find that without the password= entry, I would get a different
error message reported (unable to reach local databases), so it seems that
I need it.

I did the same thing for slave side, and I get an error message:
4) ERROR  slon_connectdb: PQconnectdb("host=copper.cdkkt.com dbname=MyTest  user=postgres") failed - fe_sendauth: no
passwordsupplied 

Seems that master cannot reach the slave and the slave cannot reach
the master?

I thought that perhaps this was due to the account being LocalSystem
accounts, for the both master and slave servers and perhaps network
access is not permitted with these accounts?

And yet, I note that the Nodes on both the master and slave are
running with PID and valid process id numbers.  However, changing
a value in the master database table does not replicate to the slave.

As a test, I tried to use a local user account for the slon service on
the master as 'postgres', which is a Windows 2000 Professional OS, which
allows local user accounts to be created and I was able to get slon to
run, but as for the slave server, which is a Windows 2000 Server, which
is also a secondary Domain Controller, I am not allowed to create local
user accounts, but instead must use the domain user account
as: 'postgres@cdkkt.com' which differs from that used by PostgreSQL
as: 'postgres'?

This is getting really confusing...

Please advise?

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.487 / Virus Database: 269.13.27/1020 - Release Date: 9/20/2007 12:07 PM