GTID = source_id:transaction_id

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5

3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5:11-18,
2C256447-3F0D-431B-9A12-575BB20C1507:1-27

mysql> show global variables like 'gtid%';
+----------------------+----------------------------------------------+
| Variable_name        | Value                                        |
+----------------------+----------------------------------------------+
| gtid_deployment_step | OFF                                          |
| gtid_executed        | e10c75be-5c1b-11e6-ab7c-000c29603333:1-29358 |
| gtid_mode            | ON                                           |
| gtid_owned           |                                              |
| gtid_purged          | e10c75be-5c1b-11e6-ab7c-000c29603333:1-29288 |
+----------------------+----------------------------------------------+
5 rows in set (0.05 sec)

mysql> show  variables like 'gtid_next';
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| gtid_next     | AUTOMATIC |
+---------------+-----------+
1 row in set (0.00 sec)

mysql> show master status;
+---------------+----------+--------------+------------------+----------------------------------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                            |
+---------------+----------+--------------+------------------+----------------------------------------------+
| binlog.000008 |     2522 |              |                  | e10c75be-5c1b-11e6-ab7c-000c29603333:1-29370 |
+---------------+----------+--------------+------------------+----------------------------------------------+
1 row in set (0.00 sec)

mysql> set gtid_next='e10c75be-5c1b-11e6-ab7c-000c29603333:29374';
Query OK, 0 rows affected (0.00 sec)

mysql> begin;commit;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.03 sec)

mysql> set gtid_next='AUTOMATIC';
Query OK, 0 rows affected (0.00 sec)

mysql> show master status;
+---------------+----------+--------------+------------------+----------------------------------------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                                  |
+---------------+----------+--------------+------------------+----------------------------------------------------+
| binlog.000008 |     2715 |              |                  | e10c75be-5c1b-11e6-ab7c-000c29603333:1-29370:29374 |
+---------------+----------+--------------+------------------+----------------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into tba1 values(1);
Query OK, 1 row affected (0.01 sec)

mysql> show master status;
+---------------+----------+--------------+------------------+----------------------------------------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                                  |
+---------------+----------+--------------+------------------+----------------------------------------------------+
| binlog.000008 |     2953 |              |                  | e10c75be-5c1b-11e6-ab7c-000c29603333:1-29371:29374 |
+---------------+----------+--------------+------------------+----------------------------------------------------+
1 row in set (0.00 sec)

The generation and lifecycle of a GTID consists of the following steps:

A transaction is executed and committed on the master.

This transaction is assigned a GTID using the master's UUID and the smallest nonzero transaction sequence number 
not yet used on this server; the GTID is written to the master's binary log (immediately preceding 
the transaction itself in the log).

After the binary log data is transmitted to the slave and stored in the slave's relay log (using established 
mechanisms for this process—see Section 17.2, “Replication Implementation”, for details), the slave reads 
the GTID and sets the value of its gtid_next system variable as this GTID. This tells the slave that 
the next transaction must be logged using this GTID.

The slave sets gtid_next in a session context.

The slave checks to make sure that this GTID has not already been used to log a transaction in its own binary log.
 If and only if this GTID has not been used, the slave then writes the GTID and applies the transaction 
(and writes the transaction to its binary log). By reading and checking the transaction's GTID first, 
before processing the transaction itself, the slave guarantees not only that no previous transaction 
having this GTID has been applied on the slave, but also that no other session has already read this GTID 
but has not yet committed the associated transaction. In other words, multiple clients are not permitted to 
apply the same transaction concurrently.
	
Because gtid_next is not empty, the slave does not attempt to generate a GTID for this transaction but instead 
writes the GTID stored in this variable—that is, the GTID obtained from the master—immediately preceding the 
transaction in its binary log.

UNION(@@global.gtid_executed, Retrieved_gtid_set - last_received_GTID)

relay_log_info_repository      = TABLE
relay_log_recovery             = ON

sync_binlog                    = 1
innodb_flush_log_at_trx_commit = 1
relay_log_recovery             = ON

relay_log_info_repository      = TABLE
relay_log_recovery             = ON

sync_binlog                    = 1
innodb_flush_log_at_trx_commit = 1
relay_log_recovery             = ON

