mysql主从配置

  1. 云栖社区>
  2. 博客>
  3. 正文

mysql主从配置

技术小阿哥 2017-11-27 14:09:00 浏览880
展开阅读全文

MySql主从配置

   根据业务备份需要,进行MySql主从配置,主服务器提供服务,从服务器作为备份使用,或者做读写分离。如果主服务器出现问题可以进行切换,数据是一样的。

一、Mysql主从的原理:

  Mysql的 Replication 是一个异步的复制过程,从一个Mater复制到另一个Slave。在 Master 与 Slave 之间的实现 整个复制过程主要由三个线程来完成,其中两个线程(Sql线程和IO线程)在 Slave 端,另外一个线程(IO线程)在 Master 端。

   要实现 MySQL 的 Replication ,首先必须打开 Master 端的Binary Log(mysql-bin.xxxxxx)功 能,否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全 顺序的执行日志中所记录的各种操作。打 开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “—log-bin” 参数选项,或者 在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。

  MySQL 复制的基本过程如下:

  1. Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;

    2. Master 接收到来自 Slave 的 IO 线程的请求后,通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息,返 回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息在 Master 端的 Binary Log 文件的 名称以及在 Binary Log 中的位置;

   3. Slave 的 IO 线程接收到信息后,将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay- bin.xxxxxx)的最末端,并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中,以便在下一次读取的 时候能够清楚的高速Master从某个bin-log的哪个位置开始往后的日志内容”

    4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后,会马上解析该 Log 文件中的内容成为在 Master 端真实执 行时候的那些可执行的 Query 语句,并在自身执行这些 Query。这样,实际上就是在 Master 端和 Slave 端执行了同样 的 Query,所以两端的数据是完全一样的。

  实际上,在老版本中,MySQL 的复制实现在 Slave 端并不是由 SQL 线程和 IO 线程这两个线程共同协作而完成的,而是由单独的一个线程来完成所有的工作。但是 MySQL 的工程师们很快发现,这样做存在很大的风险和性能问题,主要如下:

    首先,如果通过一个单一的线程来独立实现这个工作的话,就使复制 Master 端的,Binary Log日志,以及解析这些日志,然后再在自身执行的 这个过程成为一个串行的过程,性能自然会受到较大的限制,这种架构下的 Replication 的延迟自然就比较长了。

    其次,Slave 端的这个复制线程从 Master 端获取 Binary Log 过来之后,需要接着解析这些内容,还原成 Master 端所执行 的原始 Query,然后在自身执行。在这个过程中,Master端很可能又已经产生了大量的变化并生成了大量的 Binary Log 信息。如果在这 个阶段 Master 端的存储系统出现了无法修复的故障,那么在这个阶段所产生的所有变更都将永远的丢失,无法再找回来。这种潜在风险在Slave 端 压力比较大的时候尤其突出,因为如果 Slave 压力比较大,解析日志以及应用这些日志所花费的时间自然就会更长一些,可能丢失的数据也就会更多。

    所以,在后期的改造中,新版本的 MySQL 为了尽量减小这个风险,并提高复制的性能,将 Slave 端的复制改为两个线程来完成,也就是前面所提到 的 SQL 线程和 IO 线程。最早提出这个改进方案的是Yahoo!的一位工程师“Jeremy Zawodny”。通过这样的改造,这样既在很大程 度上解决了性能问题,缩短了异步的延时时间,同时也减少了潜在的数据丢失量。

  当然,即使是换成了现在这样两个线程来协作处理之后,同样也还是存在 Slave 数据延时以及数据丢失的可能性的,毕竟这个复制是异步的。只要数据的更改不是在一个事务中,这些问题都是存在的。

如 果要完全避免这些问题,就只能用 MySQL 的 Cluster 来解决了。不过 MySQL的 Cluster 知道笔者写这部分内容的时候,仍然还 是一个内存数 据库的解决方案,也就是需要将所有数据包括索引全部都 Load 到内存中,这样就对内存的要求就非常大的大,对于一般的大众化应用来说可 实施性并不是太大。当然,在之前与 MySQL 的 CTO David 交流的时候得知,MySQL 现在正在不断改进其 Cluster 的实现,其 中非常大的一个改动就是允许数据不用全部 Load 到内存中,而仅仅只是索引全部 Load 到内存中,我想信在完成该项改造之后 的 MySQL Cluster 将会更加受人欢迎,可实施性也会更大。

 

简单来说整个过程是:

