MySql数据库从同步负载均衡实时备份描述

数据库 MySQL
下面的文章主要讲述的是MySql数据库主从同步负载均衡实时的备份的实际操作步骤,以下就是正文的详细内容的介绍。

如果你对MySql数据库主从同步负载均衡实时的备份,的实际操作步骤感到很是很郁闷时。你就可以浏览下面的文章了,我在一个信誉度很好的网站找到一个关于MySql数据库主从同步负载均衡实时的备份的实际操作。供大家分享。

最近将四台MySQL数据库服务器配置成主从模式以实现一定的负载均衡,好象还可以接受,至少现在没有出什么大问题。

MySQL同步机制基于master把所有对数据库的更新、删除 等)都记录在二进制日志里。因此,想要启用同步机制,在master就必须启用二进制日志。每个slave接受来自master上在二进制日志中记录的更新操作,因此在slave上执行了这个操作的一个拷贝。应该非常重要地意识到,二进制日志只是从启用二进制日志开始的时刻才记录更新操作的。所有的slave必须在启用二进制日志时把master上已经存在的数据拷贝过来。如果运行同步时slave上的数据和master上启用二进制日志时的数据不一致的话,那么slave同步就会失败。

把master上的数据拷贝过来的方法之一实在slave上执行 LOAD DATA FROM MASTER 语句。不过要注意,LOAD DATA FROM MASTER 是从MySQL 4.0.0之后才开始可以用的,而且只支持master上的 MyISAM 类型表。同样地,这个操作需要一个全局的读锁,这样的话传送日志到slave的时候在master上就不会有更新操作了。

当实现了自由锁表热备份时(在MySQL 5.0中),全局读锁就没必要了。由于有这些限制,因此我们建议只在master上相关数据比较小的时候才执行 LOAD DATA FROM MASTER 语句,或者在master上允许一个长时间的读锁。由于每个系统之间 LOAD DATA FROM MASTER 的速度各不一样,一个比较好的衡量规则是每秒能拷贝1MB数据。这只是的粗略的估计,不过master和slave都是奔腾700MHz的机器且用100MBit/s网络连接时就能达到这个速度了。

slave上已经完整拷贝master数据后,就可以连接到master上然后等待处理更新了。如果master当机或者slave连接断开,slave会定期尝试连接到master上直到能重连并且等待更新。重试的时间间隔由 –master-connect-retry 选项来控制,它的默认值是60秒。每个slave都记录了它关闭时的日志位置。msater是不知道有多少个slave连接上来或者哪个slave从什么时候开始更新。

MySQL数据库同步功能由3个线程(master上1个,slave上2个)来实现。执行 START SLAVE 语句后,slave就创建一个I/O线程。I/O线程连接到master上,并请求master发送二进制日志中的语句。master创建一个线程来把日志的内容发送到slave上。这个线程在master上执行 SHOW PROCESSLIST 语句后的结果中的 Binlog Dump 线程便是。

slave上的I/O线程读取master的 Binlog Dump 线程发送的语句,并且把它们拷贝到其数据目录下的中继日志(relay logs)中。第三个是SQL线程,salve用它来读取中继日志,然后执行它们来更新数据。如上所述,每个mster/slave上都有3个线程。每个master上有多个线程,它为每个slave连接都创建一个线程,每个slave只有I/O和SQL线程。

在MySQL 4.0.2以前,同步只需2个线程(master和slave各一个)。slave上的I/O和SQL线程合并成一个了,它不使用中继日志。slave上使用2个线程的优点是,把读日志和执行分开成2个独立的任务。执行任务如果慢的话,读日志任务不会跟着慢下来。

例如,如果slave停止了一段时间,那么I/O线程可以在slave启动后很快地从master上读取全部日志,尽管SQL线程可能落后I/O线程好几的小时。如果slave在SQL线程没全部执行完就停止了,但I/O线程却已经把所有的更新日志都读取并且保存在本地的中继日志中了,因此在slave再次启动后就会继续执行它们了。这就允许在master上清除二进制日志,因为slave已经无需去master读取更新日志了。执行 SHOW PROCESSLIST 语句就会告诉我们所关心的master和slave上发生的情况。 下面我们来具体配置

1. 在主服务器上为从服务器建立一个用户:

grant replication slave on *.* to ‘用户名‘@’主机’ identified by ‘密码’; (在MySQL 数据库4 dot 0.2以前,用 FILE 权限来代替 REPLICATION SLAVE)