---------------------------------
2016-10-26 21:00:23 2699 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=mysql-relay-bin' to avoid this problem.
2016-10-26 21:00:24 2699 [Note] Slave: MTS group recovery relay log info based on Worker-Id 1, group_relay_log_name ./mysql-relay-bin.000011, group_relay_log_pos 2017523 group_master_log_name binlog.000007, group_master_log_pos 2017363
2016-10-26 21:00:24 2699 [ERROR] Error looking for file after ./mysql-relay-bin.000012.
2016-10-26 21:00:24 2699 [ERROR] Failed to initialize the master info structure
2016-10-26 21:00:24 2699 [Note] Check error log for additional messages. You will not be able to start replication until the issue is resolved and the server restarted.
2016-10-26 21:00:24 2699 [Note] Event Scheduler: Loaded 0 events
2016-10-26 21:00:24 2699 [Note] mysqld: ready for connections.
Version: '5.6.31-77.0-log'  socket: '/data/mysql/mysql.sock'  port: 3306  Percona Server (GPL), Release 77.0, Revision 5c1061c
---------------------------------

mysql> start slave;
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

reset slave;
change master to MASTER_AUTO_POSITION = 1
start slave;

Last_SQL_Errno: 1594
Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible 
reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog'
 on the binary log), the slave's relay log is corrupted (you can check this by running 
'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL
 code. If you want to check the master's binary log or slave's relay log, you will be able to 
know their names by issuing 'SHOW SLAVE STATUS' on this slave.

sync_binlog                    = 1
innodb_flush_log_at_trx_commit = 1

