加载中…
个人资料
绝世流浪汉
绝世流浪汉
  • 博客等级:
  • 博客积分:0
  • 博客访问:86,140
  • 关注人气:10
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
谁看过这篇博文
加载中…
正文 字体大小:

【DBA】MYSQL的replication配置

(2012-04-06 18:27:36)
标签:

mysql

replication

数据库同步

分类: DBA
  本文是自己写给自己的一篇Mysql Replication配置相关的笔记。有兴趣的同学可以看看,如要转载,请注明出处。只要不是用于商业用途,可以随意分发。

1.概要

1.1 做Master-Slave 复制的優勢

保证数据库冗余
 在Master数据库出现宕机后,slave机器可以快速接管master的服务,从而减少了服务宕机时间

负载平衡
      让select等查询命令只在slave数据库上工作,从而减少了master的负担,达到负载平衡的目的。update       等更新,修改的命令则需要在master上被执行。

数据库的备份工作可以在slave机器上进行
数据库的备份工作可以集中在slave服务器上进行。 因为在数据库进行备份的时候,mysql为了保证数据的完整性,需禁止对数据库进行写操作,如果能在slave服务器上进行备份工作,则能保证master和slave都能正常工作。

1.2 replication的动作过程

   Mysql 的Replication 是一个异步的复制过程,从一个master服务器复制到另一个slave服务器上。在Master 与Slave 之间的实现整个复制过程主要由三个线程来完成,分别是BinlogDump(master端),IO和SQL(slave端)。

    要实现MySQL 的Replication ,必须打开Master 端的Binary Log(mysqlbin.xxxxxx)功能,否则无法实现。因为整个复制过程实际上就是Slave 从Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。该LOG只会写入更新的sql操作,不会写入例如select,show等查询操作(事实上一般的互联网服务读操作数量远远大于写操作数量,因此一台Master多台Slave的构架是能很合理的做到负载均衡的)。

MySQL 复制的基本过程如下(假设Master和Slave的配置已经完成,slave已经通过冷备份拷贝了一份Master的数据库快照):
1. Slave上面的IO线程主动连接Master,并请求获取从指定日志文件的指定位置之后的日志内容;

2. Master接收到来自Slave 的IO线程的请求后,通过负责复制的IO 线程根据请求信息读取指定日志(这个日志由master上的BinlogDump这个线程来生成)指定位置之后的日志信息,返回给Slave端的IO线程。返回信息中除了日志所包含的信息(实际上是一连串有顺序的sql更新命令的二进制表示形式)之外,还包括本次返回的信息在Master端的Binary Log文件的名称以及在Binary Log中的位置(position);

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

4. Slave的SQL 线程检测到Relay Log中新增加了内容后,会解析该Log文件中的内容成为在Master端真实执行时候的那些可执行的Query语句,并在Slave端按顺序执行这些Query。这样,实际上就是在Master端和Slave 端执行了同样的Query,所以两端的数据库最终是完全一样的。
   
  工作过程图显示如下:
【DBA】MYSQL的replication配置

    

通过上面的描述我们可以看出:
1 首先这个复制的过程是非同步的,也就是Slave和Master之间的数据理论上总有一段时间(影响这个时间的因素有很多,比如Master上某时间段内更新负荷特别大,导致Slave上运行sql命令延时较长)是不一样的,复制的过程并不在同一个事务完成。要完全解决这个问题,需要设计另一个叫做cluster的技术,这里不在展开描述。

2 由动作机制可见,就算Slave断网后一段时间在链接上Master,同样可以进行一个同步的过程,只是如果Master变化太多,可能会导致Slave的同步所花费的时间比较长。

3 binlog和 Relay Log 都是二进制文件,需要用mysqlbinlog命令打开查看,Relaylog和Binlog不同点在于,Relaylog默认情况下会在slave端的sql线程操控下自动删除(例如sql线程通过读取relay-log.info文件内容,认为某些sql文已经执行过,可以删除)

4 为什么在slave端要通过两个线程来处理复制的过程呢?主要是考虑到为了减少复制的延迟。假设有一个线程同时完成IO和sql线程的工作,那么存在某种处理时间比较长的sql文时,在处理该sql文就不能在从master copy 数据过来了。从而Slave和Mster之间的数据状态延迟也会增大。

5 slave主动通过I/O发起对master的请求连接,告诉mster需要哪个文件的什么位置之后的binlog,获得master端的反馈的数据后,之后的情况是,slave端的I/O进入休眠状态,他并不会按时对master进行轮询,而master只要有新的变化,就发送变化信息给slave ,slaveI/O接收到后激活线程,启动写操作,把变化信息写入Relay log。 除非本次的tcp会话断掉,否则slave不会再主动发送获取请求。

6 Mysql的复制是向后兼容的,也就是说较新的版本可以是老版本服务器的slave服务器,但是反过来则不行,因为老版本slave服务器可能不能解释新版本master服务传送过来的sql文


2.配置方法 (只描述经典Master-Slave构架)

2.1 Master端的配置

