mysql主从配置

概念 　 　　MySQL之间数据复制的基础是二进制日志文件（binary log file）。一台MySQL数据库一旦启用二进制日志后，其作为master，它的数据库中所有操作都会以“事件”的方式记录在二进制日志中，其他数据库作为slave通过一个I/O线程与主服务器保持通信，并监控master的二进制日志文件的变化，如果发现master二进制日志文件发生变化，则会把变化复制到自己的中继日志中，然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中，以此实现从数据库和主数据库的一致性，也就实现了主从复制。 安装mysql（一主一从） 　　192.168.138.187　　主机 192.168.138.188　　丛机 步骤一：检查虚拟机中是否有mysql环境，并将其卸载，命令如下 rpm -qa | grep -i mysql 　 如果有使用【rpm -e --nodeps MySQL-client-5.5.44-1.linux2.6.x86_64】命令将其删除； 使用【find / -name mysql】命令查看是否有相关的mysql文件夹 有的话，使用【rm -rf 文件名】删除相关文件或文件夹 步骤二：在【/usr/local】目录下使用命令【mkdir mysql】新建一个文件夹名为mysql，将tar文件放在该mysql文件夹下 　　　　 　　步骤三：使用

MySQL 5.6, 5.7, 8.0的新特性 对于MySQL的历史，相信很多人早已耳熟能详，这里就不要赘述。下面仅从产品特性的角度梳理其发展过程中的里程碑事件。 1995年，MySQL 1.0发布，仅供内部使用。 1996年，MySQL 3.11.1发布，直接跳过了MySQL 2.x版本。 1999年，MySQL AB公司成立。同年，发布MySQL 3.23，该版本集成了Berkeley DB存储引擎。该引擎由Sleepycat公司开发，支持事务。在集成该引擎的过程中，对源码进行了改造，为后续可插拔式存储引擎架构奠定了基础。 2000年，ISAM升级为MyISAM存储引擎。同年，MySQL基于GPL协议开放源码。 2002年，MySQL 4.0发布，集成了后来大名鼎鼎的InnoDB存储引擎。该引擎由Innobase公司开发，支持事务，支持行级锁，适用于OLTP等高并发场景。 2005年，MySQL 5.0发布，开始支持游标，存储过程，触发器，视图，XA事务等特性。同年，Oracle收购Innobase公司。 2008年，Sun以10亿美金收购MySQL AB。同年，发布MySQL 5.1，其开始支持定时器（Event scheduler），分区，基于行的复制等特性。 2009年，Oracle以74亿美金收购Sun公司。 2010年， MySQL 5.5 发布

在工作中接触最多的就是mysql replication，由于现在公司也还在使用mysql 5.1.x版本，在复制方面还是比较多的问题，比如主库宕机或者从库宕机都会导致复制中断，通常我们需要进行人为修复（mysql 5.5版本解决大部分问题），或者很多时候需要把一个从库提升为主库，但对从库和主库的数据一致性不能保证一样，所以就利用 pt-table-checksum 工作来检查主从的一致性，以及通过 pt-table-sync 如何修复这些不一致的数据。当然如果你数据量小，slave只是当做一个备份使用，那么出现数据不一致完全可以重做，或者通过其他方法解决。如果数据量非常大，重做就是非常蛋碎的一件事情了。^_^ 工具安装： 1.软件下载： [root@MySQL-01 ~]# wget http://www.percona.com/downloads/percona-toolkit/LATEST/RPM/percona-toolkit-2.2.7-1.noarch.rpm 2.安装该工具依赖的软件包： [root@MySQL-01 ~]# yum install perl-IO-Socket-SSL perl-DBD-MySQL perl-Time-HiRes -y 3.软件安装： [root@MySQL-01 ~]# rpm -ivh percona-toolkit-2.2.7

