gh-ost使用问题记录

因为 pt-osc 对数据库性能影响较大，且容易造成死锁问题，目前我们在线更改表结构都使用 gh-ost 工具进行修改，这里记录一下使用 gh-ost 过程中的问题，以作记录；首先先复习一下gh-ost的基本实现，gh-ost的基本实现原理如下图所示：

根据源码，核心步骤如下：

1. initiateStreaming: 初始化 binlog events streaming
2. initiateApplier: 初始化 applier
3. addDMLEventsListener: 添加对指定表的binlog event过滤
4. ReadMigrationRangeValues: 获取对应表唯一索引的 min & max 值
5. executeWriteFuncs: 通过applier向ghost表写入数据, binlog event 相比 copy rows具有更高优先级
6. iterateChunks: 根据 min & max的值, 批量插入数据到 ghost 表
7. cutOver: rename & drop新旧表

问题一：gh-ost导致最新一次写操作丢失

原因分析：

在 initiateStreaming 的过程中通过 show master status 获取主节点当前的 binlog name & pos & Executed_Gtid_Set，然后通过 binlog name & pos 和当前的数据库节点建立复制通道，而后在 ReadMigrationRangeValues 的过程中通过 select min(unique_key) 和 select max(unique_key) 快照读的方式获取原表数据的范围。

问题就出在这里，根据事务的提交流程，如果sync_binlog != 1，那么 binlog name & pos 是在binlog flush阶段之后进行更新；如果 sync_binlog = 1，那么 binlog name & pos 是在 binlog sync 阶段之后进行更新，这时事务还没有在 Innodb 中完成 commit。因此，最新的一次事务对于 select min() & max() 这样的快照读是不可见的，最终造成了写操作的丢失。

如何修复：

这里有两种解决办法：1. 虽然 binlog name & pos 的信息是在 Innodb memory commit 之前进行更新，但是show master status 的 Executed_Gtid_Set 是在 Innodb memory commit 完成之后进行更新的，因此 gh-ost 可以使用 Executed_Gtid_Set 来与数据库节点建立复制通道来解决这个问题。

2. 在 ReadMigrationRangeValues 的过程中使用 select min() & max() lock in share mode 当前读来解决这个问题;

问题二：高并发写入时gh-ost无法结束：

如截图所示，Applied一直在增大，而 Copy保持不变。这是因为在通过 Applier 向 ghost 表中写数据时，binlog events apply 相比rows copy 具有更高的优先级；同时，由于 gh-ost 是通过监听 mysql binlog的方式获取增量写操作，对源MySQL节点的侵入较小；因此，在MySQL实例高并发写入时，gh-ost会忙于 apply binlog events而无法结束。

扩展一：gh-ost的cutover过程:

如上图所示，根据gh-ost  -cut-over参数的不同会选择不同的 cur-over 算法，默认是github的 atomic算法，也可以选择 facebook的 OSC算法。

atomic算法// atomicCutOver

这里为什么需要 magic_old表呢？

是为了防止lockSessionId被意外关闭后，可以阻塞rename操作。lockSessionId被意外关闭后，original table可以被写入，会造成数据不一致。至于为何要对 magic_old表加锁，我个人认为是防止magic_old表被意外删除。

源码实现如下：