第一步需要打开binlog的开关,产生用于复制的binlog。可以在配置文件my.cnf里面配置,也可以在启动mysql时输入参数启动,另外还需要给master 服务器指定一个唯一的server-id
[mysqld] 
log-bin=local-bin    ###打开binlog开关 右边的值可以自由定制
server-id  = 10      ###确定唯一的serv-id 右边的值可以自由定制

修改my.cnf之后需要重启mysql。

2.2 配置用于复制的用户帐号


需要在Master端配置具有 REPLICATION SLAVE 权限的帐号,用来从slave连接过来时认证。

下面的例子是允许10.0.0.2(Slave服务器地址)生成用户 'chou'
(Master服务器上)
mysql> GRANT REPLICATION SLAVE ON *.* TO chou@10.0.0.2 IDENTIFIED BY 'password';

2.3 打包数据库

需要事先把master服务器上的数据库数据完全备份一份至slave服务器上(不仅仅是数据库的数据,而且需要备份master服务器上的当前的日志,以及当前的数据时间点,在mysql里面这两个因素叫做log file coordinates,他们一起确定了二进制日志的位置,另外如果在当前数据时间点开始到copy发生完成时的一段时间里,如果有新二进制日志文件生成,则需要把这部分二进制文件也copy)。

所以针对以上的说明,往往有冷备份,热备份,mysqldump,lvm snapshot等不同的备份方法,各有千秋。该处只针对冷备份进行说明

锁住数据库,不允许在copy阶段对数据库进行写操作
(Master服务器上)
mysql> FLUSH TABLES WITH READ LOCK;
确认已经锁住(Master服务器端)
mysql> SHOW MASTER STATUS;
+-----------------+----------+--------------+------------------+
| File            | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-----------------+----------+--------------+------------------+
| tank-bin.000001 |       79 |              |                  |
+-----------------+----------+--------------+------------------+
1 row in set (0.00 sec)

此处需要记录下啊bin日志的文件名,以及日志现在所处的位置(position),该数据在slave服务器启动的时候会用到。(因为有可能当master端解除lock,直到slave端启动的这段时间内,master端数据库有更新操作,必须要记住这个时间点的状态)

接下来就是备份数据了,因为已经在master端锁定了数据库,所以就可以直接用tar来处理,假设我们这里只备份 friendDB 

(Master端)
# cd /var/lib/mysql/               <== 进入mysql的数据目录
# tar cvf ~/friendDB.tar friendDB  <== 打包数据库 fiendDB
数据库备份完成之后,解除lock
(Master端)
mysql> UNLOCK TABLES;

2.4 数据库备份至slave端

上面打包完成的数据copy到slave服务器上后,在slave上的相应数据库目录里展开,要注意权限需要和master端保持一致。

# cd /var/lib/mysql/
# tar xvf  friendDB.tar

2.5 Slave端配置

配置slave端的my.cnf(这里只描述最基本的配置,事实上工作场景中不会这么简单,还需要一些其他可选项,以便适应实际的工程需求)
[mysqld] 
server-id=2 <== 定义了服务器id,注意不要和其他服务器重复
配置完成后启动mysql

2.6 开始replication

在slave执行如下命令,该命令确定了当slave发起replication请求的时,连接master的参数。(前面手动记录下来的信息,在这里派上用场)
(Slave端)
mysql> CHANGE MASTER TO
        MASTER_HOST='10.0.0.1',  <== Master服务器的ip地址
        MASTER_USER='chou',      <== Master连接master端的用户名
        MASTER_PASSWORD='password', <== 密码
        MASTER_LOG_FILE='tank-bin.000001', <==前文中确定的binlog文件名
        MASTER_LOG_POS=79;       <== 前文中确定的binlog位置信息

启动replication。
(Slave端)
 mysql> START SLAVE;

此时,master端后续变化的所有内容(binlog)都会被复制到slave端,在slave端完成执行,实现最后的同步。slave端之后重启也能实现自动同步了,因为此后slave端会从生成的master.info文件的内容中选取数据作为为新连接请求的参数比如日志名,位置,用户名,密码等。

如果不能正常同步。可以查看slav端的错误日志,查看问题所在。

3. 一些相关的命令

3.1 START SLAVE/STOP SLAVE (Slave端用)

START SLAVE启动repication、STOP SLAVE关闭replication。

3.2 SHOW MASTER STATUS (Master端用)

现实当前的binlog名和所在位置(Log  Position

3.3 SHOW BINLOG EVENTS (Master端)

现实bilog中的事件内容

3.4 SHOW SLAVE STATUS (Slave端)

现实slave端的replication情况。
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 10.0.0.1
                Master_User: repl
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: tank-bin.000001
                <略>

 Slave_IO_Running,Slave_SQL_Running 值为yes的话,表示replication在正常运行。

Seconds_Behind_Master表示现在slave端最后执行的query语句对比于master端所延迟的秒数,是一个大概值,它表示了salve要完全同步到master端的状态需要花费的时间。


                                                                              ---andy  chou

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有