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
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 |