maria-discuss team mailing list archive

[Guillaume Lefranc <guillaume.lefranc@xxxxxxxxxxx>]

Hi Craig,

I assume that you use MariaDB Galera Cluster 10.0, in which case GTID's
aren't kept in sync across the cluster.
I would recommend upgrading to MariaDB Galera Cluster 10.1 and set the two
following variables:

wsrep_gtid_mode=1
wsrep_gtid_domain_id=N # set this value to a domain_id which isn't
allocated in your replication setup. It will be strictly used for Galera

If you want to do slave failover with 10.0, this is purely a manual
process, and GTID isn't really well supported. An alternative is to use
multi-source and create replication connections from each node to the slave.

Best regards



On Fri, Apr 22, 2016 at 2:25 PM Craig Bailey <cbailey@xxxxxxxxxx> wrote:

> Hi,
>
>
>
> I am attempting to get remote replication working from my MariaDB Galera
> Cluster in the following way:
>
> ·         MariaDB Galera Cluster replicates to a remote MariaDB DR node
> via standard master slave method using MariaDB GTID
>
> o   Pick a master node from the cluster
>
> o   Take a backup with xtrabackup-v2
>
> o   Apply backup to slave
>
> o   Connect the slave to the master and replicate using MariaDB GTID
>
> o   If master goes down, switch master to another node in the Galera
> Clutser
>
>
>
>
>
> However I am having problems keeping the GTID in step across all the nodes
> in the Galera cluster when joining new nodes or re-joining existing nodes.
>
>
>
> Using the latest version of xtrabackup-v2 the current GTID position is
> stored in a file as part of the backup, however it does not apply this
> value to the database when a node is brought into the cluster. A step by
> step example is below:
>
> ·         Cluster is running fine
>
> ·         Lots of transactions going through, enough that a new joiner
> would need an SST
>
> ·         Begin joining a new node to the cluster
>
> ·         SST via xtrabackup-v2 happens during this process
>
> ·         The GTID in the donor is 1-1-*12345*
>
> ·         SST completes joiner is now part of the cluster
>
> ·         The GTID on the newly joined node is 1-1-*1*
>
> ·         We now have an out of sync GTID meaning we cannot simply switch
> master if our current master goes down.
>
>
>
> I tried the same scenario using RSYNC as the transfer method and the GTID
> is replicated across to the joiner without issue.
>
>
>
> Ideally I would like continue using xtrabackup-V2 as my SST method because
> it does very little locking on a state transfer. That being the case are
> there any work arounds for this, such as a way to ensure the GTID is set on
> the joiner when the SST happens with xtrabackup-v2?
>
> On the MariaDB pages it does say “xtrabackup-v2  and xtrabackup SST
> methods currently do not support GTID” is this up-to-date information?
> https://mariadb.com/kb/en/mariadb/galera-cluster-system-variables/#wsrep_sst_method
>
>
>
> Thanks,
>
> Craig
>
>
>
> Evertz UK
>
>
>
> *cbailey@xxxxxxxxxx <cbailey@xxxxxxxxxx> *
>
>
>
> *www.evertz.com <http://www.evertz.com>*
>
>
> This e-mail and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this e-mail in error please notify the
> sender (as shown above). Kindly do not reproduce, print or forward any
> material received in error, please delete it immediately. Evertz UK Limited
> (Company No. 3458137) is incorporated in England and Wales and has its
> registered office at 100 Berkshire Place, Wharfedale Road, Winnersh,
> Wokingham, Berkshire, United Kingdom, RG41 5RD. Evertz Singapore Pte
> Limited (Company No. 200817005N) is incorporated in Singapore and has its
> registered office at One Marina Boulevard, #28-00. Singapore 018989.
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-discuss
> Post to     : maria-discuss@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-discuss
> More help   : https://help.launchpad.net/ListHelp
>
-- 
Guillaume Lefranc
Remote DBA Services Manager
MariaDB Corporation