Galera 2.2

157 views
Skip to first unread message

Alexey Yurchenko

unread,
Oct 28, 2012, 8:21:35 PM10/28/12
to codersh...@googlegroups.com
Hi everybody,

After 2 release candidates Galera 2.2 has been released. This release contains important bug fixes, new features and performance improvements. This release is functionally equivalent to RC2 but adds two small fixes to configuration, in particular replicator.causal_read_timeout setting was not respected on startup (it worked when setting in runtime though).

Download: https://launchpad.net/galera/+download

Vadim Tkachenko

unread,
Oct 28, 2012, 10:38:46 PM10/28/12
to Alexey Yurchenko, codersh...@googlegroups.com
Alex,

So, is there a detailed ChangeLog with all
new features and bug fixed ?
> --
>
>



--
Vadim Tkachenko, CTO, Percona Inc.
Phone +1-925-400-7377, Skype: vadimtk153
Schedule meeting: http://tungle.me/VadimTkachenko

Looking for Replication with Data Consistency?
Try Percona XtraDB Cluster!

Thomas Linnemann

unread,
Oct 29, 2012, 5:52:18 AM10/29/12
to codersh...@googlegroups.com
Am 29.10.2012 03:38, schrieb Vadim Tkachenko:
> Alex,
>
> So, is there a detailed ChangeLog with all
> new features and bug fixed ?
>
>


Hi,
detailed changelog with new features would be nice.
Update from 23.2.1 runs very smooth.

thank you for galera


Thomas



Alexey Yurchenko

unread,
Oct 29, 2012, 9:30:30 AM10/29/12
to codersh...@googlegroups.com, tlin...@gwdg.de
Sorry guys, just didn't want to duplicate what has been already written here. But I guess you're right:

Fixed:

  • causal reads guarantee violation at cluster partitioning
  • exclusive keys didn't produce dependency on shared keys
  • race condition in desync method (could break RSU)
  • IST was not working across different EC2 accessibility zones (and similar)
  • causal reads timeout configuration was ignored

Added:

  • wsrep_incoming_addresses status variable contains a comma-separated list of incoming (client) addresses in the cluster component
  • ability to specify several node addresses in gcomm:// URL.

Performance:

  • Significant speedups and memory footprint reduction on ranged queries.

Regards,
Alex

Henrik Ingo

unread,
Oct 30, 2012, 7:48:27 AM10/30/12
to Alexey Yurchenko, codersh...@googlegroups.com, tlin...@gwdg.de
Alex, what do you mean with "client" in this one:

> wsrep_incoming_addresses status variable contains a comma-separated list of
> incoming (client) addresses in the cluster component

Since I can see incoming client addresses with SHOW PROCESSLIST, I'm
thinking this is something Galera related?

henrik
> --
>
>



--
henri...@avoinelama.fi
+358-40-8211286 skype: henrik.ingo irc: hingo
www.openlife.cc

My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559

Ilias Bertsimas

unread,
Oct 30, 2012, 8:41:35 AM10/30/12
to codersh...@googlegroups.com, Alexey Yurchenko, tlin...@gwdg.de, henri...@avoinelama.fi
I assume he means you can see a list of addresses of the cluster nodes connected to the current node.

Alex Yurchenko

unread,
Oct 30, 2012, 10:59:16 AM10/30/12
to henri...@avoinelama.fi, codersh...@googlegroups.com, tlin...@gwdg.de
Henrik, it is a list of addresses which the cluster listens for
incoming client connections at (i.e. listen addresses of all nodes (if
specified or guessed)). If you can digest the previous sentence, please,
pretty please, convert it to something anybody would understand! My
spoken language fails me.
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: +358-400-516-011

Ilias Bertsimas

unread,
Oct 30, 2012, 11:47:53 AM10/30/12
to codersh...@googlegroups.com, henri...@avoinelama.fi, tlin...@gwdg.de
wsrep_incoming_addresses status variable contains a comma-separated list of the addresses all the cluster nodes are listening on. ?

Henrik Ingo

unread,
Oct 31, 2012, 4:45:07 PM10/31/12
to Alex Yurchenko, codersh...@googlegroups.com
On Tue, Oct 30, 2012 at 4:59 PM, Alex Yurchenko
<alexey.y...@codership.com> wrote:
> Henrik, it is a list of addresses which the cluster listens for incoming
> client connections at (i.e. listen addresses of all nodes (if specified or
> guessed)). If you can digest the previous sentence, please, pretty please,
> convert it to something anybody would understand! My spoken language fails
> me.