读写分离是在主从复制的基础上实现的 一:安装MyCat MyCat下载完解压就能用,但是我们需要进行我们的配置 下载地址 http://dl.mycat.io 下载完成上传并解压就ok了 如果启动失败的的话可以查看logs/wrapper.log文件里的错误信息,百度一搜就可以解决了 我的MyCat安装在mysql主机上ip地址为192.168.118.4 二:配置MyCat 主要配置两个文件 servvice.xml里的东西备份之后,替换成下面的 <mycat:server xmlns:mycat="http://io.mycat/"> <!-- 添加user --> <user name="mycat_master" defaultAccount="true"> <property name="password">mycat_master</property> <property name="schemas">hehe</property> </user> <!-- 添加user --> <user name="mycat_slave"> <property name="password">mycat_slave</property> <property name="schemas">hehe</property> <property name="readOnly">true<

一、 表设计规范 库名、表名、字段名必须使用小写字母，“_”分割。 库名、表名、字段名必须不超过12个字符。 库名、表名、字段名见名知意,建议使用名词而不是动词。 建议使用InnoDB存储引擎。 存储精确浮点数必须使用DECIMAL替代FLOAT和DOUBLE。 建议使用UNSIGNED存储非负数值。 建议使用INT UNSIGNED存储IPV4。 整形定义中不添加长度，比如使用INT，而不是INT(4)。 使用短数据类型，比如取值范围为0-80时，使用TINYINT UNSIGNED。 不建议使用ENUM类型，使用TINYINT来代替。 尽可能不使用TEXT、BLOB类型。 VARCHAR(N)，N表示的是字符数不是字节数，比如VARCHAR(255)，可以最大可存储255个汉字，需要根据实际的宽度来选择N。 VARCHAR(N)，N尽可能小，因为MySQL一个表中所有的VARCHAR字段最大长度是65535个字节，进行排序和创建临时表一类的内存操作时，会使用N的长度申请内存。 表字符集选择UTF8。 使用VARBINARY存储变长字符串。 存储年使用YEAR类型。 存储日期使用DATE类型。 存储时间（精确到秒）建议使用TIMESTAMP类型，因为TIMESTAMP使用4字节，DATETIME使用8个字节。 建议字段定义为NOT NULL。 将过大字段拆分到其他表中。

一、环境简述 1、工作逻辑图 2、MySQL-MMM优缺点 优点：高可用性，扩展性好，出现故障自动切换，对于主主同步，在同一时间只提供一台数据库写操作，保证的数据的一致性。 缺点：Monitor节点是单点，可以结合Keepalived实现高可用，对主机的数量有要求，需要实现读写分离，对程序来说是个挑战。 3、MySQL-MMM工作原理 MMM(Master-Master replication managerfor Mysql， Mysql主主复制管理器 )是一套灵活的脚本程序，基于 perl实现，用来对 mysql replication进行监控和故障迁移，并能管理 mysql Master-Master复制的配置 (同一时间只有一个节点是可写的 )。 mmm_mond：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。此脚本需要在监管机上运行。 mmm_agentd：运行在每个mysql服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。 mmm_control：一个简单的脚本，提供管理mmm_mond进程的命令。 mysql-mmm的监管端会提供多个虚拟IP（VIP），包括一个可写VIP，多个可读VIP，通过监管的管理，这些IP会绑定在可用mysql之上，当某一台mysql宕机时，监管会将VIP迁移至其他mysql。

整理了一些Java方面的架构、面试资料（微服务、集群、分布式、中间件等），有需要的小伙伴可以关注公众号【程序员内点事】，无套路自行领取 更多优选 一口气说出 9种 分布式ID生成方式，面试官有点懵了 3万字总结，Mysql优化之精髓 为了不复制粘贴，我被逼着学会了JAVA爬虫 技术部突然宣布：JAVA开发人员全部要会接口自动化测试框架 Redis 5种数据结构及对应使用场景，全会面试要加分的 写在前边 在家远程办公第三周，快被手机上的消息搞的有些神经质了，生怕错过一条有用的信息，没办法形势如此，公司摇摇欲坠大家也都如履薄冰，毕竟这时候失业有点惨（ 穷怕了 ）。 但就干活来说还是比较清闲的，和在公司上班相比，清闲下来很多碎片时间，可以随意的做点自己喜欢的事情。而且我发现， 人一但闲下来真的是好可怕 ，潜在的才能会全面爆发，我女朋友这个抖音深度患者，一年不做一回饭的主，一周内接连给我做了两顿黑暗料理，烤馒头版“蛋糕”、浆糊版“凉皮”，然后我就与厕所结下来不解之缘。。。 不过，作为一个程序员，我对黑暗料理是不太感兴趣滴，闲下来还是喜欢学习钻研一些新奇的技术， canal 就成了很好的研究对象，一不小心就监控了公司MySQL的一举一动的 一、canal是个啥？ canal 是阿里开发的一款基于数据库增量日志解析，提供增量数据订阅与消费的框架，整个框架纯 JAVA 开发，目前仅支持

