Christopher Browne cbbrowne at ca.afilias.info
Tue Dec 18 08:03:36 PST 2007
"Josh Harrison" <joshques at gmail.com> writes:
> Thanks. So is this the case anytime the slaves are replicating ie.,
> you cant query the slaves when they are replicating the data anytime
> whether initially to catch up with the bulk data or later even for
> small data updates/inserts?

When applying SYNCs to catch up, or as normal activity, the replicated
tables are not exclusively locked.  The entire SYNC is managed as a
single transaction, so the tuples involved in the update will
obviously be locked for the duration of that transaction, but that's
normally not a long time.

The set of activities that take out locks are documented in the manual
pages.


> Also I came across another problem now. When the slave is replicating the data, it stopped since there was no disk space. So now I deleted some other unnecassary
> database in that disk and the disk has space now. But it will not resume te replication. Is that common. When i checked the salve's log it says
> ......
> ......
> 2007-12-18 09:54:42 EST DEBUG2 remoteWorkerThread_1: all tables for set 1 found on subscriber
> 2007-12-18 09:54:42 EST DEBUG2 remoteWorkerThread_1: copy table "public"."a_method"
> 2007-12-18 09:54:42 EST DEBUG3 remoteWorkerThread_1: table "public"."a_method" does not require Slony-I serial key
> 2007-12-18 09:54:42 EST ERROR  remoteWorkerThread_1: "select "_slony_rmrs".setAddTable_int(1, 2,
>  '"public"."a_method"', 'a_method_pk', 'a_method table'); " PGRES_FATAL_ERROR ERRO
> R:  Slony-I: setAddTable_int: table id 2 has already been assigned!
> 2007-12-18 09:54:42 EST WARN   remoteWorkerThread_1: data copy for set 1 failed - sleep 60 seconds.
> Before the 'no disk space' problem it had copied some tables's data..say the first few tables. So how can I make it resume the replication from where it stopped?
> This is the slony slave's log message when the error happened
> 2007-12-18 08:54:08 EST ERROR  remoteWorkerThread_1: "select "_slony_rmrs".finishTableAfterCopy(
> 6); analyze "public"."c_var"; " PGRES_FATAL_ERROR ERROR:  could not write block 4807
> 55 of relation 1663/44356/48354: No space left on device
> CONTEXT:  SQL statement "reindex table "public"."c_var""
> PL/pgSQL function "finishtableaftercopy" line 26 at execute statement
> 2007-12-18 08:54:08 EST WARN   remoteWorkerThread_1: data copy for set 1 failed - sleep 15 seconds

I'd be inclined to drop the node and recreate it.  That would be sure
to clean things out.

Note that when it gave up on copying the data, it gave up on ALL the
data; there's nothing to resume.
-- 
let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/
You know  how most packages say  "Open here". What is  the protocol if
the package says, "Open somewhere else"?


More information about the Slony1-general mailing list