mysql主从配置

前言 作为一名后台开发，对数据库进行基准测试，以掌握数据库的性能情况是非常必要的。本文介绍了MySQL基准测试的基本概念，以及使用sysbench对MySQL进行基准测试的详细方法。 文章有疏漏之处，欢迎批评指正。 目录 一、基准测试简介 　　 1、什么是基准测试 　　 2、基准测试的作用 　　 3、基准测试的指标 　　 4、基准测试的分类 二、sysbench 　　 1、sysbench简介 　　 2、sysbench安装 　　 3、sysbench语法 　　 4、sysbench使用举例 　　 5、测试结果 三、建议 一、基准测试简介 1、什么是基准测试 数据库的基准测试是对数据库的性能指标进行定量的、可复现的、可对比的测试。 基准测试与压力测试 基准测试可以理解为针对系统的一种压力测试。但基准测试不关心业务逻辑，更加简单、直接、易于测试，数据可以由工具生成，不要求真实；而压力测试一般考虑业务逻辑(如购物车业务)，要求真实的数据。 2、基准测试的作用 对于多数Web应用，整个系统的瓶颈在于数据库；原因很简单：Web应用中的其他因素，例如网络带宽、负载均衡节点、应用服务器（包括CPU、内存、硬盘灯、连接数等）、缓存，都很容易通过水平的扩展（俗称加机器）来实现性能的提高。而对于MySQL，由于数据一致性的要求，无法通过增加机器来分散向数据库写数据带来的压力；虽然可以通过前置缓存

MySQL5.7以后都基本用GTID方式复制了，相对于binlog和position号方式，在failover时候减少很多人工切换操作 GTID，global transaction identitifiers，基于全局事务的复制方式，由server_uuid:transaction_id组成,server_uuid在数据库启动过程生成,在/data/auto.cnf中 复制过程：master事务提交时GTID，记录到binlog；然后master的binlog传送到slave的relaylog,slave读取GTID生成gtid_next系统参数;slave校验GTID是否在binlog并进一步应用事务（5.7后是存放在gtid_executed系统表，这样不用开启log_slave_updates参数，从而不用把relaylog记录再记录到binlog，减少slave压力） 下面操作下： 首先主从都配置gtid_mode、enforce_gtid_consistency参数,其中备库多加个log_slave_updates=1 [root@localhost /usr/local/mysql/data]$ cat /etc/my.cnf [mysqld] datadir=/usr/local/mysql/data log_bin=mysql-bin server_id=1

一、MHA介绍 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是日本的一位 MySQL专家采用Perl语言编写的一个脚本管理工具，该工具仅适用于MySQLReplication（二层）环境，目的在于维持Master主库的高可用性。是一套优秀的作为MySQL高可用性 环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上 保证数据的一致性，以达到真正意义上的高可用。 MHA是自动的master故障转移和Slave提升的软件包.它是基于标准的MySQL复制(异步/半同步).该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。 1）MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Manager会定时探测集群中的node节点,当发现master 出现故障的时候,它可以自动将具有最新数据的slave提升为新的master

MHA架构图 本次MHA的部署基于GTID复制成功构建，普通主从复制也可以构建MHA架构。 下载所需的软件包 mkdir /server/tools -p //创建存放包的目录 [root@db01 tools]# ll total 5136 -rw-r--r-- 1 root root 4963681 Oct 26 15:39 Atlas-2.2.1.el6.x86_64.rpm -rw-r--r-- 1 root root 87119 Oct 26 15:39 mha4mysql-manager-0.56-0.el6.noarch.rpm -rw-r--r-- 1 root root 113914 Oct 26 15:39 mha4mysql-manager-0.56.tar.gz -rw-r--r-- 1 root root 36326 Oct 26 15:39 mha4mysql-node-0.56-0.el6.noarch.rpm -rw-r--r-- 1 root root 50172 Oct 26 15:39 mha4mysql-node-0.56.tar.gz　　 下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads 安装依赖包（所有节点） yum install perl-DBD

简介： MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点） 。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。 在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制

