mysql主从配置

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

一、工作流程 （1）从宕机崩溃的 master 上尝试保存二进制日志事件（binlog events）; （2）识别含有最新更新的 slave 服务器； （3）应用差异的中继日志（relay log）到其他的 slave； （4）应用从 master 保存的二进制日志事件（binlog events）； （5）提升一个 slave 为新的 master 服务器； （6）将其他的 slave 连接指向新的 master 进行主从复制； 二、实验环境 1、注意安装环境，安装工具软件包net-tools 2、 主机名 IP地址 角色 serverID 数据库类型 server01 192.168.200.111 primary master1 1 写入 server02 192.168.200.112 secondary master2 2 写入 server03 192.168.200.113 slave1 3 读取 server04 192.168.200.114 slave2 4 读取 server05 192.168.200.115 manager 监控复制组 其中primary master对外提供写服务，备选secondary master实际相当于slave，提供读取服务，salve1和slave2也提供相关读服务，一旦primary master宕机

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

基于 MHA 的 MySQL 高可用方案 一、 MHA 简介 MHA （ Master High Availability ） 目前在 MySQL 高可用方面是一个相对成熟的解决方案， 它由日本 DeNA 公司的 youshimaton 员工（ 现就职于 Facebook 公司）开发，是一套优秀的作 为 MySQL 高可用性环境下 故障切换和主从角色提升 的高可用软件。在 MySQL 故障切换过程中，MHA 能做到在 0~30 秒之内自动完成数据库的主从故障切换操作，并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 M HA 由两部分组成： M H A M a n a g e （ r 管理节点 ） 和 M H A N o d e （数据节点 ） 。MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节点上。MHA Node 运行在每台MySQL 服务器及Manager 服务器上，MHA Manager 会定时探 测集群中的 master 节点，当 master 出现故障时，它可以自动将拥有最新数据的 slave 提升 为新的 master ，然后将所有其他的 slave 重新指向新提升的 master。整个故障转移过程对应用程序层面完全透明。 在 MHA

redhat6.5 mysql proxy代理及主从同步及读写分离 1.上传及安装所需要的软件包和语言 2.解压 mysql-proxy到 /usr/local/下，并重新命名（可以不重新命名，主要太长闲麻烦） 3.修改环境变量 编译环境变量使其生效 4.配置读写分离 5.配置2台数据库（最后保持一致），创建数据库表及数据，付权限，我创建如下： 6.启动mysql-proxy mysql-proxy --proxy-read-only-backend-addresses=192.168.189.203:3306 --proxy-backend-addresses=192.168.189.204:3306 --proxy-lua-script=/usr/local/mysql-proxy/share/doc/mysql-proxy/rw-splitting.lua 7.查看监听端量是否正常（4040默认） 8.测试 （代理服务器 ip:207， 特别说明代理要连接自己不是连接其他数据库ip，不然就连接不上 我自己犯的错误：截图说明 ） 错误记录： 写入（ip 204） 读（ip:203） ( 证明读写分离成功！但是不能主从同步！接下来我们做主从同步 ) 来源： oschina 链接： https://my.oschina.net/u/1861462/blog/738476

在windows下配置的，后面会在Linux下配置进行测试，需要配置mysql数据库同步的朋友可以参考下。 1.在主数据库服务器为从服务器添加一个拥有权限访问主库的用户: GRANT REPLICATION SLAVE ON *.* TO ' test'@'%' IDENTIFIED BY 'test'; (%表示允许所有IP，可设置指定从服务器IP) 添加用户后: 可在从服务器上用mysql -h127.0.0.1 -utest -ptest; 来测试是否有权限访问主数据库 2.在主据库配置文件加上: #master config server-id = 1 log-bin = mysql-bin 3.在从服务器数据库配置文件： server-id = 2 master-host = 10.0.0.199 master-user = test master-password = test replicate-do-db = test master-port = 3306 log-bin = mysql-bin 如果你的一切配置顺利 你在从服务器上输入命令：show slave status\G 成功情况： Slave_IO_Running:yes Slave_SQL_Running:yes 在主服务器上输入show master status 那么，恭喜，主从数据库配置OK

