Antonio Escudero <aescudero at rocketmail.com> writes:

> 1. I know now that slony is working, but i still want to know on how long will it take to finish replicating a large database?
> 2. I used ps -aux to look at processing on my system.
> then i got this
> USER?????? PID %CPU %MEM?? VSZ? RSS TTY????? STAT START?? TIME COMMAND
> postgres 24723? 0.0? 0.9 899824 59564 ?????? S??? Feb14?? 0:12 postgres: postgres database_name 66.94.234.13(47439) idle????? 
> postgres 24728? 5.7 13.6 903412 837340 ????? D??? Feb14 169:39 postgres: postgres database_name 66.94.234.13(47440) COPY????? 
> postgres 24729? 0.0? 0.9 899016 55732 ?????? S??? Feb14?? 0:25 postgres: postgres database_name 66.94.234.13(47441) idle????? 
> postgres 24730? 0.0? 4.5 900136 277144 ????? S??? Feb14?? 0:36 postgres: postgres database_name 66.94.234.13(47442) idle????? 
> does this means that it is still replicating the database? 

That would seem pretty probable.

> what does Feb14 169:39 postgres: postgres database_name 66.94.234.13(47440) COPY? means? 

That means that there is a connection busy copying all the data in the
replicated tables.  You can expect to see this twice:

1.  On the server providing the data, there is a "COPY some_table to
    stdout;" operation running;

2.  On the server subscribing to the data, there is a "COPY some_table from
    stdin;" operation running;

I'm not sure which server you were checking; there should be two of
them "tangoing" at this point...

> 3.? I tried to query some tables in the slave database.?
> Unfortunately, the tables are locked.? How will i know that the data
> are being copied or appended to the slave database?

It'll be done when it's done.

In Slony-I version 1.2, the locks will actually be more express; there
are cases, now, where the system can get into a deadlock because the
slon grabs tables one at a time, and so a deadlock could lead to a big
waste of time because some data (possibly lots of it) could get copied
and then roll back due to the deadlock.  In 1.2, we'll completely lock
the tables on the subscriber up front, which eliminates this
particular risk...

> 4.? Does this query tell that slony is appending the slave db (db_name)?
> ?postgres=# select * from pg_stat_database;
> ?? datid?? |? datname? | numbackends | xact_commit | xact_rollback | blks_read | blks_hit 
> -----------+-----------+-------------+-------------+---------------+-----------+----------
> ???????? 1 | template1 |?????????? 0 |???????? 100 |??????????? 12 |???????? 0 |??????? 0
> ???? 17229 | template0 |?????????? 0 |?????????? 0 |???????????? 0 |???????? 0 |??????? 0
> ?675239438 | db_name ?? |???????? 300 |?????? 40965 |???????? 140 11 |???????? 0 |??????? 0
> (3 rows)

I don't think there's anything much of interest to be seen from this
query.

> 5? In my slony log file, i got the following now:
> DEBUG2 remoteListenThread_1: queue event 1,1471 SYNC
> DEBUG2 remoteListenThread_1: queue event 1,1472 SYNC
> DEBUG2 syncThread: new sl_action_seq 1 - SYNC 222
> DEBUG2 remoteListenThread_1: queue event 1,1473 SYNC
> DEBUG2 localListenThread: Received event 2,222 SYNC
> DEBUG2 remoteListenThread_1: queue event 1,1474 SYNC
> DEBUG2 remoteListenThread_1: queue event 1,1475 SYNC
> DEBUG2 remoteListenThread_1: queue event 1,1476 SYNC
> Tue Feb 14 14:11:01 PST 2006
> DEBUG2 remoteListenThread_1: queue event 1,1477 SYNC

Is this the log for the provider node?  Or the subscriber?

If it's the subscriber, you'll probably see a bunch of SYNCs being
queued while the subscription is taking place.  Once the data is all
copied, those SYNCs will be processed.  If there are tables that are
Real Big, it may take as much as hours to copy the tables, so there
may be a lot of SYNCs in the interim.  

If you grep for the word "copy" in the log, that may be more useful to
you...
-- 
"cbbrowne","@","ca.afilias.info"
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)