OnlineSchemaChange

在运维MySQL数据库时，我们总会对数据表进行ddl 变更，修改添加字段或者索引，对于MySQL而言，ddl 显然是一个令所有MySQL dba 诟病的一个功能，因为在MySQL中在对表进行ddl时，会锁表，当表比较小比如小于1w上时，对前端影响较小，当时遇到千万级别的表 就会影响前端应用对表的写操作。 Perconal 推出一个工具 pt-online-schema-change，简称pt-osc，其特点是修改过程中不会造成读写阻塞。本文将简单介绍pt-osc的工作原理，安装方法及使用场景。 工作原理： 建立一个与需要操作的表相同表结构的空表 给空表执行表结构修改 在原表上增加delete/update/insert的after trigger copy数据到新表 将原表改名，并将新表改成原表名 删除原表 删除trigger。 pt-osc使用条件： 表要有主键，否则会报错。 表不能有trigger。 安装方法： 下载 wget percona.com/ get /percona-toolkit.tar.gz 编译安装 tar -zxvf percona-toolkit .tar .gz cd percona-toolkit-3 .0 .4 perl Makefile .PL (若执行 Makefile 出错 则需先执行 yum install perl-ExtUtils

来源： oschina 链接： https://my.oschina.net/liwanghong/blog/4711716

作者：xuty 本文来源：原创投稿 *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 一、概述 之前在社区发了一篇 故障分析 | 有效解决 MySQL 行锁等待超时问题 文档，主要介绍了下行锁超时的监控方法，下方评论中有人提到了 pt-stalk 工具也可以监控行锁超时，因为个人没怎么用过这个工具，所以下意识的就去 google 了一下。因为没找到有介绍具体监控输出的文档，就以为这个工具没法监控行锁等待，最后果断被打脸了。 以上是个小插曲，个人在本地测试了下 pt-stalk 的监控输出后，发现其监控项远远比我预测的多，用起来也比较方便，所以在这里分享下这个工具。 二、介绍 首先介绍下 pt-stalk ，它是 Percona-Toolkit 工具包中的一个工具，说起 PT 工具包大家都不陌生，平时常用的 pt-query-digest 、 pt-online-schema-change 等工具都是出自于这个工具包，这里就不多介绍了。 pt-stalk 的主要功能是 在出现问题时收集 OS 及 MySQL 的诊断信息 ，这其中包括： OS 层面的 CPU、IO、内存、磁盘、网络等信息； MySQL 层面的行锁等待、会话连接、主从复制，状态参数等信息。 而且 pt-stalk 是一个 Shell 脚本 ，对于我这种看不懂 perl 的人来说比较友好

MySQL中给一张千万甚至更大量级的表添加字段一直是比较头疼的问题，遇到此情况通常该如果处理？本文通过常见的三种场景进行案例说明。 1、 环境准备 数据库版本 ： 5.7.25-28（Percona 分支） 服务器配置： 3台centos 7虚拟机，配置均为2CPU 2G内存 数据库架构： 1主2从的MHA架构（为了方便主从切换场景的演示，如开启GTID，则两节点即可），关于MHA搭建可参考此文 MySQL高可用之MHA集群部署 准备测试表： 创建一张2kw记录的表，快速创建的方法可以参考 快速创建连续数 本次对存储过程稍作修改，多添加几个字段，存储过程如下： DELIMITER $$ CREATE PROCEDURE `sp_createNum`(cnt INT ) BEGIN DECLARE i INT DEFAULT 1 ; DROP TABLE if exists tb_add_columns; CREATE TABLE if not exists tb_add_columns(id int primary key ,col1 int ,col2 varchar ( 32 )); INSERT INTO tb_add_columns(id,col1,col2) SELECT i as id ,i % 7 as col1,md5(i) as col2; WHILE i <

在传统认知下，基于binlog为statement语句的复制，触发器会在slave从库上工作；而如果基于binlog为ROW行的复制，触发器不会在slave从库上工作。 With statement-based replication, triggers executed on the master also execute on the slave. With row-based replication, triggers executed on the master do not execute on the slave. 参考文献： https://dev.mysql.com/doc/refman/8.0/en/replication-features-triggers.html 在MariaDB 10.5版本里，可以通过参数 set global slave_run_triggers_for_rbr = 'ENFORCE'; 强制设置基于binlog为ROW行的复制，触发器在slave从库上工作。 这样的好处是：当你在从库上运行pt-online-schema-change修改表结构时，从库的数据和主库是一致的，可以参考我2016年写的文章 《pt-online-schema-change你今天滥用了吗？》 注：MySQL 8.0不支持。 来源： oschina 链接：

MySQL中给一张千万甚至更大量级的表添加字段一直是比较头疼的问题，遇到此情况通常该如果处理？本文通过常见的三种场景进行案例说明。 1、 环境准备 数据库版本 ： 5.7.25-28（Percona 分支） 服务器配置： 3台centos 7虚拟机，配置均为2CPU 2G内存 数据库架构： 1主2从的MHA架构（为了方便主从切换场景的演示，如开启GTID，则两节点即可），关于MHA搭建可参考此文 MySQL高可用之MHA集群部署 准备测试表： 创建一张2kw记录的表，快速创建的方法可以参考 快速创建连续数 本次对存储过程稍作修改，多添加几个字段，存储过程如下： DELIMITER $$ CREATE PROCEDURE `sp_createNum`(cnt INT ) BEGIN DECLARE i INT DEFAULT 1 ; DROP TABLE if exists tb_add_columns; CREATE TABLE if not exists tb_add_columns(id int primary key ,col1 int ,col2 varchar ( 32 )); INSERT INTO tb_add_columns(id,col1,col2) SELECT i as id ,i % 7 as col1,md5(i) as col2; WHILE i <

引言 在面试中，大家应该经历过如下场景 面试官:"用过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达到最大值这个问题！ 然而，如果你在面试中的回答如果是: 你:"简单啊

数据库设计规范 数据库设计之三大范式 要求表的每个字段必须是一个不可分割的独立的单元 在第一范式的基础上，要求每张表只表达一个意思。表中的每个字段都和主键有依赖 在第二范式基础，要求每张表的主键之外的其他字段都只能和主键有直接的决定依赖关系 数据库结构设计 逻辑设计----->物理设计 实际工作 逻辑设计 + 物理设计 物理设计 表名 字段名 字段类型 规范制定 一、数据库命名规范 所有的数据库对象名称必须使用小写字母，并且使用下划线分割，因为mysql在linux系统下是大小写敏感的。 所有的数据库对象名称禁止使用mysql保留关键字，如果一定要使用，则需要使用 from `` 括起来。 数据库对象的命名要做到见名识义，并且最好不要超过32个字符，例如 用户数据库：yy_userdb，用户账号表：user_account 所有的临时表必须以tmp_ 开头，备份表必须以bak_ 开头，并以日期为后缀，例如tmp_user_20190721，便于标识表，和后面清理数据作为依据 所有的存储相同数据的列名和列类型必须一致，一般是作为关联列使用，如果类型不一样，在做关联的时候，会做隐式的列类型转换，同时也会造成列上的索引失效，同时查询效率大幅降低 二、数据库基本设计规范 所有表必须使用Innodb存储引擎。Mysql5.5使用之前Myisam（默认存储引擎）情况（不支持事务），。原因：-1

MySQL表碎片整理 1. 计算碎片大小 2. 整理碎片 2.1 使用alter table table_name engine = innodb命令进行整理。 2.2 使用pt-online-schema-change工具也能进行在线整理表结构，收集碎片等操作。 2.3 使用optimize table命令，整理碎片。 3. 整理表碎片shell脚本 1. 计算碎片大小 要整理碎片，首先要了解碎片的计算方法。 可以通过 show table [from|in db_name] status like '%table_name%' 命令查看： mysql> show table from employees status like 't1'\G *************************** 1. row *************************** Name: t1 Engine: InnoDB Version: 10 Row_format: Dynamic Rows: 1176484 Avg_row_length: 86 Data_length: 101842944 Max_data_length: 0 Index_length: 0 Data_free: 39845888 Auto_increment: NULL Create_time: 2018-08

作者：张学程 本文为 DM 源码阅读系列文章的第九篇，在 上篇文章 中我们详细介绍了 DM 对 online schema change 方案的同步支持，对 online schema change 同步方案以及实现细节等逻辑进行了分析。 在本篇文章中，我们将对 shard DDL 同步机制以及 checkpoint 机制等进行详细的介绍，内容包括 shard group 的定义、shard DDL 的同步协调处理流程、checkpoint 机制以及与之相关的 safe mode 机制。 shard DDL 机制的实现 DM 中通过 库表路由与列值转换 功能，实现了对分库分表合并场景下 DML 的同步支持。但当需要同步的各分表存在 DDL 变更时，还需要对 DDL 的同步进行更多额外的处理。有关分表合并时 shard DDL 同步需要处理的问题以及 DM 中的同步支持原理，请先阅读 TiDB Ecosystem Tools 原理解读系列（三）TiDB-DM 架构设计与实现原理 。 shard group 在 这篇文章 中，我们介绍了 DM 在处理 shard DDL 同步时引入了两级 shard group 的概念，即用于执行分表合并同步任务的各 DM-worker 组成的 shard group、每个 DM-worker 内需要进行合表同步的各上游分表组成的 shard