Re: Who is Slony Master/Slave + general questions.

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Shoaib Mir <shoaibmir(at)gmail(dot)com>
Cc: sjarosz(at)gmail(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: Who is Slony Master/Slave + general questions.
Date: 2007-01-24 11:50:10
Message-ID: ea56563925be5eec43d76546075838cb@oopsware.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, 20 Jan 2007 11:07:57 +0500, "Shoaib Mir" <shoaibmir(at)gmail(dot)com> wrote:
> I dont have the replication setup on my machine right now but I guess as
> far
> as I remember you can surely check for the master and slave nodes from a
> Slony schema table.
>

I think the notion of "master and slave server" is a little bit misleading here:
We have sets and a node could be a origin or subscriber of them. Thinking that way,
one idea to get that information is to issue

SELECT
a.set_id,
a.set_comment,
(SELECT last_value FROM _replication.sl_local_node_id) AS local_id,
CASE WHEN a.set_origin = (SELECT last_value FROM _replication.sl_local_node_id) THEN
TRUE
ELSE
FALSE END AS master_node
FROM
_replication.sl_set a;

This gives you a result set which holds TRUE for every set the current node is
an origin node for.

> ------------
> Shoaib Mir
> EnterpriseDB (www.enterprisedb.com)
>
> On 19 Jan 2007 08:25:23 -0800, sjarosz(at)gmail(dot)com <sjarosz(at)gmail(dot)com>
> wrote:
>>
>> I am using LinuxHA to manage the failover and Slony as part of to
>> failover to move to the healthy node. But my question was more along
>> the lines, if a user has access to both databases (master and slave)
>> but does not know which one is which, how can you tell?
>>
>> Take a scenario: you configure 2 servers as master and slave. You walk
>> for a period of time during which a number failovers occur. You come
>> back. Can I query a sl_???? table to determine which server is the
>> current master and which one is the current slave?
>>

If you are using LinuxHA you have a virtual IP adress for your Cluster which points to the current
active "master" on your cluster. Connecting to the master node should always happen through this
IP adress, so you always "know" you are on the master when using this IP. You could then spread read
operations along the IPs assigned directly to each node, "declaring" these connections read only.

Bernd

In response to

Browse pgsql-general by date

  From Date Subject
Next Message marcelo Cortez 2007-01-24 13:05:58 Re: how to read bytea field
Previous Message Shoaib Mir 2007-01-24 10:32:44 Re: copy schema X to schema Y in the same DB