十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
首先介绍下 pt-stalk,它是 Percona-Toolkit 工具包中的一个工具,说起 PT 工具包大家都不陌生,平时常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于这个工具包,这里就不多介绍了。
创新互联公司是一家以网络技术公司,为中小企业提供网站维护、成都网站建设、成都网站制作、网站备案、服务器租用、申请域名、软件开发、小程序制作等企业互联网相关业务,是一家有着丰富的互联网运营推广经验的科技公司,有着多年的网站建站经验,致力于帮助中小企业在互联网让打出自已的品牌和口碑,让企业在互联网上打开一个面向全国乃至全球的业务窗口:建站联系电话:18980820575
pt-stalk 的主要功能是在出现问题时收集 OS 及 MySQL 的诊断信息,这其中包括:
1. OS 层面的 CPU、IO、内存、磁盘、网络等信息;
2. MySQL 层面的行锁等待、会话连接、主从复制,状态参数等信息。
而且 pt-stalk 是一个 Shell脚本,对于我这种看不懂 perl 的人来说比较友好,脚本里面的监控逻辑与监控命令也可以拿来参考,用于构建自己的监控体系。
三、使用
接着我们来看下如何使用这个工具。
pt-stalk 通常以后台服务形式监控 MySQL 并等待触发条件,当触发条件时收集相关诊断数据。
触发条件相关的参数有以下几个:
function:
∘ 默认为 status,代表监控 SHOW GLOBAL STATUS 的输出;
∘ 也可以设置为 processlist,代表监控 show processlist 的输出;
variable:
∘ 默认为 Threads_running,代表 监控参数,根据上述监控输出指定具体的监控项;
threshold:
∘ 默认为 25,代表 监控阈值,监控参数超过阈值,则满足触发条件;
∘ 监控参数的值非数字时,需要配合 match 参数一起使用,如 processlist 的 state 列;
cycles:
∘ 默认为 5,表示连续观察到五次满足触发条件时,才触发收集;
连接参数:host、password、port、socket。
其他一些重要参数:
iterations:该参数指定 pt-stalk 在触发收集几次后退出,默认会一直运行。
run-time:触发收集后,该参数指定收集多长时间的数据,默认 30 秒。
sleep:该参数指定在触发收集后,sleep 多久后继续监控,默认 300 秒。
interval:指定状态参数的检查频率,判断是否需要触发收集,默认 1 秒。
dest:监控数据存放路径,默认为 /var/lib/pt-stalk。
retention-time :监控数据保留时长,默认 30 天。
daemonize:以后台服务运行,默认不开启。
log:后台运行日志,默认为 /var/log/pt-stalk.log。
collect:触发发生时收集诊断数据,默认开启。
∘ collect-gdb:收集 GDB 堆栈跟踪,需要 gdb 工具。
∘ collect-strace:收集跟踪数据,需要 strace 工具。
∘ collect-tcpdump:收集 tcpdump 数据,需要 tcpdump 工具。
在MySQL5.5之前,MySQL 的复制是异步操作,主库和从库的数据之间存在一定的延迟,这样存在一个隐患:当在主库上写入一个事务并提交成功,而从库尚未得到主库推送的Binlog日志时,主库宕机了,例如主库可能因磁盘损坏、内存故障等造成主库上该事务Binlog丢失,此时从库就可能损失这个事务,从而造成主从不一致。
为了解决这个问题, MySQL5.5引人了半同步复制机制。
在MySQL 5.5之前的异步复制时,主库执行完 Commit提交操作后,在主库写入 Binlog日志后即可成功返回客户端,无需等待Binlog日志传送给从库,如图31-7所示。
而半同步复制时,为了保证主库上的每一个 Binlog 事务都能够被可靠的复制到从库上,主库在每次事务成功提交时,并不及时反馈给前端应用用户,而是等待其中一个从库也接收到 Binlog事务并成功写入中继日志后,主库才返回Commit操作成功给客户端。 半同步复制保证了事务成功提交后,至少有两份日志记录 ,一份在主库的 Binlog日志上,另一份在至少一个从库的中继日志Relay Log 上,从而更进一步保证了数据的完整性。半同步复制的大致流程如图31-8所示。
半同步复制模式下,假如在图31-8的步骤1、2、3中的任何一个步骤中主库宕机,则事务并未提交成功,从库上也没有收到事务对应的 Binlog日志,所以主从数据是一致的;
假如在步骤4传送 Binlog日志到从库时,从库宕机或者网络故障,导致 Binlog并没有及时地传送到从库上,此时主库上的事务会等待一段时间(时间长短由参数rpl_semi_sync_master_timeout设置的毫秒数决定),如果 Binlog 在这段时间内都无法成功推送到从库上,则 MySQL自动调整复制为异步模式,事务正常返回提交结果给客户端。
半同步复制很大程度上取决于主从库之间的网络情况,往返时延RTT 越小决定了从库的实时性越好。通俗地说,主从库之间网络越快,从库越实时。
半同步模式是作为MySQL5.5的一个插件来实现的,主库和从库使用不同的插件。安装比较简单,在上一小节异步复制的环境上,安装半同步复制插件即可。
1、首先,判断MySQL服务器是否支持动态增加插件:
2、安装插件
3、可以查看到已安装的插件
4、在安装完插件后,半同步复制默认是关闭的,这时需设置参数来开启半同步
主:
从:
以上的启动方式是在命令行操作,也可写在配置文件中。
主:
从:
4、重启从上的IO线程
从:
如果没有重启,则默认还是异步复制,重启后,slave会在master上注册为半同步复制的slave角色。这时候,主的error.log中会打印如下信息:
查看半同步是否在运行
主:
从:
这两个变量常用来监控主从是否运行在半同步复制模式下。至此,MySQL半同步复制搭建完毕~
来做个实验,观察半同步状态参数的变化。
1、在主库上insert一条记录,观察下变化;
Rpl_semi_sync_master_net_waits加1,说明刚才的insert已经发送到从机并且主机还接收到从机的反馈响应;
2、我们将从机mysql停止,再次在主机上进行insert后查看状态
可以看到,主机进行insert阻塞了10秒才返回结果。Rpl_semi_sync_master_status变为OFF,Rpl_semi_sync_master_no_tx加1,说明这条insert没有同步到从机。后面再一次执行了insert立马返回了结果,说明此时已经降级为异步复制;Rpl_semi_sync_master_no_tx也是增加了1;
3、现在恢复启动从机,再次在主机上进行insert后查看状态
Rpl_semi_sync_master_status还是OFF,Rpl_semi_sync_master_no_tx又增加了1。说明从库重启并不会自动恢复为原来的半同步复制,需要手动操作:
主 SET GLOBAL rpl_semi_sync_master_enabled = 1;
从 SET GLOBAL rpl_semi_sync_slave_enabled = 1; STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
上面是从机重启后的变化,那么主到从之间的网络问题呢,我们可以利用防火墙来模拟。
对于全同步复制,当主库提交事务之后,所有的从库节点必须收到,APPLY并且提交这些事务,然后主库线程才能继续做后续操作。这里面有一个很明显的缺点就是,主库完成一个事务的时间被拉长,性能降低。
有两种方法,一种方法使用mysql的check table和repair table 的sql语句,另一种方法是使用MySQL提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。
1. check table 和 repair table
登陆mysql 终端:
mysql -uxxxxx -p dbname
check table tabTest;
如果出现的结果说Status是OK,则不用修复,如果有Error,可以用:
repair table tabTest;
进行修复,修复之后可以在用check table命令来进行检查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk适用于MYISAM类型的数据表,而isamchk适用于ISAM类型的数据表。这两条命令的主要参数相同,一般新的系统都使用MYISAM作为缺省的数据表类型,这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用:
myisamchk tablename.MYI
进行检测,如果需要修复的话,可以使用:
myisamchk -of tablename.MYI
关于myisamchk的详细参数说明,可以参见它的使用帮助。需要注意的时在进行修改时必须确保MySQL服务器没有访问这个数据表,保险的情况下是最好在进行检测时把MySQL服务器Shutdown掉。
另外可以把下面的命令放在你的rc.local里面启动MySQL服务器前:
[ -x /tmp/mysql.sock ] /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI
其中的/tmp/mysql.sock是MySQL监听的Sock文件位置,对于使用RPM安装的用户应该是/var/lib/mysql/mysql.sock,对于使用源码安装则是/tmp/mysql.sock可以根据自己的实际情况进行变更,而pathtochk则是myisamchk所在的位置,DATA_DIR是你的MySQL数据库存放的位置。
需要注意的时,如果你打算把这条命令放在你的rc.local里面,必须确认在执行这条指令时MySQL服务器必须没有启动!检测修复所有数据库(表)
1 下载官方文档、2 建议你看你本书:使用:
MySQL必知必会
MySQL Cookbook 第2版
优化:
高性能MySQL(第二版) 复制监控:
高可用MySQL:构建健壮的数据中心 源代码:
深入理解MySQL
深入理解MySQL核心技术
MySQL技术内幕InnoDB存储引擎
Online DDL 工具:pt-osc
对于 MySQL Online DDL 目前主流的有三种工具:
原生 Online DDL;
pt-osc(online-schema-change),
gh-ost
本文主要讲解 pt-online-schema-change 的使用以及三种工具的简单对比。
一、原理及限制
1.1 原理
1. 创建一个与原表结构相同的空表,表名是 _new 后缀;
2. 修改步骤 1 创建的空表的表结构;
3. 在原表上加三个触发器:delete/update/insert,用于 copy 数据过程中,将原表中要执行的语句在新表中执行;
4. 将原表数据以数据块(chunk)的形式 copy 到新表;
5. rename 原表为 old 表,并把新表 rename 为原表名,然后删除旧表;
6. 删除触发器。
1、打开navicat软件,打开要复制表的数据库,如下图所示:
2、点击上方的“工具-数据传输”,如下图所示:
3、进去之后,左边选择的是要复制的表的数据库,右边选择的将表复制到目标数据库,如下图所示:
4、打开左边数据库对象中的“表”,选择要复制哪几张表,点击开始。
5、点击开始,会弹出一个框,点击是,等待一下,出现如下界面,复制成功,点击“关闭”。
6、可以看到表已经复制到另外一个数据库上了,如下图所示: