MySQL配置主从分离

主数据库操作(ip:192.168.176.110)

配置MySQL主服务器的配置文件

[root@localhost ~]# vi /etc/my.cnf

在my.cnf内加上如下配置

server-id = 1 #保证唯一性
log-bin = mysql-bin #主从服务的核心 定义binblog日志的前缀名 
#binlog-do-db=test #需要同步的数据库，如果没有本行，即表示同步所有的数据库 
#binlog-do-db=mydb #需要同步的数据库，同时同步test、mydb库 、
#binlog-ignore-db=mysql #被忽略的数据库

重启MySQL主服务器

[root@localhost ~]# service mysqld restart

登录MySQL

[root@localhost ~]# mysql -uroot -p123456 

查看数据库状态

需要记住File列和Position列的数据，配置从服务器需要使用

mysql> show master status;

主数据库操作(ip:192.168.176.120)

配置MySQL从服务器的配置文件

[root@localhost ~]# vi /etc/my.cnf

在my.cnf内加上如下配置

server-id = 2 #保证唯一性

重启MySQL主服务器

[root@localhost ~]# service mysqld restart

登录MySQL

[root@localhost ~]# mysql -uroot -p123456 

配置同步主服务器：

master_host主服务器地址

master_port主服务器端口

master_user主服务器用户名

master_password主服务器密码

master_log_file 对应上图的主服务器File列数据

master_log_pos对应上图的主服务器Position列数据

mysql> change master to master_host='192.168.176.110',master_port=3306,master_user='root',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=157;

开启服务，并查看服务状态

mysql> start slave;  #开启从服务
mysql> show slave status\G; #查看从服务状态

配置成功

配置出错

注意：配置主从同步，出现Slave_IO_Running: No 情况处理方式（复制同一套环境出现的问题）

如果出现上图的错误，说明两台虚拟机的MySQL环境的UUID一致。 可以通过命令检测他们的UUID。

[root@localhost ~]# cat /var/lib/mysql/auto.cnf

如果命令无效 则进入到MySQL，执行以下命令获取安装的路径

mysql> show variables like 'datadir';

然后从服务器生成一个新的UUID

mysql> select uuid();

复制后 通过命令去修改里面的UUID（路径为自己mysql安装路径）

[root@localhost ~]# vi /var/lib/mysql/auto.cnf

最后重启下mysql服务

[root@localhost ~]# service mysqld restart

执行完后重新的去执行【配置同步主服务器】的步骤，配置参数和主服务器相同的即可

以上是配置主从同步，出现Slave_IO_Running: No 情况处理方式

主服务器创建数据库

主库宕机处理方式

1-确保所有的relay log全部更新完毕，在每个从库上执行show processlist

2-更新完毕后，登录所有从库查看master.info文件，对比选择pos最大的作为新的主库，

3-然后登录这个新的主库，执行stop slave；进入主目录，删除master.Info和relay-log.info配置my.cnf文件开启log-bin文件

4-创建用于同步的用户并授权slave

5-登录另外一台从库，执行stop slave停止同步

6-执行start slave

7-修改新的master数据，测试slave是否同步更新

从库宕机

1-查看从库上mysql的错误日志，里面有记录主从挂掉时的binlog信息。

2-有了binlog和postion信息后，只需要重新在从库上进行change master to配置即可。配置后开启slave状态，没有报错

3-查看slave状态，发现slave已经正常了，开始进行延时数据恢复。

总结