Centos6 安装mysql5.6 实现主从复制/主主复制环境虚拟机下载

本博主配置好的Centos6 安装mysql5.6 实现主从复制/主主复制环境虚拟机下载,链接:https://pan.baidu.com/s/1YYS13pSxidzNwjlC-PiGng
提取码:npea 下载好,用Vmware Workstaion打开,即可以正常使用

Mysql复制概念
Mysql内建的复制功能是构建大型高性能应用程序的基础, 将Mysql数据分布到多个系统上,这种分布机制是通过将Mysql某一台主机数据复制到其它主机(slaves)上,并重新执行一遍来实现的。复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,然后封锁并等待主服务器通知新的更新。

Mysql支持哪些复制
–  基于语句的复制: 在主服务器执行SQL语句,在从服务器执行同样语句。MySQL默认采用基于语句的复制,效率较高。一旦发现没法精确复制时, 会自动选基于行的复制。
–  基于行的复制: 把改变的内容复制过去,而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持
–  混合类型的复制: 默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,就会采用基于行的复制。

Mysql复制解决的问题
–  数据分布 (Data distribution )
–  负载平衡(load balancing)
–  据备份(Backups) ,保证数据安全
–  高可用性和容错行(High availability and failover)
–  实现读写分离,缓解数据库压力

Mysql主从复制原理
master服务器将数据的改变都记录到二进制binlog日志中,只要master上的数据发生改变,则将其改变写入二进制日志;salve服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变,如果发生改变,则开始一个I/O Thread请求master二进制事件,同时主节点为每个I/O线程启动一个dump线程,用于向其发送二进制事件,并保存至从节点本地的中继日志中,从节点将启动SQL线程从中继日志中读取二进制日志,在本地重放,使得其数据和主节点的保持一致,最后I/O Thread和SQL Thread将进入睡眠状态,等待下一次被唤醒。

需要理解:
–  从库会生成两个线程,一个I/O线程,一个SQL线程;
–  I/O线程会去请求主库的binlog,并将得到的binlog写到本地的relay-log(中继日志)文件中;
–  主库会生成一个log dump线程,用来给从库I/O线程传binlog;
–  SQL线程,会读取relay log文件中的日志,并解析成sql语句逐一执行;

这里注意几点:
–  master将操作语句记录到binlog日志中,然后授予slave远程连接的权限(master要开启binlog二进制日志功能;通常为了数据安全考虑,slave也开启binlog);
–  slave开启两个线程:IO线程和SQL线程。其中:IO线程负责读取master的binlog内容到中继日志relay log里;SQL线程负责从relay log日志里读出binlog内容,并更新到slave的数据库里,这样就能保证slave数据和master数据保持一致了;
–  mysql复制至少需要两个Mysql的服务,当然Mysql服务可以分布在不同的服务器上,也可以在一台服务器上启动多个服务;
–  mysql复制最好确保master和slave服务器上的Mysql版本相同(如果不能满足版本一致,那么要保证master主节点的版本低于slave从节点的版本);
–  master和slave两节点间时间需同步;

Mysql复制流程图

如上图所示:
–  Mysql复制过程的第一部分就是master记录二进制日志。在每个事务更新数据完成之前,master在二日志记录这些改变。MySQL将事务串行的写入二进制日志,即使事务中的  语句都是交叉执行的。在事件写入二进制日志完成后,master通知存储引擎提交事务;
–  第二部分就是slave将master的binary log拷贝到它自己的中继日志。首先,slave开始一个工作线程(I/O线程)。I/O线程在master上打开一个普通的连接,然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件,如果已经跟上master,它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志;
–  SQL slave thread(SQL从线程)处理该过程的最后一步。SQL线程从中继日志读取事件,并重放其中的事件而更新slave的数据,使其与master中的数据一致。只要该线程与  I/O线程保持一致,中继日志通常会位于OS的缓存中,所以中继日志的开销很小;
–  此外,在master中也有一个工作线程:和其它MySQL的连接一样,slave在master中打开一个连接也会使得master开始一个线程。复制过程有一个很重要的限制, 即复制在slave上是串行化的,也就是说master上的并行更新操作不能在slave上并行操作。

Mysql复制方案
主从复制: 主库授权从库远程连接,读取binlog日志并更新到本地数据库的过程;主库写数据后,从库会自动同步过来(从库跟着主库变);
主主复制: 主从相互授权连接,读取对方binlog日志并更新到本地数据库的过程;只要对方数据改变,自己就跟着改变;

本博主配置好的Centos6 安装mysql5.6 实现主从复制/主主复制环境虚拟机下载,链接:https://pan.baidu.com/s/1YYS13pSxidzNwjlC-PiGng
提取码:npea 下载好,用Vmware Workstaion打开,即可以正常使用

