PXB 56 in galera mode should backup last binlog file

Raghu, Alexey...I have been asked to get this taken care of and have a questions or two:

1-Is this is only necessary to do within innobackupex::write_galera_info if the detected server version is PXC/PS 5.6, or is it harmless to just do it regardless of server version as long as --galera_info is specified?
2-Would it be acceptable so simply issue 'FLUSH BINARY LOGS; SHOW MASTER STATUS' to capture the current binlog filename necessary to backup instead of using any extra command line options?

Thanks

Another two quick questions...
1-Is there any benefit or desire to adding the binlog filename and/or position being captured to the galera_info file?
2-Is there a need for an explicit test case for this or could I maybe just expand out t/xb_galera_info.sh to query the server for the binlog file name and look for it within the backup set (or is that much even necessary)? I'm not too familiar with any PXC tests but would have to assume that this functionality will also get tested/proofed there as well.

Doing it for 5.6 only is better.

Sure if that works. Btw, doesn't ftwrl also do a binlog flush?
On 9 Jan 2014 02:50, "George Ormond Lorch III" <email address hidden>
wrote:

> Raghu, Alexey...I have been asked to get this taken care of and have a
> questions or two:
>
> 1-Is this is only necessary to do within innobackupex::write_galera_info
> if the detected server version is PXC/PS 5.6, or is it harmless to just do
> it regardless of server version as long as --galera_info is specified?
> 2-Would it be acceptable so simply issue 'FLUSH BINARY LOGS; SHOW MASTER
> STATUS' to capture the current binlog filename necessary to backup instead
> of using any extra command line options?
>
> Thanks
>
> --
> You received this bug notification because you are a member of Percona
> core, which is subscribed to Percona XtraBackup.
> https://bugs.launchpad.net/bugs/1250375
>
> Title:
> PXB 56 in galera mode should backup last binlog file
>
> Status in Percona XtraBackup:
> Triaged
> Status in Percona XtraBackup 2.1 series:
> Triaged
> Status in Percona XtraBackup 2.2 series:
> Triaged
>
> Bug description:
> As discussed in https://bugs.launchpad.net/percona-xtradb-
> cluster/+bug/1228304, PXB 5.6 with --galera-info will need to do one
> more step in addition:
>
> a) After it gets uuid and seqno under FTWRL, it needs to do
> 'flush binary logs' and then add the last binlog (after flush) to
> the stream.
>
> b) This is required only if binlog and gtid are enabled on that
> host.
>
> c) The binlog name prefix (ie. XXXX in XXXX.index) can be
> provided through command-line (through an option) if required since that
> is readily
> available to SST script.
>
>
> =================================================================================
>
> This is required for Xtrabackup SST in 5.6 to support gtid (without
> gtid it works fine).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/percona-xtrabackup/+bug/1250375/+subscriptions
>

I don't see any benefit from that, need to check further.
On 9 Jan 2014 03:10, "George Ormond Lorch III" <email address hidden>
wrote:

> Another two quick questions...
> 1-Is there any benefit or desire to adding the binlog filename and/or
> position being captured to the galera_info file?
> 2-Is there a need for an explicit test case for this or could I maybe just
> expand out t/xb_galera_info.sh to query the server for the binlog file name
> and look for it within the backup set (or is that much even necessary)? I'm
> not too familiar with any PXC tests but would have to assume that this
> functionality will also get tested/proofed there as well.
>
> --
> You received this bug notification because you are a member of Percona
> core, which is subscribed to Percona XtraBackup.
> https://bugs.launchpad.net/bugs/1250375
>
> Title:
> PXB 56 in galera mode should backup last binlog file
>
> Status in Percona XtraBackup:
> Triaged
> Status in Percona XtraBackup 2.1 series:
> Triaged
> Status in Percona XtraBackup 2.2 series:
> Triaged
>
> Bug description:
> As discussed in https://bugs.launchpad.net/percona-xtradb-
> cluster/+bug/1228304, PXB 5.6 with --galera-info will need to do one
> more step in addition:
>
> a) After it gets uuid and seqno under FTWRL, it needs to do
> 'flush binary logs' and then add the last binlog (after flush) to
> the stream.
>
> b) This is required only if binlog and gtid are enabled on that
> host.
>
> c) The binlog name prefix (ie. XXXX in XXXX.index) can be
> provided through command-line (through an option) if required since that
> is readily
> available to SST script.
>
>
> =================================================================================
>
> This is required for Xtrabackup SST in 5.6 to support gtid (without
> gtid it works fine).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/percona-xtrabackup/+bug/1250375/+subscriptions
>

As I understand from discussion at https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1228304, the only purpose of copying the last binlog file is to get GTID info from it later. It's not clear what precisely is required by Galera, but I assume it is Executed_Gtid_Set which is later assigned to gtid_purged.

XtraBackup stores Executed_Gtid_set (if available) in the xtrabackup_binlog_info file. I understand that other SST methods do not provide GTID sets and thus copying the last binlog file is a workaround for that limitation. But does XtraBackup really need to do that?

As discussed on IRC, the problem with reading the GTID info from xtrabackup_binlog_info is that it would require XtraBackup-specific changes to wsrep/mysqld part of PXC. And Galera developers prefer all SST methods to be identical (in this case, identically ugly).

So we will implement this request. But, as this is a PXC 5.6 specific hack, this is how it should work:

- in write_galera_info(), get Executed_Gtid_Set in the same way it is done in write_binlog_info()
- *if* Executed_Gtid_Set is defined (this automatically restricts functionality changes to PXC 5.6 with GTID enabled), do the following:
- execute FLUSH BINARY LOGS to create an empty log file
- get the current binary log file name from SHOW MASTER STATUS
- get the binary logs base directory by splitting the directory name from 'log_bin_basename'. Use File::Basename::dirname($mysql{vars}->{log_bin_basename}->{Value}.
- store $log_bin_dir/$log_bin_file into the backup

I don't think we need a new option to control that functionality.

Regarding the test case, I think we need a new test, because unlike xb_galera_info we want to restrict it to PXC 5.6 (i.e. it should contain "require_galera" and "require_server_version_higher_than 5.6.0".

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-150