在基于MySQL逻辑复制原理的下的主从架构，经常会由于某些缘故产生主从数据不一致，从而导致主从复制进程报错中断。而基于定期去检查从库的show slave status\G的IO线程和SQL线程的状态，只能确认当前replication是正常的，却无法确认当前主从数据是否一致。幸好percona公司提供pt工具包，其中的pt-table-checks
在实际环境中，时不时需要备份恢复单个或多个表（注意：这里除非明确指定，所说的表一律指InnoDB表），而对于innodb引擎恢复单个表需要整体的恢复，xtrabackup也可以单个表恢复，只不过是用的正则过滤的，不知最新版本是否支持表空间传输特性。本文将要说说怎么移动或复制部分或全部的表到另一台服务器上，而所要用到的技术点就是transportable tablespace特性，这就意味着MySQ
创建测试表，其建表语句如下：mysql> show create table test1;+-------+-----------------------------------------------------------------------------------------------------------------------------------------------
pt-online-schema-change工具依赖于触发器的机制去实现表的无锁DDL。那我们试想在一主一从的情况下，有个大表需要执行DDL操作，为了验证该操作的执行时长，先用pt-online-schema-change工具在从库上执行变更。确认没有问题后再在主库上执行变更。当然，在执行之前是需要开启会话级的sql_log_bin=0以避免记录到binlog。但是我们从官方文档中获知如下：很明
MySQL数据库的二进制日志binlog记录了对数据库的全量DDL和DML操作，对数据库的point to point灾难恢复起着无法替代的关键作用。因此，基于此类考虑，需要对生产环境产生的binlog做好相应的备份措施。 这里主要谈及2种备份方法，一种通过脚本定时调度的方式，强行切换binlog，增量备
mysql的binlog日志是维系mysql主从同步的重要媒介。binlog日志对SQL记录策略，直接影响到主从之间的数据一致性。接下来我们来实验下，看看mysql对事务表和非事务表的DML操作，binlog是如何记录的。 实验环境：mysql官方社区版5.7.18， 操作系统centos7.3，binl
大家都知道，在运行mysql服务的服务器上，linux系统的内存numa特性是强烈建议关闭的。因为这种特性很容易引起内存泄漏的情况：即发现物理内存还有剩余，但是系统已经开始使用swap内存。 numa内存特性：
转载自：http://blog.sina.com.cn/s/blog_6d39dc6f0100m7eo.html1.1 获得当前日期+时间（date + time）函数：now()除了 now() 函数能获得当前的日期时间外，MySQL 中还有下面的函数：current_timestamp() curre
如果线上的MySQL生产数据库的数据被误删除，然后DBA去会恢复数据的时候，发现该数据库没有做备份、binlog也没有开启的话。还有其他手段去尽力去恢复数据吗？ percona公司提供了一个非常规的修复工具，可以去修复表数据。当然这个工具是有限制的：1、仅针对innodb引擎的表 2、表的row_format必须是REDUNDANT或者COMPACT
生产环境的MySQL是通过crontab的方式，定时调度热备脚本备份数据。目前是通过XtraBackup软件实现热备。关于热备脚本方面，请查看我原先的博客《使用shell实现mysql自动全备、增备&日志备份》：http://linzhijian.blog.51cto.com/1047212/1891745 ，这里不再展开说明。 &
数据库层面：应用系统层面优化SQL优化SQL优化一般通过分析慢查询日志来抓取长事务高消耗的sql，通过结合具体业务，对sql逻辑进行分析and精简，or重写sql。通过配置slow_query_log=1和log_queries_not_using_indexes=1启动慢查询日志记录和记录下没有使用索引的查询,后者会让慢查询日志文件很快膨胀，需要定时对文件进行切割。分析慢日志的工具一般使用pt工
mysql5.6和mysql5.7对online DDL做了大幅度功能增强，但是仍然存在主库执行DDL，从库存在大幅延迟的情况，故目前生产环境还是通过pt-online-schema-change工具来实现online DDL。但是pt-online-schema-change的使用是否就没有限制呢？ 先看看官方文
基于GTID的主从replication并配合MHA搭建高可用架构，请参考之前的博客：http://linzhijian.blog.51cto.com/1047212/1906434。这里只叙述如何在此基础上增加maxscale中间件，实现读写分离的功能。 MaxScale是maridb开发的一个MyS
从一个国外的博客找到的资料：http://wendal.net/461.html SELECT t.TABLE_SCHEMA AS `db`, t.TABLE_NAME AS `table`, s.INDEX_NAME AS `index name`, s.COLUMN_NAME AS `FIELD
前阵回收生产帐号的访问范围，即之前是xxx@"%"的帐号命名方式，修改成若干个以前端应用部署的机器IP为准，修改成xxx@"IP address"。尽量减少不可信客户端连接数据库的情况发生，加强数据安全。 但是回收xxx@"%"帐号后发现，生产一
mysqlpump是mysql5.7.8版本后特有的逻辑备份工具，相对于mysqldump和mysqldumper，mysqlpump拥有更多特性，官方文档的描述如下：mysqlpump features include: Parallel processing of databases, and of o
1. XA-2PC (two phase commit, 两阶段提交 )XA是由X/Open组织提出的分布式事务的规范(X代表transaction; A代表accordant？)。XA规范主要定义了(全局)事务管理器(TM: Transaction Manager)和(局部)资源管理器(RM: Resource Manager)之间的接口。XA为了实现分布式事务，将事务的提交分成了两个阶段：
1 主从一致性加强支持在事务commit前等待ACK新版本的semi sync 增加了rpl_semi_sync_master_wait_point参数 来控制半同步模式下 主库在返回给会话事务成功之前提交事务的方式。该参数有两个值：AFTER_COMMIT（5.6默认值） master将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，同时主
由于mysql5.6社区版没有企业版特有的audit审计插件，最近需要对生产的mysql数据库增加审计功能，在考虑了percona、maridb和macfee3个版本的audit，最终选择了较为熟悉的percona版。 这里注意下，最好采用同一子版本的PXC的audit_log.so文件，即下载PXC的二
innodb引擎多版本控制分析，参考资料：http://hedengcheng.com/?p=148
命令行下具体用法如下： mysqldump -u用戶名 -p密码 -d 数据库名 表名 脚本名; 1、导出数据库为dbname的表结构（其中用戶名为root,密码为dbpasswd,生成的脚本名为db.sql） mysqldump -uroot -pdbpasswd -d dbname >db.sql;&nb
一、环境部署：mysql1:192.168.110.131 作为mastermysql2:192.168.110.132 作为slavemysql3:192.168.110.130 作为slave，同时作为MHA的管理机虚拟IP：192.168.110.100二、mysql主从环境搭建和MHA安装1、mysql主从搭建自行搭建
mysql权限分为全局权限、库权限、表权限，对应于mysql库里面的user表、db表、tables_priv表。grant all privileges on *.* :操作mysql.user表grant all privileges on db.* :操作mysql.db表grant all privileges on db.table :操作mysql.tables
今天从库crash重启后出现很有趣的现象： 可以发现： Retrieved_Gtid_Set值显示从库没有接收到部分事务，丢失了部分事务。但是从Executed_Gtid_Set显示从库没有丢失事务。
mysql5.6升级5.7
数据库热备脚本： vim backup.sh #!/bin/sh time=`date "+%Y%m%d_%H%M%S"` host=`hostname` week=`date +%w` monitor="/home/mysql/monitor/mysql_hotbackup_status.txt" ##zabbix监
基于ext4文件系统的mysql服务器，通过iotop发现，有个jbd2进程占用大量的IO资源，而非mysql进程自身消耗的IO导致。如图所示：进程jbd2占用了部分IO，导致数据盘IO异常繁忙。网络上的解决方法如下：先给出解决方案，处理此问题的优先级为：1、yum update kernel 用yum升级系统内核，重启之后查看是否有效；2、缓解方法：修改commit值，降低文件系统提交次数或者禁
mysql5.6 GTID 复制
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
