Re: [percona-group] Configuration with backup node

[Alex Yurchenko]

On 2012-11-12 08:55, Sergey Rudenko wrote:
> Hello,
> I want to create a ckuster with the following configuration:
>
> - Node A is first node in cluster, and it will be used as backup node
> - Node A does not serve SQL queries
> - Node B and C are 'working' nodes - they will be under load and will
> receive SQL queries
> - If B or C crashed, they will receive SST transfer from A only (I
> suppose
> it contains the most consistent data)
> - If A crashed, it will receive SST from B or C.
>
> What value of 'wsrep_urls' I need to have on each node?
>
> My suggestion:
>
> A:
>> gcomm:// - at start to form a cluster
>> gcomm://B,gcomm://C - after cluster start
>>
>
>
>> B,C:
>> gcomm://A
>
>
>
> Is my suggestion right or not?
> Thanks.

Hi,

It is right. But it only facilitates reconnection to the cluster. After
that the donor will be chosen automatically.

If you want to configure A as a donor for B and C, you ALSO need

A:
wsrep_node_name="nodeA"

B,C:
wsrep_sst_donor="nodeA"

I take it is does not matter who will be a donor for A, so that will
suffice.

Regards,
Alex

--
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: +358-400-516-011

[Sergey Rudenko]

Thanks a lot, got it. 

Some additional questions:

1) Is it good practice or not - by your opinion? (to have a backup/reference node)

2) Am I right in my actions regarding to setting wsrep_urls?

- I start a cluster with 'gcomm://' on Node A

- then join B and C to cluster

- then change wsrep_urls on Node A to 'gcomm://B,gcomm://C' and restart it

Are these actions exactly correct or may be is there a better way? 

Sorry but it's really difficult to understand a mechanism of cluster URLs =)

A lot of howto's about PXC/Galera advise just to leave 'gcomm://' on 1st node, but if I understood right, it's a way to split-brain.

So, I'm a little bit confused with this issue. 

Please help.

Thanks in advance.

понедельник, 12 ноября 2012 г., 14:06:30 UTC+4 пользователь Alexey Yurchenko написал:

[Alex Yurchenko]

On 2012-11-12 12:42, Sergey Rudenko wrote:
> Thanks a lot, got it.
>
> Some additional questions:
>
> 1) Is it good practice or not - by your opinion? (to have a
> backup/reference node)

If you can afford it - definitely yes.

> 2) Am I right in my actions regarding to setting wsrep_urls?
> - I start a cluster with 'gcomm://' on Node A

If we're talking about wsrep_urls parameter, then I'd do

wsrep_urls=gcomm://B,gcomm://C,gcomm://

this way you would not need to restart it below, only remove gcomm://
part (you need to restart it only because mysqld_safe needs to be
restarted to read new wsrep_urls value).

> - then join B and C to cluster
> - then change wsrep_urls on Node A to 'gcomm://B,gcomm://C' and
> restart it
> Are these actions exactly correct or may be is there a better way?

Well, see above. And don't forget to specify ports in wsrep_urls.

> Sorry but it's really difficult to understand a mechanism of cluster
> URLs =)
> A lot of howto's about PXC/Galera advise just to leave 'gcomm://' on
> 1st
> node, but if I understood right, it's a way to split-brain.

No, it is not split-brain, but "split-cluster" which is even worse (a
node forms a separate cluster of his own). Never leave gcomm:// in
configuration. It is only for bootstrapping the cluster.

[Sergey Rudenko]

Thanks again.

No, it is not split-brain, but "split-cluster" which is even worse (a
node forms a separate cluster of his own). Never leave gcomm:// in
configuration. It is only for bootstrapping the cluster.

How can I automatically detect  a 'split-cluster' event in this case?

By monitoring of 'wsrep_cluster_size' on each node? 

Or is there some other params like 'cluster_id'? 

[Alex Yurchenko]

On 2012-11-12 13:51, Sergey Rudenko wrote:
> Thanks again.
>
>
> No, it is not split-brain, but "split-cluster" which is even worse (a
>> node forms a separate cluster of his own). Never leave gcomm:// in
>> configuration. It is only for bootstrapping the cluster.
>>
>
> How can I automatically detect a 'split-cluster' event in this case?
> By monitoring of 'wsrep_cluster_size' on each node?

Mostly yes.

> Or is there some other params like 'cluster_id'?

Depending on how the node was restarted, cluster UUID and even
transaction sequence number may be preserved - in order to allow quick
resync with the cluster bypassing SST. So it is definitely not the means
to detect cluster divergence.