Dropping table without going through Slony script

Hey,

Recently, unknowingly, we dropped a table on the master db which was a 
part of Slony replication without it going through the Slony script. 
This table is however present on the mirror/replicated db. I read 
somewhere, and want to confirm if the following hack will work.

Dropped table name : foo
tab_id in sl_table : 20

* Create a new table named "foo" with the same schema as the original 
dropped table
* Add trigger on the master table with name "_mirror_logtrigger_20"(as 
created on other replicated tables)
* Update sl_table with the new oid.
* All done, now drop the table via the slop drop script?

Thanks for help in advance

--
Anooj Narvekar

How do we change IP of origin?

We changed network topology in one of our clusters, and I need to renew
IP addresses in both origin and master.

How can I do that without restarting replication from scratch? In this
case, the data is small, and I can restart replication -- but still I
wonder whether there is a better way to do that or not.

Regards,

--

-- 
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

_______________________________________________
Slony1-general mailing list
Slony1-general@...
http://lists.slony.info/mailman/listinfo/slony1-general

Re: How do we change IP of origin?

On 11-01-04 09:15 AM, Devrim GÜNDÜZ wrote:
>
> We changed network topology in one of our clusters, and I need to renew
> IP addresses in both origin and master.
>
> How can I do that without restarting replication from scratch? In this
> case, the data is small, and I can restart replication -- but still I
> wonder whether there is a better way to do that or not.
>

I think you can do this by

1) Issuing a series of STORE PATH commands to update all of your 
conninfo tables to have the new IP

2) Restart the slon daemons to have the new IP in the conninfo for the 
local node (update the command line or slon.conf to have the new I.P)

3) Update any admin conninfo lines in any slonik scripts/preambles you 
have lying around

Slony doesn't store the nodes IP as part of sl_node.

> Regards,
>
>
>
>
> _______________________________________________
> Slony1-general mailing list

Re: How do we change IP of origin?

Le 04/01/2011 15:39, Steve Singer a écrit :
> On 11-01-04 09:15 AM, Devrim GÜNDÜZ wrote:
>>
>> We changed network topology in one of our clusters, and I need to renew
>> IP addresses in both origin and master.
>>
>> How can I do that without restarting replication from scratch? In this
>> case, the data is small, and I can restart replication -- but still I
>> wonder whether there is a better way to do that or not.
>>
> 
> I think you can do this by
> 
> 1) Issuing a series of STORE PATH commands to update all of your 
> conninfo tables to have the new IP
> 
> 2) Restart the slon daemons to have the new IP in the conninfo for the 
> local node (update the command line or slon.conf to have the new I.P)
> 
> 3) Update any admin conninfo lines in any slonik scripts/preambles you 
> have lying around
> 
> Slony doesn't store the nodes IP as part of sl_node.
> 
> 

Hi,

Having done such things recently, I can warn you to wait long enough to be sure

How do I go about restarting slony?

One of the slaves is running behind on replication. It is recommended that
you restart slony when this happens. What are the steps one should take to
go about restarting it?

Thanks, Sharad

--

-- 
View this message in context: http://old.nabble.com/How-do-I-go-about-restarting-slony--tp30588795p30588795.html
Sent from the Slony-I -- General mailing list archive at Nabble.com.

Re: How do I go about restarting slony?

On Tue, Jan 4, 2011 at 10:23 AM, sharadov <sreddy@...> wrote:
>
>
>
> One of the slaves is running behind on replication. It is recommended that
> you restart slony when this happens. What are the steps one should take to
> go about restarting it?

There's restarting the slon daemons, there's dropping a node and
recreating it, and there's dropping all replication and starting over.
 In that order.  How to stop and start slon daemons depends on how you
installed the slon daemons.  We used the slony tools to do it.  The
init script basically kill -9s all of the slon daemons to stop it, and
starts each with a script to start them.

After that, if the node can't catch up you may need to drop and
recreate the node.  Pretty simple really, read the reference docs on
drop node command to get started.

