在基于MySQL逻辑复制原理的下的主从架构，经常会由于某些缘故产生主从数据不一致，从而导致主从复制进程报错中断。而基于定期去检查从库的show slave status\G的IO线程和SQL线程的状态，只能确认当前replication是正常的，却无法确认当前主从数据是否一致。幸好percona公司提供pt工具包，其中的pt-table-checks
创建测试表，其建表语句如下：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内存特性：
SwingBench介绍： SwingBench由负载生成器，协调器和集群概述组成。该软件使得能够生成负载并且将图表的事务/响应时间映射。 SwingBench可用于演示和测试诸如实际应用集群，在线表重建，备用数据库，在线备份和恢复等技术 SwingBe
如果线上的MySQL生产数据库的数据被误删除，然后DBA去会恢复数据的时候，发现该数据库没有做备份、binlog也没有开启的话。还有其他手段去尽力去恢复数据吗？ percona公司提供了一个非常规的修复工具，可以去修复表数据。当然这个工具是有限制的：1、仅针对innodb引擎的表 2、表的row_format必须是REDUNDANT或者COMPACT
生产环境的MySQL是通过crontab的方式，定时调度热备脚本备份数据。目前是通过XtraBackup软件实现热备。关于热备脚本方面，请查看我原先的博客《使用shell实现mysql自动全备、增备&日志备份》：http://linzhijian.blog.51cto.com/1047212/1891745 ，这里不再展开说明。 &
测试环境：机器：192.168.110.132redis主端口：6379redis从端口：6380redis从端口：6381sentinel端口：26379操作系统版本：CentOS release 6.5 (Final)redis版本：3.2.6Linux系统安装redis:1、下载redis: 登陆redis官网https://redis.io/d
数据库层面：应用系统层面优化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
前阵回收生产帐号的访问范围，即之前是xxx@"%"的帐号命名方式，修改成若干个以前端应用部署的机器IP为准，修改成xxx@"IP address"。尽量减少不可信客户端连接数据库的情况发生，加强数据安全。 但是回收xxx@"%"帐号后发现，生产一
mysqlpump是mysql5.7.8版本后特有的逻辑备份工具，相对于mysqldump和mysqldumper，mysqlpump拥有更多特性，官方文档的描述如下：mysqlpump features include: Parallel processing of databases, and of o
由于mysql5.6社区版没有企业版特有的audit审计插件，最近需要对生产的mysql数据库增加审计功能，在考虑了percona、maridb和macfee3个版本的audit，最终选择了较为熟悉的percona版。 这里注意下，最好采用同一子版本的PXC的audit_log.so文件，即下载PXC的二
一、环境部署：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主从搭建自行搭建
目前部署了zabbix3.0作为生产的监控系统，最近发现一个有趣的问题，就是套用percona公司的percona moinitor plugins中MySQL的监控模板的时候，有些agent的机器在取MySQL.running-slave这个item值的时候，agent侧取值同server侧取值是不一致的，如下：agent:[root@mysql03 zabbix_agentd.d]# /var
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号