要想实现AB复制,那么前提是master上必须要开启二进制日志
1)首先master将数据更新记录到二进制日志文件
2)从slave start开始,slave通过I/O线程向master索要二进制日志文件,slave是知道要从哪个位置点开始要
3)master接收到slave的io请求之后,就会从相应的位置点开始,给slave传日志
4)slave接收到日志后,vi会写入本地的中继日志中
5)slave通过sql线程读取中继日志的内容,在数据库中执行相应的操作,到此为止,master和slave上的数据一致,之后slave服务器进入等待状态,等待master的后续更新

原理图:


wKiom1Z7qQnBJafGAAAy6YGh8IY354.png  

二、主从服务器上的线程:

1)从服务器上的线程
I/O线程:负责从主服务器索要二进制日志,并将其存入从服务器的中继日志中
SQL线程:负责读取从服务器上的中继日志,并对数据库执行相应的操作
2)主服务器上的线程
binlog dump线程:负责发送二进制日志

 

三、搭建过程:

Master端:

①开启二进制日志:

vi /etc/my.cnf

[mysqld]

log-bin=mysql-bin
skip-name-resolve
server-id = 1 //保证主从不一样

②重启mysql服务:

/etc/init.d/mysqld restart

③授权备份用户

mysql> grant replication slave,reload,super on *.* to slave@192.168.1.2 identified by 'backup';
//此处的IP为从服务器的IP,用户名salve 密码backup

④做全库备份:

mysql> flush tables with read lock; 

//给所有的表加上读锁,为了保证数据的一致性

# mysqldump -u root -p --all-databases > /tmp/all.sql

mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
mysql-bin.000002 | 1306 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

//这里定义到二进制日志名和偏移量(当前日志的位置)

mysql> unlock tables;

 

 

Slave端:

①开启中继日志:

vi /etc/my.cnf

relay_log=mysql-relay //开启中继日志
relay_log_index=mysql-relay.index //中继日志的索引文件
server-id = 2 //保证跟主服务不一致,原有的将1修改为2

②重启服务:

/etc/init.d/mysqld restart

③导入数据:

scp 192.168.1.1:/tmp/all.sql /tmp

source /root/.bash_profile 
mysql -uroot -p < /tmp/all.sql

####################################################################

#或者直接打包数据,这样能够节约时间,线上可能用到#

#cp -R /data/app/mysql/data /tmp#

#这时就可以执行下面的读取日志点的操作,然后解锁,然后在往下执行#

#tar cxvf /tmp/all.tar.gz /tmp/data#

##

####################################################################

④开启主从同步

mysql> change master to master_host="192.168.1.1",master_port=3306,master_user="slave",master_password="backup",master_log_file="mysql-bin.000002",master_log_pos=1306;

mysql> slave start; //开启从服务器
mysql> show slave status\G 确保这两行是Yes
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

 

删除备份sql

# rm -rf /tmp/all.sql

 

验证:

①master上查看slave的状态:

mysql> show slave hosts ;

+-----------+------+------+-----------+

| Server_id | Host | Port | Master_id |

+-----------+------+------+-----------+

|         3 |      | 3306 |         1 |

|         2 |      | 3306 |         1 |

+-----------+------+------+-----------+

2 rows in set (0.00 sec)

 

②master上添加数据查看从库是否及时更新

 

③查看从库的错误日志情况

tail -0f /data/app/mysql/data/mysql_error.log

 

如果该日志中出现大量的:

151224 14:09:40 [Note] Slave: received end packet from server, apparent master shutdown: 

151224 14:09:40 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000034' at position 3621049

151224 14:09:40 [Note] Slave: received end packet from server, apparent master shutdown: 

151224 14:09:40 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000034' at position 3621049

151224 14:09:40 [Note] Slave: received end packet from server, apparent master shutdown: 

151224 14:09:40 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000034' at position 3621049

151224 14:09:40 [Note] Slave: received end packet from server, apparent master shutdown: 

151224 14:09:40 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000034' at position 3621049

原因是server-id出现重复,应该考虑到master的ID 和其他的salve的ID

 

 

-------------------------------------------------
问题:
1、如果change语句有问题
mysql> slave stop;
再重新执行change那一句。
2、ab复制配置失效
删除master.info文件
删除relay-log.info
服务重启
重新操作
------------------------------------------------- 
出现的问题:
1、change语句里面多空格或错误
2、同步数据的账号无法连接主服务器
1)账号密码错误
2)少了skip-name-resolve这一行,不能远程登录
-----------------------------------------------------



本文转自 dengaosky 51CTO博客,原文链接:http://blog.51cto.com/dengaosky/1854002,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
技术小阿哥
+ 关注