Then, there's tearing down all replication on all machines in the
cluster and starting over.  That's probably more involved than you
want or need really.

Re: How do I go about restarting slony?

Thanks Scott.
What is the command to stop/start slony?
And commands to drop a node and recreate it.

Scott Marlowe-2 wrote:
> 
> On Tue, Jan 4, 2011 at 10:23 AM, sharadov <sreddy@...> wrote:
>>
>>
>>
>> One of the slaves is running behind on replication. It is recommended
>> that
>> you restart slony when this happens. What are the steps one should take
>> to
>> go about restarting it?
> 
> There's restarting the slon daemons, there's dropping a node and
> recreating it, and there's dropping all replication and starting over.
>  In that order.  How to stop and start slon daemons depends on how you
> installed the slon daemons.  We used the slony tools to do it.  The
> init script basically kill -9s all of the slon daemons to stop it, and
> starts each with a script to start them.
> 
> After that, if the node can't catch up you may need to drop and
> recreate the node.  Pretty simple really, read the reference docs on
> drop node command to get started.
> 
> Then, there's tearing down all replication on all machines in the
> cluster and starting over.  That's probably more involved than you

Re: How do I go about restarting slony?

On Tue, Jan 4, 2011 at 11:37 AM, sharadov <sreddy@...> wrote:
>
>
> Thanks Scott.
> What is the command to stop/start slony?

Depends on your platform and how you installed it.  For my Ubuntu and
Centos boxen it's:

sudo /etc/init.d/slony stop
sudo /etc/init.d/slony start

> And commands to drop a node and recreate it.

You'll need to write some simple slonik scripts.  The one we use is
something like this:

------------------------------------------ drop_node2.slnk
---------------------------------

cluster name = slony_www;
 node 1 admin conninfo='host=db1 dbname=www user=slony port=5432';
 node 2 admin conninfo='host=db2 dbname=www user=slony port=5432';

try {
	drop node( id=2, event node=1);
  } on error {
        exit 1;
  }
  echo 'Dropped node 2';

Re: How do I go about restarting slony?

Thanks for the help Scott.
This should get me started.

Scott Marlowe-2 wrote:
> 
> On Tue, Jan 4, 2011 at 11:37 AM, sharadov <sreddy@...> wrote:
>>
>>
>> Thanks Scott.
>> What is the command to stop/start slony?
> 
> Depends on your platform and how you installed it.  For my Ubuntu and
> Centos boxen it's:
> 
> sudo /etc/init.d/slony stop
> sudo /etc/init.d/slony start
> 
>> And commands to drop a node and recreate it.
> 
> You'll need to write some simple slonik scripts.  The one we use is
> something like this:
> 
> ------------------------------------------ drop_node2.slnk
> ---------------------------------
> 
> cluster name = slony_www;
>  node 1 admin conninfo='host=db1 dbname=www user=slony port=5432';
>  node 2 admin conninfo='host=db2 dbname=www user=slony port=5432';
> 

Re: ERROR: duplicate key value violates unique constraint "sl_nodelock-pkey" error - bugzilla # 132

On 10-12-29 04:03 PM, Mark Steben wrote:
> Hi – I’ve been running slony 2.0.4 in test for a few weeks now.
>
> Just last week we physically moved the machine that houses the master db
>
> To a server block that the slave also resides on. We changed the i/p and
> also
>
> Began running with pgpool (port 9999) as the administrator.
>
> It was then that we began throwing the above error. No matter how many times
>
> I’ve cleared out sl_nodelock and restarted slon I still get the same
> error on
>
> The master postgres log. Reading through the slony docs and entering
> bugzilla
>
> For the first time, I come to realize this is a bug that has been fixed.
>
> I’m not a systems administrator so, while I do database upgrades, I’m
> not as familiar
>
> With applying patches on existing software and I’m totally new to
> bugzilla. Need some
>
> Guidance. Do I:
>
> 1. Upgrade to 2.0.5?
>