一、MHA介绍 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是日本的一位 MySQL专家采用Perl语言编写的一个脚本管理工具，该工具仅适用于MySQLReplication（二层）环境，目的在于维持Master主库的高可用性。是一套优秀的作为MySQL高可用性 环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上 保证数据的一致性，以达到真正意义上的高可用。 MHA是自动的master故障转移和Slave提升的软件包.它是基于标准的MySQL复制(异步/半同步).该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。 1）MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Manager会定时探测集群中的node节点,当发现master 出现故障的时候,它可以自动将具有最新数据的slave提升为新的master,然后将所有其它的slave导向新的master上.整个故障转移过程对应用程序是透明的。 2）MHA

GTID复制原理： 基于GTID的复制是MySQL 5.6后新增的复制方式. GTID (global transaction identifier) 即全局事务ID, 保证了在每个在主库上提交的事务在集群中有一个唯一的ID. 在原来基于日志的复制中, 从库需要告知主库要从哪个偏移量进行增量同步, 如果指定错误会造成数据的遗漏, 从而造成数据的不一致. 而基于GTID的复制中, 从库会告知主库已经执行的事务的GTID的值, 然后主库会将所有未执行的事务的GTID的列表返回给从库. 并且可以保证同一个事务只在指定的从库执行一次. GTID是由server_uuid和事物id组成，格式为：GTID=server_uuid:transaction_id。server_uuid是在数据库启动过程中自动生成，每台机器的server-uuid不一样。uuid存放在数据目录的auto.conf文件中，而transaction_id就是事务提交时系统顺序分配的一个不会重复的序列号。 GTID的好处： （1）GTID使用master_auto_position=1代替了binlog和position号的主从复制搭建方式，相比binlog和position方式更容易搭建主从复制。 （2）GTID方便实现主从之间的failover，不用一步一步的去查找position和binlog文件。

GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID，它由服务器ID以及事务ID组合而成。这个全局事务ID不仅仅在原始服务器器上唯一，在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单，以及数据库一致性更可靠。本文主要描述了快速配置一个基于GTID的主从复制架构，供大家参考。 一、GTID的概念 1、全局事务标识：global transaction identifiers。 2、GTID是一个事务一一对应，并且全局唯一ID。 3、一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。 4、GTID用来代替传统复制方法，不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。 5、MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。 6、在传统的slave端，binlog是不用开启的，但是在GTID中slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）。 二、GTID的组成 GTID = source_id:transaction_id source_id，用于鉴别原服务器，即mysql服务器唯一的的server_uuid

基于gtid 主从复制 参考链接：https://blog.csdn.net/weixin_43407305/article/details/87911235 参考链接：https://blog.csdn.net/martingpf/article/details/81115187 参考链接：https://blog.csdn.net/leshami/article/details/50630691 参考链接：https://blog.csdn.net/qq_43094192/article/details/83994952 MySQL 5.6引入的GTID(Global Transaction IDs)使得其复制功能的配置、监控及管理变得更加易于实现，且更加健壮. MySQL 5.6中使用复制功能，其服务配置段[mysqld]中于少应该定义如下选项： binlog-format：二进制日志的格式，有row、statement和mixed几种类型；需要注意的是：当设置隔离级别为READ-COMMITED必 须设置二进制日志格式为ROW，现在MySQL官方认为STATEMENT这个已经不再适合继续使用,但mixed类型在默认的事务隔离级别下，可能会导致主从数据不一致； log-slave-updates、gtid-mode、enforce-gtid-consistency

Mysql5.6基于GTID全局事务的复制 什么是 GTID ？   GTID(Global Transaction Identifiers)是全局事务标识 当使用GTIDS时，在主上提交的每一个事务都会被识别和跟踪，并且运用到所有从MySQL，而且配置主从或者主从切换时不再需要指定 master_log_files和master_log_pos；由于GTID-base复制是完全基于事务的，所以能很简单的决定主从复制的一致性； 官方建议Binlog采用Row格式 MySQL 5.1.12 开始，可以用以下三种模式来实现： 基于SQL语句的复制(statement-based replication, SBR)， 基于行的复制(row-based replication, RBR)， 混合模式复制(mixed-based replication, MBR)。 相应地，binlog的格式也有三种：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 模式是默认的。 基于混合模式的复制：它是根据事件的类型实时的改变binlog的格式。当设置为混合模式时，默认为基于语句的格式，但在特定的情况下它会自动的转变为基于行的模式。 SBR 的优点： 历史悠久，技术成熟 binlog文件较小 binlog中包含了所有数据 库更改信息，可以据此来审核数据库的安全等情况