如果打算在slave上执行 LOAD TABLE FROM MASTER 或 LOAD DATA FROM MASTER 语句,那么必须给该帐户授予附加权限:
授予全局 SUPER 和 RELOAD 权限。

授予对想要加载的所有表上的 SELECT 权限。在master上任何没有 SELECT 权限的表都会被 LOAD DATA FROM MASTER 略过。

2. 编辑主服务器的配置文件:/etc/my.cnf

server-id = 1

log-bin

binlog-do-db=需要备份的数据库名,如果备份多个数据库,重复设置这个选项即可

binlog-ignore-db=不需要备份的数据库苦命,如果备份多个数据库,重复设置这个选项即可

3. 编辑从服务器的配置文件:/etc/my.cnf

server-id=2 (配置多个从服务器时依次设置id号)

master-host=主机

master-user=用户名

master-password=密码

master-port=端口

replicate-do-db=需要备份的数据库名,如果备份多个数据库,重复设置这个选项即可

记得先手动同步一下主从服务器中要备份的数据库,然后重启主,从服务器。

要验证主从设置是否已经成功,可以登录从服务器输入如下命令:

 

  1. mysql> show slave status\G 

得到的列表会有类似下面的数据:

 

  1. Slave_IO_State: Waiting for master to send event  
  2. Slave_IO_Running: Yes  
  3. Slave_SQL_Running: Yes 

如果后面两个选项不全是Yes,那就说明你前面某个步骤配置错了。

如果你的设置是正确的,尝试在主服务器上插入若干条记录,然后你再转到从服务器,会发现相应的新记录已经自动同步过来了。

如果你的主从服务器已经配置好了,那么你在应用程序中,只要保证所有的insert/delete/update操作是在主服务器上进行的,那么相应的数据变化会自动同步到从服务器上,这样,我们就可以把select操作分担到多台从数据库上,从而降低服务器的载荷。

如果你想使用复制数据文件的方式来备份数据库,只要在从服务器上的mysql数据库命令行先键入slave stop;然后复制数据库文件,复制好了,再在mysql命令行键入slave start;启动从服务器,这样就即备份了数据有保证了数据完整性,而且整个过程中主服务器的mysql无需停止。

提示:如果修改了主服务器的配置,记得删除从服务器上的master.info文件。否则从服务器使用的还是老配置,可能会导致错误。

注意:关于要复制多个数据库时,binlog-do-db和replicate-do-db选项的设置,如果要备份多个数据库,只要重复设置相应选项就可以了。

比如:

 

  1. binlog-do-db=a 
  2. bbinlog-do-db=b  
  3. replicate-do-db=a  
  4. replicate-do-db=b  

 

补充:

在从服务器上使用show slave status

Slave_IO_Running,为No,则说明IO_THREAD没有启动,请执行slave start [IO_THREAD]

Slave_SQL_Running为No则复制出错,查看Last_error字段排除错误后执行slave start [SQL_THREAD]

【编辑推荐】

  1. 解决MySQL中文乱码的方法归纳
  2. MySQL 安装备份在Linux系统中的安装
  3. MySQL 数据库的双机热备实际操作配置
  4. 建立MySQL镜像数据库在linux下的简单方案
  5. Mysql安装与qmail实际操作概述
责任编辑:佚名 来源: 博客园
相关推荐

2010-05-07 13:14:22

数据库负载均衡

2020-09-21 11:30:28

CanalMySQL数据库

2010-05-07 13:09:06

2010-04-21 17:16:15

2010-05-10 18:05:09

2010-04-22 13:03:20

负载均衡功能

2012-10-19 10:21:07

数据库负载均衡mssqlserver

2010-04-15 09:27:37

Oracle数据库

2019-07-23 10:43:28

MariaDB数据库MySQL

2010-08-27 09:59:51

SQL Server

2010-06-09 14:04:34

MySQL数据库

2011-08-05 15:28:47

MySQL数据库集群负载均衡

2010-04-21 16:57:18

数据库负载均衡

2012-05-29 18:05:00

2010-06-02 16:57:50

MySQL数据库同步

2020-07-20 08:02:16

MySQL数据库Nginx

2011-03-31 14:34:46

cactimysql备份

2011-03-30 13:57:41

MySQL数据库自动备份

2019-03-01 13:40:01

MySQL数据库备份案例

2010-05-10 14:27:19

线路负载均衡
点赞
收藏

51CTO技术栈公众号