1. MHA环境搭建 规划: 主库: 51 node 从库: 52 node 53 node manager 2. 准备环境（略。1主2从GTID）搭建主从关系，此为简略 配置文件： [mysqld] basedir=/usr/local/mysql/ datadir=/data/mysql/data socket=/tmp/mysql.sock server_id=51 port=3306 secure-file-priv=/tmp autocommit=0 log_bin=/data/binlog/mysql-bin binlog_format=row gtid-mode=on enforce-gtid-consistency=true log-slave-updates=1 [mysql] prompt=db01 [\\d]> 初始化： mysqld --initialize-insecure --user=mysql --basedir=/usr/local/mysql --datadir=/data/mysql/data 授权： grant replication slave on *.* to repl@'10.0.1.%' identified by '123'; 主从数据同步： 若主从关系一起建立，则不需要备份主库数据到从库，否则应该将最近一次的备份数据恢复到从库

11.25 事物隔离级别 事物日志redo undo 事物锁 begin; update 事物日志性能优化 innodb_flush_log_at_trx_commit=0|1|2|3 innodb事务日志相关配置； show variables like '%innodb_log%'; 通用日志 通用日志：记录对数据库的通用操作，包括错误的SQL语句 通用日志可以保存在：file（默认值）或 table 通用日志相关设置 general_log=ON|OFF general_log_file=HOSTNAME.log log_output=TABLE|FILE|NONE 慢查询（重点） slow_query_log=on|off show profile for query 2; long_query_time=N; set global log_queries_not_using_indexes=ON; 二进制日志（重点） 记录导致数据改变或潜在导致数据改变的SQL语句 记录已提交的日志 不依赖于存储引擎类型 功能：通过“重放”日志文件中的事件来生成数据副本 注意：建议二进制日志和数据文件分开存放 二进制日志记录三种格式； 基于“语句”记录：statement，记录语句，默认模式 基于“行”记录：row，记录数据，日志量较大 （可恢复数据） 混合模式：mixed,

一、实验环境 主机名 IP地址 master 192.168.200.111 slave 192.168.200.112 atlas 192.168.200.113 主从复制不再赘述，链接地址： https://blog.csdn.net/weixin_42480196/article/details/102565189https://blog.csdn.net/weixin_42480196/article/details/102565189 授权Atlas登录用户 grant all on *.* to admin@'192.168.200.113' identified by '123'; flush privileges; 二、安装atlas #下载rpm包 wget https://github.com/Qihoo360/Atlas/releases/download/2.2.1/Atlas-2.2.1.el6.x86_64.rpm #安装 rpm -ivh Atlas-2.2.1.el6.x86_64.rpm 三、配置读写分离 加密密码 /usr/local/mysql-proxy/bin/encrypt 123 3yb5jEku5h4= #加密后 配置配置文件，实现读写分离 vim /usr/local/mysql-proxy/conf/test.cnf [mysql

在 CentOS7上搭建MySQL主从复制与读写分离 MySQL主从复制原理 MySQL的主从复制和MySQL的读写分离两者有着紧密联系，首先要部署主从复制，只有主从复制完成了，才能在此基础上进行数据的读写分离。 （ 1）MySQL支持复制的类型。 1)基于语句的复制。MySQL默认采用基于语句的复制，效率比较高。 2)基于行的复制。把改变的内容复制过去，而不是把命令在从服务器上执行一遍。 3）混合类型的复制。默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制。 （ 2）MySQL复制的工作过程如图所示。 1）在每个事务更新数据完成之前，Master在二进制日志记录这些改变。写入二进制日志完成后，Master通知存储引擎提交事务。 2）Slave将Master的Binary log复制到其中继日志。首先，Slave开始一个工作线程——I/O线程，I/O线程在Master上打开一个普通的链接，然后开始Binlog dump process。Binlog dump process从Master的二进制日志中读取事件，如果已经跟上Master，它会睡眠并等待Master产生新的事件。I/O线程将这些事件写入中继日志。 3）SQL slave thred（SQL从线程）处理该过程的最后一步。SQL线程从中继日志读取事件，并重放其中的事件而更新Slave的数据