IPv6 Status

[Joe Topjian]

Hello,

I'm wondering if anyone knows the status of IPv6 or has a working IPv6-only implementation?

I see there is an open bug for IPv6 (https://bugs.launchpad.net/galera/+bug/1130595) but no status update in a while.

I've been able to get nodes to join to each other using IPv6, but SST (at least with xtrabackup) always falls back to IPv4. wsrep refuses to parse any IPv6 address format. Using "sockopt", I can get socat to listen on all interfaces (including v6), but SST still wants to use v4.

Thanks,

Joe

[alexey.y...@galeracluster.com]

Hi,

1) so far there was little interest in IPv6 support, hence no status
updates for the bug. No work was done on it. So I'm quite surprised to
hear that you got it working there. Perhaps it always worked then.

2) there are two unrelated parts in the equation there: Galera plugin
(which does actual replication) and SST scripts (which do initial data
copying). They work totally independently. So if you have issue with
xtrabackup SST, it is either an issue with the script or xtrabackup
itself. You may want to check the script and it may be easily fixable.

Regards,
Alex

[Joe Topjian]

Hi Alex,

Thanks for the info. I'll dig into the sst script when I get a chance and report if I'm able to find anything.

Thanks again,

Joe

--
You received this message because you are subscribed to the Google Groups "codership" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codership-team+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joe Topjian]

Hello,

I had a chance to start digging into the SST scripts to see if I could make it IPv6-compatible. I'm seeing an issue where the address is being split at a colon (most likely to split the IPv4 address and port). For example:

[Note] WSREP: Running: 'wsrep_sst_xtrabackup-v2 --role 'joiner' --address '[2605' --auth 'sstuser:password' --datadir '/var/lib/mysql/' --defaults-file '/etc/mysql/my.cnf' --parent '5412'  '' '

I'm unable to find where this split is taking place. Where does the actual call to wsrep_sst_xtrabackup-v2 with all arguments happen?

Thanks,

Joe

[alexey.y...@galeracluster.com]

There is a long story with autoguessing IP addresses and ports. Seeing
that you have it split you have not defined fully neither
wsrep_node_address nor wsrep_sst_address. Try to define them fully
(including ports).

All in all I think you could have a better chance of success if you used
hostnames instead of IP addresses.

Regards,
Alex

>>> email to codership-tea...@googlegroups.com.

[Joe Topjian]

ah! you're right - wsrep_sst_receive_address wasn't set. I set it and the full address is now being passed.

I fully agree about hostnames. If I have IPv6 host entries in /etc/hosts, would that be good enough? Is there anything that Galera does that ignores hosts entries and does a DNS lookup? The reason I ask is if there is a case where there's both an A and AAAA record.

On Tue, Jul 29, 2014 at 10:50 AM, <alexey.y...@galeracluster.com> wrote:

There is a long story with autoguessing IP addresses and ports. Seeing that you have it split you have not defined fully neither wsrep_node_address nor wsrep_sst_address. Try to define them fully (including ports).

All in all I think you could have a better chance of success if you used hostnames instead of IP addresses.

Regards,
Alex

On 2014-07-29 17:05, Joe Topjian wrote:

Hello,

I had a chance to start digging into the SST scripts to see if I could make
it IPv6-compatible. I'm seeing an issue where the address is being split at
a colon (most likely to split the IPv4 address and port). For example:

[Note] WSREP: Running: 'wsrep_sst_xtrabackup-v2 --role 'joiner' --address
'[2605' --auth 'sstuser:password' --datadir '/var/lib/mysql/'
--defaults-file '/etc/mysql/my.cnf' --parent '5412'  '' '

I'm unable to find where this split is taking place. Where does the actual
call to wsrep_sst_xtrabackup-v2 with all arguments happen?

Thanks,
Joe



On Mon, Jul 14, 2014 at 3:19 PM, Joe Topjian <j...@topjian.net> wrote:

Hi Alex,

Thanks for the info. I'll dig into the sst script when I get a chance and
report if I'm able to find anything.

Thanks again,
Joe

On Mon, Jul 14, 2014 at 12:48 PM, <alexey.yurchenko@galeracluster.com>
wrote:

email to codership-team+unsubscribe@googlegroups.com.

[alexey.y...@galeracluster.com]

On 2014-07-29 17:56, Joe Topjian wrote:
> ah! you're right - wsrep_sst_receive_address wasn't set. I set it and
> the
> full address is now being passed.
>
> I fully agree about hostnames. If I have IPv6 host entries in
> /etc/hosts,
> would that be good enough? Is there anything that Galera does that
> ignores
> hosts entries and does a DNS lookup? The reason I ask is if there is a
> case
> where there's both an A and AAAA record.

/etc/hosts should be enough - as long as you have a proper resolve order
;)
Galera does nothing fancy in this respect. So as long as the OS resolves
the hostname, I'd expect everything to work, xtrabackup included.

>>>> <alexey.y...@galeracluster.com>

>>>>> email to codership-tea...@googlegroups.com.

[Hui Xiang]

Hi all,

  I am deploying on ipv6 environment too, and there is no lucky, two errors are hit, any help is really appreciated.

  1. getaddrinfo failed

   Already add the ipv6 and hostname in /etc/hosts and dnsdomainname return a good value, does anyone know or have a clue about why this error is still happening? it might also happens on ipv4, but usually it 's working when the cluster first created, after reboot or rebuild the my.cnf with other ip address values, it just appears, so does galera keep the dns look up cache?

   140908  1:52:50 [ERROR] WSREP: failed to open gcomm backend connection: 113: getaddrinfo failed with error 'Name or service not known' (-2) for tcp:// [2001:db8:1:0:f9df:1c05:f1f5:ec2a]:4567: 113 (No route to host)

         at galerautils/src/gu_resolver.cpp:resolve():530