Mysql主从复制优点
在从服务器可以执行查询工作(即我们常说的读功能),降低主服务器压力;(主库写,从库读,降压)
在从主服务器进行备份,避免备份期间影响主服务器服务;(确保数据安全)
当主服务器出现问题时,可以切换到从服务器。(提升性能)

Mysql主从复制工作流程关键细节
1) MySQL支持单向、异步复制,复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。MySQL复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。因此,要进行复制,必须在主服务器上启用二进制日志。每个从服务器从主服务器接收主服务器上已经记录到其二进制日志的保存的更新。当一个从服务器连接主服务器时,它通知主服务器定位到从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,并在本机上执行相同的更新。然后封锁并等待主服务器通知新的更新。从服务器执行备份不会干扰主服务器,在备份过程中主服务器可以继续处理更新。

阅读更多

ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

今天在使用冷备份文件重做从库时遇到一个报错,值得研究一下。

版本:MySQL5.6.27

一、报错现象

dba:(none)> start slave;

ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

这个时候查看error.log:

2017-07-17 16:19:02 9022 [ERROR] Failed to open the relay log ‘./tjtx-96-67-relay-bin.017814’ (relay_log_pos 172582079).

2017-07-17 16:19:02 9022 [ERROR] Could not find target log file mentioned in relay log info in the index file ‘./tjtx135-1-95-relay-bin.index’ during relay log initialization.

2017-07-17 16:19:02 9022 [ERROR] Failed to initialize the master info structure

2017-07-17 16:19:02 9022 [Note] Check error log for additional messages. You will not be able to start replication until the issue is resolved and the server restarted.

2017-07-17 16:19:02 9022 [Note] Event Scheduler: Loaded 0 events

2017-07-17 16:19:02 9022 [Note] /usr/local/mysql/bin/mysqld: ready for connections.

Version: ‘5.6.27-log’  socket: ‘/tmp/mysql.sock’  port: 3306  MySQL Community Server (GPL)

2017-07-17 16:19:06 9022 [ERROR] Slave SQL: Slave failed to initialize relay log info structure from the repository, Error_code: 1872

从报错上看,意思是启动slave时,使用repository中信息初始化relay log结构失败。为什么失败?原来是从tjtx135-1-95-relay-bin.index文件中找不到tjtx-96-67-relay-bin.017814文件。到这里,答案就很清楚,由于我使用的是冷备份文件恢复的实例,在mysql库中的slave_relay_log_info表中依然保留之前relay_log的信息,所以导致启动slave报错。

那如何解决呢?先来简单的解MySQL Relay log的基础知识:

二、MySQL Relay log介绍

在MySQL复制结构下,Slave服务器会产生三种日志文件,用来保存主库的二进制日志事件以及relay log已执行到的位置和状态。

1、relay log 文件:由IO thread线程从主库读取的二进制日志事件组成,该日志被Slave上的SQL thread线程执行,从而实现数据的复制。

2、master info log:该文件保存slave连接master的状态以及配置信息,如用户名,密码,日志执行的位置等。在5.6版本之前,都是使用master.info文件,从5.6开始,通过在my.cnf  中配置 –master-info-repository=TABLE。这些信息会被写入mysql.slave_master_info 表中,代替原来的master.info文件。

3、relay log info log:该文件保存slave上relay log的执行位置。在5.6版本之前,都是使用relay-log.info文件,从5.6开始,通过在my.cnf中配置 –relay-log-info-repository=TABLE,使用mysql.slave_relay_log_info表代替原来的文件。每次当slave上执行start slave时,就会读取该表中的位置信息。

新版本使用表来代替原来的文件,主要为crash-safe replication,从而大大提高从库的可靠性。为保证意外情况下从库的可靠性,mysql.slave_master_info和mysql.slave_relay_log_info表必须为事务性的表,从5.6.6起,这些表默认使用InnoDB存储引擎。在5.6.5及之前的版本默认使用MyISAM引擎,可用下面语句进行转换:

ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;

ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;

【注意】不要试图手工的更新、插入、删除以上两个表的内容,以免出现意料不到的问题。

三、问题解决

通过上面的报错以及relay log介绍,很容易知道由于mysql.slave_relay_log_info表中保留以前的复制信息,导致新从库启动时无法找到对应文件,那么我们清理掉该表中的记录不就可以。再次提醒,不要手动删该表数据,MySQL已经提供工具给我们:reset slave:

reset slave干的那些事:

1、删除slave_master_info ,slave_relay_log_info两个表中数据;

2、删除所有relay log文件,并重新创建新的relay log文件;

3、不会改变gtid_executed 或者 gtid_purged的值

下面解决问题:

dba:(none)> reset slave;

Query OK, 0 rows affected (0.00 sec)

dba:(none)> change master to ……

 

dba:(none)> start slave;

Query OK, 0 rows affected (0.00 sec)

到这里问题解决。

【经验】:以后用冷备份恢复实例后,在启动slave前,先进行reset slave清空下以前的旧信息。