wsrep_cluster_address for multiple address

[Ruud G.]

Hello, 

In the new release of PXC wsrep_urls is deprecated:

Multiple addresses can now be specified in the gcomm:// URLwhen defining the address to connect to cluster.

Option wsrep_urls is now deprecated, wsrep_cluster_address should be used to specify multiple addresses instead. 

 http://www.mysqlperformanceblog.com/2012/11/15/announcing-percona-xtradb-cluster-5-5-28-23-7/

But I can't unrestand which syntax will be right in this case.

I tried the following:

• gcomm://A,B
  
• gcomm://A,gcomm://B
• gcomm:A;gcom://B

But in all cases I got the error:

[ERROR] WSREP: gcs/src/gcs.c:gcs_open():1290: Failed to open channel 'cluster0' at '{SPECIFIED_VALUE}': -255 (Unknown error 255)

Could anyone to explain me how I should rewrite wsrep_urls to use wsrep_cluster_address instead of deprecated option?

Thanks a lot.

[Hrvoje Matijakovic]

Hi Ruud,

On Sat, Nov 17, 2012 at 12:29:08PM -0800, Ruud G. wrote:
> Hello,
>

> In the new release of PXC *wsrep_urls *is deprecated:
>
> *Multiple addresses can now be specified in the gcomm:// URLwhen defining
> > the address to connect to cluster.*
>
> *Option wsrep_urls is now deprecated, wsrep_cluster_address should be used
> > to specify multiple addresses instead. *

>
>
> > http://www.mysqlperformanceblog.com/2012/11/15/announcing-percona-xtradb-cluster-5-5-28-23-7/
>
>
> But I can't unrestand which syntax will be right in this case.
> I tried the following:
>

> - gcomm://A,B
> - gcomm://A,gcomm://B
> - gcomm:A;gcom://B
>
The correct syntax is:
gcomm://A,B

example:
wsrep_cluster_address=gcomm://10.2.2.26,10.2.2.27

You can check available options on http://www.codership.com/wiki/doku.php?id=galera_url

> But in all cases I got the error:
>
> [ERROR] WSREP: gcs/src/gcs.c:gcs_open():1290: Failed to open channel

> 'cluster0' at '*{SPECIFIED_VALUE}*': -255 (Unknown error 255)
>
> Could anyone to explain me how I should rewrite *wsrep_urls *to use *wsrep_cluster_address
> *instead of deprecated option?
> Thanks a lot.
>

You should bear in mind that the first time you're creating a new cluster the first node in cluster should use empty gcomm:// address. After you have at least one more node connected you can then point the wsrep_cluster_address of the first node to that node or if you have more nodes you can add them as well.

Example:
Node1
IP: 10.2.2.25
wsrep_cluster_address=gcomm://10.2.2.26,10.2.2.27

Node2
IP 10.2.2.26
wsrep_cluster_address=gcomm://10.2.2.25,10.2.2.27

Node3
IP 10.2.2.27
wsrep_cluster_address=gcomm://10.2.2.25,10.2.2.26

Regards,
Hrvoje

[Alex Yurchenko]

What's "roll over to an empty cluster"?

On 2012-11-27 15:36, Justice London wrote:
> Does this mean that the ability to roll over to an empty cluster (you
> could
> do this with wsrep_urls) no longer exists? If so under configuration
> management type solutions I consider this a big miss, as it will make
> things that much less automated. Is there a solution here I'm
> missing?
>
> Jutice
>
> On Monday, November 19, 2012 7:06:52 AM UTC-8, hrvoje matijakovic

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

[Justice London]

In wsrep_urls you could start a new cluster if it could not detect any of the other hosts like so: wsrep_urls=gcomm://ip1:4567,gcomm://ip2:4567,gcomm://

How do you do the same with wsrep addresses?

[Alex Yurchenko]

On 2013-02-04 21:32, Justice London wrote:
> In wsrep_urls you could start a new cluster if it could not detect
> any of
> the other hosts like so:
> wsrep_urls=gcomm://ip1:4567,gcomm://ip2:4567,gcomm://
>
> How do you do the same with wsrep addresses?

Good question. That would have been the correct way to start a cluster
- if only you could connect to mysql server before initializing storage
engines. As of now you can't and it is unlikely you ever will (since all
of the auth info is stored in the tables), so it works only with
wsrep_sst_method=mysqldump.

It goes like this:

1) set cluster addresses in my.cnf

wsrep_cluster_address=gcomm://addr1,addr2,addr3?pc.wait_prim=no

(pc.wait_prim=no is essential)

At that point you have a cluster component that is non-primary. It
won't accept any queries.

2) login to one of the nodes and

mysql> SET GLOBAL wsrep_provider_options="pc.bootstrap=1";

This will make the component primary. Note that this may cause massive
resyncs and state transfers between the nodes if they all have different
states.

Make sure that there is only one primary component at any time (that's
why it is impossible to automate).

In practice wsrep_urls method seems to be more usable, albeit
conceptually inferior and technically more risky.

[Oleksandr Drach]

Alex, 

I see multiple addresses in wsrep_cluster_address paramater has been just recently implemented.

Percona made it in Percona XtraDB Cluster 5.5.28-23.7.

Could you please point me to the exact Codership MySQL-wsrep release in which this feature was included?

Thanks!

[Alex Yurchenko]

Oleksandr,

It is not in MySQL-wsrep, it is in Galera, starting with 2.2.

On 2013-03-05 12:52, Oleksandr Drach wrote:
> Alex,
>

> I see multiple addresses in *wsrep_cluster_address *paramater has

> been just
> recently implemented.
> Percona made it in Percona XtraDB Cluster
>

> 5.5.28-23.7<http://www.mysqlperformanceblog.com/2012/11/15/announcing-percona-xtradb-cluster-5-5-28-23-7/>
> .

[Oleksandr Drach]

Alex,

Thanks a lot!

Just found original information in Galera release notes on 23.2.2rc1 release from the 2.x series released 2012-09-29. Really useful changes!

So now specifying multiple addresses we may ensure that after multiple servers crash (including "gcomm://") our nodes will be able to re-join cluster even if primary component remains down. Sounds good for crash recovery.

[Alex Yurchenko]

On 2013-03-06 11:12, Oleksandr Drach wrote:
> Alex,
>
> Thanks a lot!
>

> Just found original information in Galera release notes on *23.2.2rc1
> release from the 2.x series released 2012-09-29.*
> <https://launchpad.net/galera/+download?>Really

> useful changes!
> So now specifying multiple addresses we may ensure that after
> multiple
> servers crash (including "gcomm://") our nodes will be able to
> re-join
> cluster even if primary component remains down. Sounds good for crash
> recovery.

Not so fast. They will join, but you still need to command the cluster
to become primary. And if you're using rsycn or xtrabackup for SST you
won't be able to do it, because you can't connect to mysqld before you
initialize storage engines, and you can't do SST after that.