Rpl_slave.cc
static int request_dump(THD *thd, MYSQL* mysql, Master_info* mi,
                        bool *suppress_warnings)
{
...
  enum_server_command command= mi->is_auto_position() ?
    COM_BINLOG_DUMP_GTID : COM_BINLOG_DUMP;
...
  if (command == COM_BINLOG_DUMP_GTID)
  {
...
    if (gtid_executed.add_gtid_set(mi->rli->get_gtid_set()) != RETURN_STATUS_OK ||
        gtid_executed.add_gtid_set(gtid_state->get_logged_gtids()) !=
        RETURN_STATUS_OK)                     //生成的gtid_executed和Retrieved_Gtid_Set的并集
    {
      global_sid_lock->unlock();
      goto err;
    }
...
    /*
      Note: binlog_flags is always 0.  However, in versions up to 5.6
      RC, the master would check the lowest bit and do something
      unexpected if it was set; in early versions of 5.6 it would also
      use the two next bits.  Therefore, for backward compatibility,
      if we ever start to use the flags, we should leave the three
      lowest bits unused.
    */
    int2store(ptr_buffer, binlog_flags);
    ptr_buffer+= ::BINLOG_FLAGS_INFO_SIZE;
    int4store(ptr_buffer, server_id);
    ptr_buffer+= ::BINLOG_SERVER_ID_INFO_SIZE;
    int4store(ptr_buffer, BINLOG_NAME_INFO_SIZE);
    ptr_buffer+= ::BINLOG_NAME_SIZE_INFO_SIZE;
    memset(ptr_buffer, 0, BINLOG_NAME_INFO_SIZE);  //BINLOG文件名固定为NULL
    ptr_buffer+= BINLOG_NAME_INFO_SIZE;
    int8store(ptr_buffer, 4LL);                    //POS固定为4
    ptr_buffer+= ::BINLOG_POS_INFO_SIZE;

    int4store(ptr_buffer, encoded_data_size);
    ptr_buffer+= ::BINLOG_DATA_SIZE_INFO_SIZE;
    gtid_executed.encode(ptr_buffer);              //填充Slave的gtid_executed
    ptr_buffer+= encoded_data_size;

    command_size= ptr_buffer - command_buffer;
    DBUG_ASSERT(command_size == (allocation_size - 1));
  }
  else
  {
...

}

Rpl_master.cc
void mysql_binlog_send(THD* thd, char* log_ident, my_off_t pos,
                       const Gtid_set* slave_gtid_executed, int flags)
{
...
  bool using_gtid_protocol= slave_gtid_executed != NULL;
...
  name= search_file_name;
  if (log_ident[0])
    mysql_bin_log.make_log_name(search_file_name, log_ident);
  else
  {
    if (using_gtid_protocol)
    {
...
      Sid_map* slave_sid_map= slave_gtid_executed->get_sid_map();
      DBUG_ASSERT(slave_sid_map);
      global_sid_lock->wrlock();
      const rpl_sid &server_sid= gtid_state->get_server_sid();
      rpl_sidno subset_sidno= slave_sid_map->sid_to_sidno(server_sid);
      if (!slave_gtid_executed->is_subset_for_sid(gtid_state->get_logged_gtids(),
                                                  gtid_state->get_server_sidno(),
                                                  subset_sidno))
      {
        errmsg= ER(ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER);
        my_errno= ER_MASTER_FATAL_ERROR_READING_BINLOG;
        global_sid_lock->unlock();
        GOTO_ERR;
      }
...
      if (!gtid_state->get_lost_gtids()->is_subset(slave_gtid_executed))
      {
        errmsg= ER(ER_MASTER_HAS_PURGED_REQUIRED_GTIDS);
        my_errno= ER_MASTER_FATAL_ERROR_READING_BINLOG;
        global_sid_lock->unlock();
        GOTO_ERR;
      }
      global_sid_lock->unlock();
      first_gtid.clear();
      if (mysql_bin_log.find_first_log_not_in_gtid_set(name,
                                                       slave_gtid_executed,
                                                       &first_gtid,
                                                       &errmsg))
      {
         my_errno= ER_MASTER_FATAL_ERROR_READING_BINLOG;
         GOTO_ERR;
      }
    }
    else
      name= 0;					// Find first log
  }
...
//后面根据binlog文件名和Pos发送binlog,但在GTID模式下，从头（POS=4）读取binlog但跳过Slave已经执行过的GTID。
...
      switch (event_type)
      {
...
      case GTID_LOG_EVENT:
        if (using_gtid_protocol)
        {
...
          skip_group= slave_gtid_executed->contains_gtid(gtid_ev.get_sidno(sid_map),
                                                     gtid_ev.get_gno());
...
}

Relay_log_info::rli_init_info()
	->init_recovery() //relay_log_recovery=1的时候执行
		->mts_recovery_groups() //slave_parallel_workers>1的时候执行

int mts_recovery_groups(Relay_log_info *rli)
{
MY_BITMAP *groups= &rli->recovery_groups;
...
  for (uint it_job= 0; it_job < above_lwm_jobs.elements; it_job++) //遍历所以执行位点在lwm之后的worker（lwm也称为checkpoint，保存在slave_relay_log_info.Relay_log_pos中，lwm之前的event不存在gap）
  {
    Slave_worker *w= ((Slave_job_group *)
                      dynamic_array_ptr(&above_lwm_jobs, it_job))->worker;
    LOG_POS_COORD w_last= { const_cast<char*>(w->get_group_master_log_name()),
                            w->get_group_master_log_pos() };
...
      while (not_reached_commit &&
             (ev= Log_event::read_log_event(&log, 0, p_fdle,
                                            opt_slave_sql_verify_checksum)))
      {
...
          LOG_POS_COORD ev_coord= { (char *) rli->get_group_master_log_name(),
                                      ev->log_pos };
...
          if ((ret= mts_event_coord_cmp(&ev_coord, &w_last)) == 0) //找到worker执行位点对应的relay记录，分配给这个worker的从checkpoint到这个位点的event都已经应用了，设置rli->recovery_groups。
          {
...
            DBUG_PRINT("mts",
                       ("Doing a shift ini(%lu) end(%lu).",
                       (w->checkpoint_seqno + 1) - recovery_group_cnt,
                        w->checkpoint_seqno));

            for (uint i= (w->checkpoint_seqno + 1) - recovery_group_cnt,
                 j= 0; i <= w->checkpoint_seqno; i++, j++)
            {
              if (bitmap_is_set(&w->group_executed, i))
              {
                DBUG_PRINT("mts", ("Setting bit %u.", j));
                bitmap_fast_test_and_set(groups, j);
              }
            }
            not_reached_commit= false;
          }

...
      if (not_reached_commit && rli->relay_log.find_next_log(&linfo, 1)) //由于crash时relay log不全，找不到完整的事务记录，报错！
      {
         error= TRUE;
         sql_print_error("Error looking for file after %s.", linfo.log_file_name);
         goto err;
      }
...
}

  This may happen because the gap is not persitent stored anywhere
  and eventually old relay log files will be removed and further
  calculations on the gaps will be impossible.

  We need to improve this. /Alfranio.
*/
error= mts_recovery_groups(rli);
if (rli->mts_recovery_group_cnt)
{
  if (gtid_mode == GTID_MODE_ON)
  {
    rli->recovery_parallel_workers= 0;
    rli->clear_mts_recovery_groups(); //清空rli->recovery_groups
  }
  else
  {
    error= 1;
    sql_print_error("--relay-log-recovery cannot be executed when the slave "
                    "was stopped with an error or killed in MTS mode; "
                    "consider using RESET SLAVE or restart the server "
                    "with --relay-log-recovery = 0 followed by "
                    "START SLAVE UNTIL SQL_AFTER_MTS_GAPS");
  }
}   } ... }