gh-ost

本文是使用 golang 实现 redis 系列的第四篇文章，将介绍如何使用 golang 实现 Append Only File 持久化及 AOF 文件重写。 本文完整源代码在作者Github HDT3213/godis AOF 文件 AOF 持久化是典型的异步任务，主协程(goroutine) 可以使用 channel 将数据发送到异步协程由异步协程执行持久化操作。 在 DB 中定义相关字段: type DB struct { // 主线程使用此channel将要持久化的命令发送到异步协程 aofChan chan *reply.MultiBulkReply // append file 文件描述符 aofFile *os.File // append file 路径 aofFilename string // aof 重写需要的缓冲区，将在AOF重写一节详细介绍 aofRewriteChan chan *reply.MultiBulkReply // 在必要的时候使用此字段暂停持久化操作 pausingAof sync.RWMutex } 在进行持久化时需要注意两个细节: get 之类的读命令并不需要进行持久化 expire 命令要用等效的 expireat 命令替换。举例说明，10:00 执行 expire a 3600 表示键 a 在 11:00 过期，在 10:30

背景： 作为一个DBA，大表的DDL的变更大部分都是使用Percona的 pt-online-schema-change ，本文说明下另一种工具 gh-ost 的使用：不依赖于触发器,是因为他是通过模拟从库,在row binlog中获取增量变更,再异步应用到ghost表的。在使用gh-ost之前，可以先看 GitHub 开源的 MySQL 在线更改 Schema 工具【转】 文章或则官网了解其特性和原理。本文只对使用进行说明。 说明： 1）下载安装： https://github.com/github/gh-ost/tags 2） 参数说明 ：gh-ost --help View Code 3）使用说明：条件是操作的MySQL上需要的binlog模式是ROW。如果在一个从上测试也必须是ROW模式，还要开启log_slave_updates。根据上面的参数说明按照需求进行调整。 环境：主库：192.168.163.131；从库：192.168.163.130 DDL过程 ： ① 检查有没有外键和触发器。 ② 检查表的主键信息。 ③ 检查是否主库或从库，是否开启log_slave_updates，以及binlog信息 ④ 检查gho和del结尾的临时表是否存在 ⑤ 创建ghc结尾的表，存数据迁移的信息，以及binlog信息等 ---以上校验阶段 ⑥ 初始化stream的连接

作者简介： 杨奇龙，网名“北在南方”，7年DBA老兵，目前任职于杭州有赞科技DBA，主要负责数据库架构设计和运维平台开发工作，擅长数据库性能调优、故障诊断。 一、前言 作为 MySQL DBA，相信我们大家都会对大表变更（大于10G 以上的）比较头疼，尤其是某些 DDL 会锁表，影响业务可持续性。目前通用的方案使用 Percona 公司开源的 pt-osc 工具解决导致锁表的操作，还有一款 github 基于 go 语言开发的 gh-ost。本文主要介绍 gh-ost 使用方法，其工作原理放到下一篇文章介绍。 二、使用 2.1 gh-ost 介绍 gh-ost 作为一个伪装的备库，可以从主库/备库上拉取 binlog，过滤之后重新应用到主库上去，相当于主库上的增量操作通过 binlog 又应用回主库本身，不过是应用在幽灵表上。 其大致的工作过程： gh-ost 首先连接到主库上，根据 alter 语句创建幽灵表， 然后作为一个备库连接到其中一个真正的备库或者主库上(根据具体的参数来定)，一边在主库上拷贝已有的数据到幽灵表，一边从备库上拉取增量数据的 binlog，然后不断的把 binlog 应用回主库。 等待全部数据同步完成，进行 cut-over 幽灵表和原表切换。图中 cut-over 是最后一步，锁住主库的源表，等待 binlog 应用完毕，然后替换 gh-ost 表为源表

作者：魏新平，知数堂第5期MySQL实战班学员，第10期MySQL优化班学员，现任职助教。 Describing safe, blocking, atomic, pure-mysql cut-over phase 原文链接： https://github.com/github/gh-ost/issues/82 作者：shlomi-noach 我们提供的方式是基于两个数据库连接的。假如我们的连接是C10，C20。应用的连接是C1..C9,C11..C19,C21..C29。 C1..C9在 tbl 上进行正常的dml操作:INSERT, UPDATE, DELETE C10: CREATE TABLE tbl_old (id int primary key) COMMENT='magic-be-here' C10: LOCK TABLES tbl WRITE, tbl_old WRITE C11..C19,新进来的对tbl的操作，由于C10的锁，会被阻塞 C20: RENAME TABLE tbl TO tbl_old, ghost TO tbl 由于C10加的锁，也会被阻塞住。但是当锁被释放后，会比C1..C9,C11..C19先执行。 C21..C29，新进来对tbl的dml操作还是会被阻塞住 C10: 检测C20的rename操作是否存在(在show

引言 在面试中，大家应该经历过如下场景 面试官:"用过mysql吧，你们是用自增主键还是UUID？" 你:"用的是自增主键" 面试官:"为什么是自增主键？" 你:"因为采用自增主键，数据在物理结构上是顺序存储，性能最好，blabla…" 面试官:"那自增主键达到最大值了，用完了怎么办？" 你:"what，没复习啊！！" (然后，你就可以回去等通知了！) 这个问题是一个粉丝给我提的，我觉得挺有意(KENG)思(B)! 于是，今天我们就来谈一谈，这个自增主键用完了该怎么办！ 正文 我们先明白一点，在mysql中，Int整型的范围如下 我们以无符号整型为例，存储范围为0～4294967295，约43亿！我们先说一下，一旦自增id达到最大值，此时数据继续插入是会报一个主键冲突异常如下所示: //Duplicate entry '4294967295' for key 'PRIMARY' 那解决方法也是很简单的，将Int类型改为BigInt类型，BigInt的范围如下: 就算你每秒10000条数据，跑100年，单表的数据也才 10000 24 3600 365 100=31536000000000 这数字距离BigInt的上限还差的远，因此你将自增ID设为BigInt类型，你是不用考虑自增ID达到最大值这个问题！ 然而，如果你在面试中的回答如果是: 你:"简单啊

作者简介： 杨奇龙，网名“北在南方”，7年DBA老兵，目前任职于杭州有赞科技DBA，主要负责数据库架构设计和运维平台开发工作，擅长数据库性能调优、故障诊断。 一、前言 作为 MySQL DBA，相信我们大家都会对大表变更（大于10G 以上的）比较头疼，尤其是某些 DDL 会锁表，影响业务可持续性。目前通用的方案使用 Percona 公司开源的 pt-osc 工具解决导致锁表的操作，还有一款 github 基于 go 语言开发的 gh-ost。本文主要介绍 gh-ost 使用方法，其工作原理放到下一篇文章介绍。 二、使用 2.1 gh-ost 介绍 gh-ost 作为一个伪装的备库，可以从主库/备库上拉取 binlog，过滤之后重新应用到主库上去，相当于主库上的增量操作通过 binlog 又应用回主库本身，不过是应用在幽灵表上。 其大致的工作过程： gh-ost 首先连接到主库上，根据 alter 语句创建幽灵表， 然后作为一个备库连接到其中一个真正的备库或者主库上(根据具体的参数来定)，一边在主库上拷贝已有的数据到幽灵表，一边从备库上拉取增量数据的 binlog，然后不断的把 binlog 应用回主库。 等待全部数据同步完成，进行 cut-over 幽灵表和原表切换。图中 cut-over 是最后一步，锁住主库的源表，等待 binlog 应用完毕，然后替换 gh-ost 表为源表

作者：lan 本文为 DM 源码阅读系列文章的第八篇， 上篇文章 对 DM 中的定制化数据同步功能进行详细的讲解，包括库表路由（Table routing）、黑白名单（Black & white table lists）、列值转化（Column mapping）、binlog 过滤（Binlog event filter）四个主要功能的实现。 本篇文章将会以 gh-ost 为例，详细地介绍 DM 是如何支持一些 MySQL 上的第三方 online schema change 方案同步，内容包括 online schema change 方案的简单介绍，online schema change 同步方案，以及同步实现细节。 MySQL 的 Online Schema Change 方案 目前有一些第三方工具支持在 MySQL 上面进行 Online Schema Change，比较主流的包括 pt-online-schema-change 和 gh-ost 。 这些工具的实现原理比较类似，本文会以 gh-ost 为例来进行分析讲解。 从上图可以大致了解到 gh-ost 的逻辑处理流程： 在操作目标数据库上使用 create table ghost table like origin table 来创建 ghost 表； 按照需求变更表结构，比如 add column/index ；