140908  1:52:50 [ERROR] WSREP: gcs/src/gcs_core.c:gcs_core_open():196: Failed to open backend connection: -113 (No route to host)

140908  1:52:50 [ERROR] WSREP: gcs/src/gcs.c:gcs_open():1292: Failed to open channel 'juju_cluster' at 'gcomm://juju-xianghui-machine-2, [2001:db8:1:0:f9df:1c05:f1f5:ec2a]:4567': -113 (No route to host)

140908  1:52:50 [ERROR] WSREP: gcs connect failed: No route to host

140908  1:52:50 [ERROR] WSREP: wsrep::connect() failed: 7

140908  1:52:50 [ERROR] Aborting

2.  If the above error isn't reported, then next below error appears, 'connection timeout', I am wondering if the cluster is using ipv6 multicast depends on physical environment support ipv6 multicast?  is there any place to indicate how the gcomm cluster address and the group works with any protocol layer?

140908  1:10:10 [Note] WSREP: gcomm: connecting to group 'juju_cluster', peer 'juju-xianghui-machine-2:,juju-xianghui-machine-1:'

140908  1:10:10 [Warning] WSREP: (e0de3f8f-36f4-11e4-827e-f76099c53dc0, 'tcp://[::]:4567') address 'tcp://[2001:db8:1:0:754d:f9a8:1c10:7932]:4567' points to own listening address, blacklisting

140908  1:10:13 [Warning] WSREP: no nodes coming from prim view, prim not possible

140908  1:10:13 [Note] WSREP: view(view_id(NON_PRIM,e0de3f8f-36f4-11e4-827e-f76099c53dc0,1) memb {

        e0de3f8f-36f4-11e4-827e-f76099c53dc0,

} joined {

} left {

} partitioned {

})

140908  1:10:13 [Warning] WSREP: last inactive check more than PT1.5S ago (PT3.50252S), skipping check

140908  1:10:43 [Note] WSREP: view((empty))

140908  1:10:43 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)

         at gcomm/src/pc.cpp:connect():141

140908  1:10:43 [ERROR] WSREP: gcs/src/gcs_core.c:gcs_core_open():196: Failed to open backend connection: -110 (Connection timed out)

140908  1:10:43 [ERROR] WSREP: gcs/src/gcs.c:gcs_open():1292: Failed to open channel 'juju_cluster' at 'gcomm://juju-xianghui-machine-2,juju-xianghui-machine-1': -110 (Connection timed out)

140908  1:10:43 [ERROR] WSREP: gcs connect failed: Connection timed out

140908  1:10:43 [ERROR] WSREP: wsrep::connect() failed: 7

140908  1:10:43 [ERROR] Aborting

I know there is little interest on ipv6 at this moment, but would someone to tell the mechanism of how the cluster communicate between each other when ipv6 is used.

Thanks in advance.    

[David Timothy Strauss]

Assuming this work will show up in the merged MariaDB with Galera, I
will happily fund work for better IPv6 support if someone is qualified
and just looking for sponsorship.

[Sergey Mishin]

Hello,
actually, i got Galera working over IPv6-only network.
To get Galera working over IPv6 you need add following line to your my.cnf(or replace if you already have the same one) _across all your nodes_:

wsrep_provider_options = "gmcast.listen_addr=tcp://[::]:4567;"

Also, i'm using Percona version of Galera cluster(XtraDB cluster), so there is included script for SST transfer /usr/bin/wsrep_sst_xtrabackup-v2. To make it working over IPv6 you need apply following sed:

# sed -i -e 's/socat -u/socat -6 -u/' /usr/bin/wsrep_sst_xtrabackup-v2

After that just run /etc/init.d/mysql start and node should get the SST from bootstraped one.

[Рыжий Лис]

Hello,

Actually i have two dual-stack machines and one ipv6-only and i cant get it working.

so.. I add some checks to /usr/bin/wsrep_sst_* scripts, and finally got it working. But anyway, percona developers must fix that error(i doesnt want to set up wsrep_sst_receive_address manually) and fix/test ipv6 for 'mysqldump' and 'xtrabackup' wsrep_sst_method(i didn't do that)

Debian package and sources you can find here: https://github.com/idonin/percona-galera-ipv6-fix





понедельник, 6 апреля 2015 г., 15:55:34 UTC+3 пользователь Sergey Mishin написал:

[Joe Topjian]

A year after starting this thread, I got IPv6 replication working. :)  Not that it took me a year, I just finally had time to revisit.

Here's my patch to wsrep_sst_xtrabackup-v2 to enable IPv6 connectivity:

https://gist.github.com/jtopjian/b280b4f04942e456a880

In my MySQL configuration, I set the following:

[mysqld]

wsrep_provider_options = "gmcast.listen_addr=tcp://[::]:4567; ist.recv_addr=[IPV6-ADDR]:4568"

wsrep_node_address = [IPV6-ADDR]:4567

wsrep_sst_receive_address = [IPV6-ADDR]:4444

Thanks,

Joe

  

[Philip Stoev]

Hello,

Thank you very much for your contribution. I have opened a ticket on GitHub
and attached your patch there

https://github.com/codership/mysql-wsrep/issues/161

Philip Stoev