There is nothing wrong with the sentence as such, but there are many
things now that a MySQL+Galera server will be listening for. You fail
to rule out all the potential wrong guesses.

So what you are saying is that it is a list of addresses (also port?)
that are currently members of the cluster (current cluster
configuration), and therefore traffic in the form of galera protocol
is expected and accepted.

Or would it also contain addresses specified in wsrep_cluster_address,
even if those nodes haven't actually shown up yet?

Let me ask another question which you can answer more easily: Kind of
a FAQ is "how can I find out which nodes are currently connected to
the cluster?" Is this the variable that answers that question?

henrik

Alex Yurchenko

unread,
Oct 31, 2012, 6:01:00 PM10/31/12
to henri...@avoinelama.fi, codersh...@googlegroups.com
On 2012-10-31 22:45, Henrik Ingo wrote:
> On Tue, Oct 30, 2012 at 4:59 PM, Alex Yurchenko
> <alexey.y...@codership.com> wrote:
>> Henrik, it is a list of addresses which the cluster listens for
>> incoming
>> client connections at (i.e. listen addresses of all nodes (if
>> specified or
>> guessed)). If you can digest the previous sentence, please, pretty
>> please,
>> convert it to something anybody would understand! My spoken language
>> fails
>> me.
>
> There is nothing wrong with the sentence as such, but there are many
> things now that a MySQL+Galera server will be listening for. You fail
> to rule out all the potential wrong guesses.

Indeed I do. As it follows:

> So what you are saying is that it is a list of addresses (also port?)

Well, what good is address without the port?

> that are currently members of the cluster (current cluster
> configuration), and therefore traffic in the form of galera protocol
> is expected and accepted.

No. It is about where MySQL client connections are expected and
accepted.

> Or would it also contain addresses specified in
> wsrep_cluster_address,
> even if those nodes haven't actually shown up yet?

Only the members of component.

> Let me ask another question which you can answer more easily: Kind of
> a FAQ is "how can I find out which nodes are currently connected to
> the cluster?" Is this the variable that answers that question?

Well, this list should be it if you can identify the nodes by the
addresses where they listen for client connections at. (again the same
construction which I believe is sufficiently grammatically correct and
unambiguous, yet so easy to misunderstand)

Henrik Ingo

unread,
Nov 1, 2012, 7:56:05 AM11/1/12
to Alex Yurchenko, codersh...@googlegroups.com
On Thu, Nov 1, 2012 at 12:01 AM, Alex Yurchenko
<alexey.y...@codership.com> wrote:
>> that are currently members of the cluster (current cluster
>> configuration), and therefore traffic in the form of galera protocol
>> is expected and accepted.
>
>
> No. It is about where MySQL client connections are expected and accepted.
>
>
>> Or would it also contain addresses specified in wsrep_cluster_address,
>> even if those nodes haven't actually shown up yet?
>
>
> Only the members of component.
>
>
>> Let me ask another question which you can answer more easily: Kind of
>> a FAQ is "how can I find out which nodes are currently connected to
>> the cluster?" Is this the variable that answers that question?
>
>
> Well, this list should be it if you can identify the nodes by the addresses
> where they listen for client connections at. (again the same construction
> which I believe is sufficiently grammatically correct and unambiguous, yet
> so easy to misunderstand)
>

Thanks, it makes sense now!

I have run Galera clusters where MySQL listens for client connections
on one network interface and Galera replication happens on another
interface. So I was focused on wsrep variables only being concerned
with the Galera replication. But like before, what you did here is a
very useful and user friendly piece of information and exceeded what
my imagination could expect. Good work!

In addition to knowing which nodes are currently part of the primary
cluster component, this information is directly usable as a list of
addresses that clients can use to connect to cluster. Very useful!

henrik

Ilias Bertsimas

unread,
Dec 17, 2012, 9:20:40 AM12/17/12
to codersh...@googlegroups.com, tlin...@gwdg.de
Hello,

You need to use the new wsrep_cluster_address parameter and according to the manual:


"As of version 2.2 Galera supports a comma-separated list of cluster members in the cluster address like:gcomm://node1,node2:port2,node3?key1=value1&key2=value2..."

Kind Regards,
Ilias.

On Monday, December 17, 2012 3:55:57 PM UTC+2, Валерий Москалев wrote:
"ability to specify several node addresses in gcomm:// URL"   - How i can specify several node addresses? comma separated ?

Thank you for galera
Valera
Reply all
Reply to author
Forward
0 new messages