Kristian, Unfortunately this doesn't work as expected. I took 10.0-base r3685. Started new just bootstrapped server with server_id = 1. It has @@global.gtid_binlog_pos, @@global.gtid_slave_pos and @@global.gtid_current_pos empty. Then I execute set global gtid_binlog_state = '0-10-10' After that @@global.gtid_binlog_pos = '0-10-10' as expected, but both @@global.gtid_slave_pos and @@global.gtid_current_pos are still empty. Because of that server won't be able to replicate from master. If I set gtid_binlog_state to '0-1-10' though @@global.gtid_current_pos changes to '0-1-10' and everything is fine. It looks like the problem is in the server_id check in the first loop in rpl_slave_state::iterate(). Can it be removed from there? Pavel On Thu, Aug 22, 2013 at 1:26 PM, Pavel Ivanov <pivanof@google.com> wrote:
Thank you.
Quick note: Sys_var_gtid_binlog_state::global_update() has label "err" in the wrong place -- it tries to free "data" before it's allocated.
And as I picked up rev 3682 from 10.0-base it also has problems: New variables "rev" and "glev" in the write_ignored_events_info_to_relay_log should be initialized to NULL. For the new code in Gtid_list_log_event::Gtid_list_log_event() instead of "#ifdef MYSQL_SERVER" you probably wanted to write "#if defined(MYSQL_SERVER) && defined(HAVE_REPLICATION)" or "#if defined(MYSQL_SERVER) && !defined(EMBEDDED_LIBRARY)".
Pavel
On Thu, Aug 22, 2013 at 7:27 AM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
Kristian Nielsen <knielsen@knielsen-hq.org> writes:
If you have time to test this then that would be a nice help. I'll see if I can come up with a quick patch (ie. later today or tomorrow).
Please try this patch and let me know if you find any issues. I still need to implement test cases, but it seems to work from quick manual testing.
If you use this to save and restore the internal binlog state across deleting the binlogs, you should be able to have things work the same as if FLUSH LOGS + PURGE BINARY LOGS had been used, and avoid all the small issues that were caused by the deletion of the binlogs.
I've attached the patch and also appended some text that I indend to add to the documentation.
- Kristian.
----------------------------------------------------------------------- Variable: gtid_binlog_state Scope: global Dynamic: Yes Type: String
The variable gtid_binlog_state holds the internal state of the binlog. The state consists of the last GTID ever logged to the binary log for every combination of domain_id and server_id. This information is used by the master to determine whether a given GTID has been logged to the binlog in the past, even if it has later been deleted due to binlog purge.
Normally this internal state is not needed by users, as @@gtid_binlog_pos is more useful in most cases. The main usage of @@gtid_binlog_state is to restore the state of the binlog after RESET MASTER (or equivalently if the binlog files are lost). If the value of @@gtid_binlog_state is saved before RESET MASTER and restored afterwards, the master will retain information about past history, same as if PURGE BINARY LOGS had been used (of course the actual events in the binary logs are lost).
Note that to set the value of @@gtid_binlog_state, the binary log must be empty, that is it must not contain any GTID events and the previous value of @@gtid_binlog_state must be the empty string. If not, then RESET MASTER must be used first to erase the binary log first.
For completeness, note that setting @@gtid_binlog_state internally executes a RESET MASTER. This is normally not noticable as it can only be changed when the binlog is empty of GTID events. However, if executed eg. immediately after upgrading to MariaDB 10, it is possible that the binlog is non-empty but without any GTID events, in which case all such events will be deleted, just as if RESET MASTER had been run. -----------------------------------------------------------------------