func (this *Migrator) atomicCutOver() (err error) {
　　　　　// 设置 cutover 标记, 限流函数会使用此标记
	atomic.StoreInt64(&this.migrationContext.InCutOverCriticalSectionFlag, 1)
	defer atomic.StoreInt64(&this.migrationContext.InCutOverCriticalSectionFlag, 0)
　　　　　// 通知释放锁的通道
	okToUnlockTable := make(chan bool, 4)
　　　　 // 最后删除 magic old table
	defer func() {
		okToUnlockTable <- true
		this.applier.DropAtomicCutOverSentryTableIfExists()
	}()
　　　　 //
	atomic.StoreInt64(&this.migrationContext.AllEventsUpToLockProcessedInjectedFlag, 0)
　　     // 存储会话ID
	lockOriginalSessionIdChan := make(chan int64, 2)
        // 表锁定后通知通道
	tableLocked := make(chan error, 2)
        // 表锁释放后通知通道
	tableUnlocked := make(chan error, 2)
	go func() {
　　　　　　　　　　/*
　　　　　　　　　　* 在 cutover 阶段对表加锁, 共分为以下几步：
                 * 1. 打开一个新的会话，将会话ID存入 lockOriginalSessionIdChan 中
                   2. 调用 get_lock(key, timeout) 对应用进行加锁。需要一个字符串key和加锁超时等待时间，sessionA 调用 get_lock 对key加锁,
　　　　　　　　　　　　　　sessionB也调用 get_lock 对相同的key加锁会等待，直到超时或 sessionA 断开。
                   3. 通过 set session lock_wait_timeout 设置表切换锁超时时间为CutOverLockTimeoutSeconds * 2, 默认为 6s，CutOverLockTimeoutSeconds可以人为指定。
                   4. 创建 cutover 过程中的 magic old表
                   5. 通过 lock tables write 对原始表和 magic old 表加 write锁
                   6. 向 tableLocked 通道中写入nil, 通知其他协程对原表和 magic old表加锁完成，可以开始后续工作
                   7. 当前协程阻塞，通过 <- okToUnlockTable 等待 unlocks table 信号
                   8. 删除 magic old 表, 删除之后，原始表仍然处于 lock 状态
                   9. 通过 unlock tables 对表进行解锁
                   10. 解锁成功后，向 tableUnlocked 通道写入 nil, 通知其他协程
　　　　　　　　　　*/
		if err := this.applier.AtomicCutOverMagicLock(lockOriginalSessionIdChan, tableLocked, okToUnlockTable, tableUnlocked); err != nil {
			log.Errore(err)
		}
	}()
        // 这里阻塞等待原始表和 magic old 表加锁完成
	if err := <-tableLocked; err != nil {
		return log.Errore(err)
	}
        // 获取加锁的 sessionId
	lockOriginalSessionId := <-lockOriginalSessionIdChan
	log.Infof("Session locking original & magic tables is %+v", lockOriginalSessionId)
	// At this point we know the original table is locked.
	// We know any newly incoming DML on original table is blocked.
        // 这里，原始表已被锁定，原始表不会产生新的 binlog event。我们需要等待 apply 原始表的 binlog events 到最新位置，等待
        // 时间默认为 CutOverLockTimeoutSeconds(3s, 可以人为指定)
	if err := this.waitForEventsUpToLock(); err != nil {
		return log.Errore(err)
	}

	// Step 2
	// We now attempt an atomic RENAME on original & ghost tables, and expect it to block.
	this.migrationContext.RenameTablesStartTime = time.Now()
        // rename 操作是否被阻塞标志
	var tableRenameKnownToHaveFailed int64
        // 存储 rename 会话ID
	renameSessionIdChan := make(chan int64, 2)
        // rename 成功或失败后消息通知通道
	tablesRenamed := make(chan error, 2)
        // 异步的进行 rename 操作
	go func() {
                /**
　　　　　　　　　　 * rename 表操作
                    1. 打开新的 session，并将 sessionId 存入 renameSessionIdChan 中
                    2. 通过 set session lock_wait_timeout:= CutOverLockTimeoutSeconds 来设置 rename 操作超时时间
                    3. 通过 rename originalTable to magic_oldTable, ghost_table to originalTable 来进行rename操作，因为在之前对 originalTable
                       和 magic_oldTable 加有锁，正常情况下会阻塞
　　　　             4. 而后向 tablesRenamed 通道写入信息，如果rename成功写入 nil，rename失败则写入 err
　　　　　　　　　　*/
		if err := this.applier.AtomicCutoverRename(renameSessionIdChan, tablesRenamed); err != nil {
			// Abort! Release the lock
                        // 终止，释放锁
			atomic.StoreInt64(&tableRenameKnownToHaveFailed, 1)
			okToUnlockTable <- true
		}
	}()
        // 这里获取 rename sessionId
	renameSessionId := <-renameSessionIdChan
	log.Infof("Session renaming tables is %+v", renameSessionId)

	waitForRename := func() error {

		if atomic.LoadInt64(&tableRenameKnownToHaveFailed) == 1 {
			// We return `nil` here so as to avoid the `retry`. The RENAME has failed,
			// it won't show up in PROCESSLIST, no point in waiting
                        // 当 rename 操作失败时, 返回 nil避免重试。
			return nil
		}
		return this.applier.ExpectProcess(renameSessionId, "metadata lock", "rename")
	}
	// Wait for the RENAME to appear in PROCESSLIST
        // 等待 rename 操作出现在 processlist 中
	if err := this.retryOperation(waitForRename, true); err != nil {
		// Abort! Release the lock
                // 终止！ 释放锁
		okToUnlockTable <- true
		return err
	}
        // tableRenameKnownToHaveFailed = 0 表示 rename 操作被阻塞，符合预期
	if atomic.LoadInt64(&tableRenameKnownToHaveFailed) == 0 {
		log.Infof("Found atomic RENAME to be blocking, as expected. Double checking the lock is still in place (though I don't strictly have to)")
	}
        // 探测对 original table 和 magic old table 加锁的线程还继续存在, 如果不存在则无法保证数据一致性
	if err := this.applier.ExpectUsedLock(lockOriginalSessionId); err != nil {
		// Abort operation. Just make sure to drop the magic table.
		return log.Errore(err)
	}
	log.Infof("Connection holding lock on original table still exists")

	// Now that we've found the RENAME blocking, AND the locking connection still alive,
	// we know it is safe to proceed to release the lock
        // 这里 rename 操作被阻塞，并且加锁的连接仍然有效，继续释放锁是能保证数据安全的，这里通知释放锁
	okToUnlockTable <- true
	// BAM! magic table dropped, original table lock is released
	// -> RENAME released -> queries on original are unblocked.
        // 阻塞等待锁被释放
	if err := <-tableUnlocked; err != nil {
		return log.Errore(err)
	}
        // 阻塞等待 rename 操作完成 (锁被释放后rename操作会优先其他dml操作执行)
	if err := <-tablesRenamed; err != nil {
		return log.Errore(err)
	}
	this.migrationContext.RenameTablesEndTime = time.Now()

	// ooh nice! We're actually truly and thankfully done
        // 整个切换完成
	lockAndRenameDuration := this.migrationContext.RenameTablesEndTime.Sub(this.migrationContext.LockTablesStartTime)
	log.Infof("Lock & rename duration: %s. During this time, queries on %s were blocked", lockAndRenameDuration, sql.EscapeName(this.migrationContext.OriginalTableName))
	return nil
}