1. 为什么需要主从复制? 　　a. 在复杂的业务中,有一个sql需要锁表,导致不能使用读的服务,影响业务的运行,使用主从复制,让主库写,从库读,保证业务的运行 　　b. 做数据的热备 　　c. 架构扩展,业务量原来越大,I/O访问评率过高,做多库存储,提高单个机器的I/O性能 2. 原理(默认采用的是异步的方式,不是强一致性) 　　MySQL 中有一种日志叫做 bin 日志（二进制日志），这个日志会记录下所有修改了数据库的SQL语句。主从复制的原理其实就是"从"服务器向"主"服务器请求这个日志文件，"主"服务器会把这个 bin 日志复制到"从"服务器上执行一遍，这样"从"服务器上的数据就和"主"服务器上的数据相同了。 　　 　　主服务器必须启动二进制日志binlog,记录任何修改数据库数据的sql 　　从服务器开启一个线程(I/O thread)把自己扮演成mysql的客户端,通过mysql协议,请求主服务器的二进制日志文件binlog 　　主服务器启动一个线程(Dump thread),检查自己二进制日志中的sql,核对参数,对比,将binlog日志发送到从服务器 　　从服务器接收到主服务器的数据放到中继日志relay log文件中 　　从服务器启动一个线程sql thread,把relay log中的事件读取出来,在本地执行 3. mysql主从同步延时分析 　

主从复制是指将主数据库的DDL和DML操作通过二进制日志传到数据库上，然后在从数据库上对这些日志进行重新执行，使从数据库和主数据库的数据一致 原理 MySQL主库在事务提交时会把数据变更记录在二进制日志Binlog中 主库推送二进制日志文件Binlog中的事件到从库的中继RelayLog中，之后从库根据中继日志重做数据变更操作，通过逻辑复制来达到主库和从库的数据一致性 MySQL通过三个线程来完成主从数据库间的数据复制，其中Binlog Dump线程跑在主库上，I/O线程和sql线程跑在从库 当在从库启动复制时，首先创建I/O线程连接主库，主库随后创建BinlogDump线程读取数据库事件并发送给I/O线程，I/O线程获取到事件数据后更新到从库的中继日志RelayLog中去，，之后从库上的sql线程读取中继日志relayLog中更新的数据库事件并应用 实例搭建（使用docker） 运行MySQL主实例 docker run -p 3307:3306 --name mysql-master \ -v /mydata/mysql-master/log:/var/log/mysql \ -v /mydata/mysql-master/data:/var/lib/mysql \ -v /mydata/mysql-master/conf:/etc/mysql \ -e MYSQL_ROOT

六，配置VIP漂移 主机名 IP地址（NAT） 漂移VIP 描述 mysql-db01 eth0:192.168.0.51 VIP：192.168.0.60 系统：CentOS6.5（6.x都可以） 安装：mysql5.6 mysql-db02 eth0:192.168.0.52 VIP：192.168.0.60 系统：CentOS6.5（6.x都可以） 安装：mysql5.6 mysql-db03 eth0:192.168.0.53 VIP：192.168.0.60 系统：CentOS6.5（6.x都可以） 安装：mysql5.6 6.1 IP漂移的两种方式 通过keepalived的方式，管理虚拟IP的漂移 通过MHA自带脚本方式，管理虚拟IP的漂移 6.2 MHA脚本管理方式 （1）获取管理脚本master_ip_failover 提示：yum安装的manager是没有这个脚本的。 我们需要从manager的源码包里复制一个。 [root@mysql-db03 ~]# ll mha4mysql-manager-0.56.tar.gz -rw-r--r--. 1 root root 113914 Sep 4 18:43 mha4mysql-manager-0.56.tar.gz [root@mysql-db03 ~]# tar xf mha4mysql-manager-0.56