　　facebook OSC算法// cutOverTwoStep

cutOverTwoStep很巧妙地利用MySQL不同 session 下 alter table x rename to x1; 和 rename table x1 to x; 不同的锁机制进行 cutover，值得深入研究。

源码如下：

/*
 * cutOverTwoStep() 将阻塞原始表，等待原始表上的binlog events全部应用到 ghost 表，然后进行非原子的表rename操作，original->old, then new->original；
 * 在rename过程中，原始表不存在，查询操作将失败。
*/
func (this *Migrator) cutOverTwoStep() (err error) {
	atomic.StoreInt64(&this.migrationContext.InCutOverCriticalSectionFlag, 1)
	defer atomic.StoreInt64(&this.migrationContext.InCutOverCriticalSectionFlag, 0)
	atomic.StoreInt64(&this.migrationContext.AllEventsUpToLockProcessedInjectedFlag, 0)
　　　　　// 首先通过 lock tables write; 对原始表加锁
	if err := this.retryOperation(this.applier.LockOriginalTable); err != nil {
		return err
	}
        // 等待原始表上的 binlog events 全部应用到 ghost 表
	if err := this.retryOperation(this.waitForEventsUpToLock); err != nil {
		return err
	}
　　　　 // 1. 这里使用和 LockOriginalTable 操作相同的session来执行 alter original_table rename magic_old_table; 来重
        // 命名原表，该操作不会被 LockOriginalTable 操作加的锁阻塞，相同的 session 执行 rename table original to magic 将阻塞。
        // 2. 将 ghost 表重命名为 original 表; 这里采用在另一个 session 上执行 rename table ghost to original；来进行，因此在
        // 原 session 上执行将被锁阻塞。
	if err := this.retryOperation(this.applier.SwapTablesQuickAndBumpy); err != nil {
		return err
	}
        // 对原表解锁
	if err := this.retryOperation(this.applier.UnlockTables); err != nil {
		return err
	}

	lockAndRenameDuration := this.migrationContext.RenameTablesEndTime.Sub(this.migrationContext.LockTablesStartTime)
	renameDuration := this.migrationContext.RenameTablesEndTime.Sub(this.migrationContext.RenameTablesStartTime)
	log.Debugf("Lock & rename duration: %s (rename only: %s). During this time, queries on %s were locked or failing", lockAndRenameDuration, renameDuration, sql.EscapeName(this.migrationContext.OriginalTableName))
	return nil
}