百分百源码网-让建站变得如此简单! 登录 注册 签到领金币!

主页 | 如何升级VIP | TAG标签

当前位置: 主页>网站教程>数据库> MySql主从复制有哪些?怎样配置实现?
分享文章到:

MySql主从复制有哪些?怎样配置实现?

发布时间:08/01 来源:未知 浏览: 关键词:
本篇文章给大家带来的内容是介绍MySql主从复制有哪些?怎样配置实现?有一定的参照 价值,有需要的伴侣可以参照 一下,但愿对你有所帮忙。 本篇文章给大家带来的内容是介绍MySql主从复制有哪些?怎样配置实现?有一定的参照 价值,有需要的伴侣可以参照 一下,但愿对你有所帮忙。

一、什么是Mysql主从复制

MySQL主从复制是其最重要的功能之一。主从复制是指一台办事器充当主数据库办事器,另一台或多台办事器充当从数据库办事器,主办事器中的数据主动复制到从办事器之中。关于多级复制,数据库办事器即可充当主机,也可充当从机。MySQL主从复制的根基是主办事器对数据库修改记载二进制日志,从办事器通过主办事器的二进制日志主动施行更新。

二、Mysq主从复制的类型

1、基于语句的复制:

主办事器上面施行的语句在从办事器上面再施行一遍,在MySQL-3.23版本今后支撑。

存在的题目:工夫上可能不完全同步造成偏向,施行语句的会员也可能是不一样一个会员。

2、基于行的复制:

把主办事器上面改编后的内容直接复制已往,而不体贴到底转变该内容是由哪条语句激发的,在MySQL-5.0版本今后引入。

存在的题目:比方一个薪水表中有一万个会员,我们把每个会员的薪水+1000,那么基于行的复制则要复制一万行的内容,由此造成的开销比拼大,而基于语句的复制仅仅一条语句就可以了。

3、混合类型的复制:

MySQL默许运用基于语句的复制,当基于语句的复制会激发题目的时候就会运用基于行的复制,MySQL会主动进行选中。

在MySQL主从复制架构中,读操纵可以在所有的办事器上面进行,而写操纵只能在主办事器上面进行。主从复制架构虽然给读操纵供给了扩展,可要是写操纵也比拼多的话(多台从办事器还要从主办事器上面同步数据),单主模型的复制中主办事器势必会成为机能瓶颈。

三、Mysql主从复制的工作道理

1、基于语句的复制:主办事器上面施行的语句在从办事器上面再施行一遍,在MySQL-3.23版本今后支撑。

存在的题目:工夫上可能不完全同步造成偏向,施行语句的会员也可能是不一样一个会员。

2、基于行的复制:把主办事器上面改编后的内容直接复制已往,而不体贴到底转变该内容是由哪条语句激发的,在MySQL-5.0版本今后引入。

存在的题目:比方一个薪水表中有一万个会员,我们把每个会员的薪水+1000,那么基于行的复制则要复制一万行的内容,由此造成的开销比拼大,而基于语句的复制仅仅一条语句就可以了。

3、混合类型的复制:MySQL默许运用基于语句的复制,当基于语句的复制会激发题目的时候就会运用基于行的复制,MySQL会主动进行选中。

在MySQL主从复制架构中,读操纵可以在所有的办事器上面进行,而写操纵只能在主办事器上面进行。主从复制架构虽然给读操纵供给了扩展,可要是写操纵也比拼多的话(多台从办事器还要从主办事器上面同步数据),单主模型的复制中主办事器势必会成为机能瓶颈。

三 MySQL主从复制工作道理

如下图所示:

配置Master的my.cnf文件(关键性的配置)/etc/my.cnf

log-bin=mysql-bin

server-id   = 1

binlog-do-db=icinga

binlog-do-db=DB2     //要是备份多个数据库,反复设定这个选项即可

binlog-do-db=DB3   //需要同步的数据库,要是没有本行,即表示同步所有的数据库

binlog-ignore-db=mysql  //被忽略的数据库

配置Slave的my.cnf文件(关键性的配置)/etc/my.cnf

log-bin=mysql-bin

server-id=2

master-host=10.1.68.110

master-user=backup

master-password=1234qwer

master-port=3306

replicate-do-db=icinga

replicate-do-db=DB2

replicate-do-db=DB3   //需要同步的数据库,要是没有本行,即表示同步所有的数据库

replicate-ignore-db=mysql   //被忽略的数据库

网友说replicate-do-db的运用中可能会出些题目(http://blog.knowsky.com/19696...),本人没有亲自去测试。猜想binlog-do-db参数用于主办事器中,通过过滤Binary Log来过滤掉配置文件中不允许复制的数据库,也就是不向Binary Log中写入不允许复制数据的操纵日志;而replicate-do-db用于从办事器中,通过过滤Relay Log来过滤掉不允许复制的数据库或表,也就是施行Relay Log中的行动时不施行那些不被允许的修改行动。这样的话,多个从数据库办事器的状况:有的从办事器既从主办事器中复制数据,又做为主办事器向别的的从办事器复制数据,那它的配置文件中应当可以同时存在binlog-do-db、replicate-do-db这两个参数才对。一切都是本人的预期,对于binlog-do-db、replicate-do-db的概括运用办法还得在现实开发中一点点探索才可以。

网上有说,复制时忽略某些数据库或者表的操纵最佳不要在主办事器上面进行,由于主办事器忽略之后就不会再往二进制文件中写了,但是在从办事器上面虽然忽略了某些数据库但是主办事器上面的这些操纵信息仍然会被复制到从办事器上面的relay log里面,只是不会在从办事器上面施行罢了。我想这个意思应当是倡议在从办事器中设定replicate-do-db,而不要在主办事器上设定binlog-do-db。

别的,无论是黑名单(binlog-ignore-db、replicate-ignore-db)还是白名单(binlog-do-db、replicate-do-db)只写一个就行了,要是同时运用那么只要白名单生效。

四、Mysql主从复制的历程

MySQL主从复制的两种状况:同步复制和异步复制,现实复制架构中大局部为异步复制。

复制的根本历程如下:

  1. Slave上面的IO进程连贯上Master,并要求从指定日志文件的指定位置(或者从最开端的日志)之后的日志内容。

  2. Master接收到来自Slave的IO进程的要求后,负责复制的IO进程会依据要求信息读取日志指定位置之后的日志信息,返回给Slave的IO进程。返回信息中除了日志所包括的信息以外,还包含本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置。

  3. Slave的IO进程接收到信息后,将接收到的日志内容顺次增加到Slave端的relay-log文件的最末端,并将读取到的Master端的 bin-log的文件名和位置记载到master-info文件中,以便鄙人一次读取的时候能够分明的告诉Master“我需要从某个bin-log的哪个位置开端日后的日志内容,请发给我”。

  4. Slave的Sql进程检测到relay-log中新添加了内容后,会即将解析relay-log的内容成为在Master端真实施行时候的那些可施行的内容,并在本身施行。

五、Mysql主从复制的概括配置

复制平常用来新建主节点的副本,通过增加冗余节点来保障高可用性,固然复制也可以用于其他用法,例如在从节点上进行数据读、剖析等等。在横向扩展的业务中,复制很容易实施,主要体现在在应用主节点进行写操纵,多个从节点进行读操纵,MySQL复制的异步性是指:事物第一在主节点上提交,然后复制给从节点并在从节点上利用,这样意味着在统一个工夫点主从上的数据可能纷歧致。异步复制的益处在于它比同步复制要快,要是对数据的一致性请求很高,还是采纳同步复制较好。

最简略的复制模式就是一主一从的复制模式了,这样一个简略的架构只需要三个步骤即可完成:

(1)创立一个主节点,开启binlog,设定办事器id;

(2)创立一个从节点,设定办事器id;

(3)将从节点连贯到主节点上。

下面我们开端操纵,以MySQL 5.5为例,操纵系统Ubuntu12.10,Master 10.1.6.159 Slave 10.1.6.191。

apt-get install mysql-server
Master机器

Master上面开启binlog日志,而且设定一个独一的办事器id,在局域网内这个id必需独一。二进制的binlog日志记载master上的所有数据库转变,这个日志会被复制到从节点上,而且在从节点上回放。修改my.cnf文件,在mysqld模块下修改如下内容:

[mysqld]
server-id   = 1
log_bin     = /var/log/mysql/mysql-bin.log

log_bin设定二进制日志所发生文件的根本名称,二进制日志由一系列文件组成,log_bin的值是可选项,要是没有为log_bin设定值,则默许值是:主机名-bin。要是随意修改主机名,则binlog日志的名称也会被转变的。server-id是用来独一标识一个办事器的,每个办事器的server-id都不同。这样slave连贯到master后,会要求master将所有的binlog通报给它,然后将这些binlog在slave上回放。为了防止权限凌乱,个别都是创立一个独自用于复制的账户。

binlog是复制历程的关键,它记载了数据库的所有转变,平常马上施行结束的语句会在binlog日志的末尾写入一笔记录,binlog只记载转变数据库的语句,关于不转变数据库的语句则不进行记载。这种状况叫做基于语句的复制,前面提到过还有一种状况是基于行的复制,两种模式各有各的优缺陷。

Slave机器

slave机器和master同样,需要一个独一的server-id。

[mysqld]
server-id = 2

连贯Slave到Master

在Master和Slave都配置好后,只需要把slave只想master即可

change master to master_host='10.1.6.159',master_port=3306,master_user='rep',
master_password='123456';
start slave;

接下来在master上做一些针对转变数据库的操纵,来调查slave的变化状况。在修改完my.cnf配置重新启动数据库后,就开端记载binlog了。可以在/var/log/mysql名目下看到一个mysql-bin.000001文件,并且还有一个mysql-bin.index文件,这个mysql-bin.index文件有哪些?这个文件保留了所有的binlog文件列表,但是我们在配置文件中并没有设定改值,这个可以通过log_bin_index进行设定,要是没有设定改值,则默许值和log_bin同样。在master上施行show binlog events下令,可以看到首先个binlog文件的内容。

注意:上面的sql语句是从头开端复制首先个binlog,要是想从某个位置开端复制binlog,就需要在change master to时指定要开端的binlog文件名和语句在文件中的起点位置,参数如下:master_log_file和master_log_pos。

mysql> show binlog events\G
*************************** 1. row ***************************
   Log_name: mysql-bin.000001
        Pos: 4
 Event_type: Format_desc
  Server_id: 1
End_log_pos: 107
       Info: Server ver: 5.5.28-0ubuntu0.12.10.2-log, Binlog ver: 4
*************************** 2. row ***************************
   Log_name: mysql-bin.000001
        Pos: 107
 Event_type: Query
  Server_id: 1
End_log_pos: 181
       Info: create user rep
*************************** 3. row ***************************
   Log_name: mysql-bin.000001
        Pos: 181
 Event_type: Query
  Server_id: 1
End_log_pos: 316
       Info: grant replication slave on *.* to rep identified by '123456'
3 rows in set (0.00 sec)
  • Log_name 是二进制日志文件的名称,一个事件不克不及横跨两个文件

  • Pos 这是该事件在文件中的开端位置

  • Event_type 事件的类型,事件类型是给slave通报信息的根本办法,每个新的binlog都已Format_desc类型开端,以Rotate类型完毕

  • Server_id 新建该事件的办事器id

  • End_log_pos 该事件的完毕位置,也是下一个事件的开端位置,因而事件范畴为Pos~End_log_pos-1

  • Info 事件信息的可读文本,不一样的事件有不一样的信息

示例

在master的test库中新建一个rep表,并插入一笔记录。

create table rep(name var);
insert into rep values ("guol");
flush logs;

flush logs下令强迫轮转日志,生成一个新的二进制日志,可以通过show binlog events in 'xxx'来查看该二进制日志。可以通过show master status查看目前正在写入的binlog文件。这样就会在slave上施行响应的转变操纵。

上面就是最简略的主从复制模式,不外有时候随着工夫的推动,binlog会变得非常巨大,要是新添加一台slave,从头开端复制master的binlog文件是非常耗时的,所以我们可以从一个指定的位置开端复制binlog日志,可以通过其他办法把之前的binlog文件进行迅速复制,例如copy物理文件。在change master to中有两个参数可以实现该功能,master_log_file和master_log_pos,通过这两个参数指定binlog文件及其位置。我们可以从master上复制也可以从slave上复制,假设我们是从master上复制,概括操纵历程如下:

(1)为了防止在操纵历程中数据更新,致使数据纷歧致,所以需要先刷新数据并锁定数据库:flush tables with read lock。

(2)检查目前的binlog文件及其位置:show master status。

mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin.000003
Position: 107
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

(3)通过mysqldump下令新建数据库的逻辑备分:mysqldump --all-databases -hlocalhost -p >back.sql。

(4)有了master的逻辑备份后,对数据库进行解锁:unlock tables。

(5)把back.sql复制到新的slave上,施行:mysql -hlocalhost -p 把master的逻辑备份插入slave的数据库中。

(6)此刻可以把新的slave连贯到master上了,只需要在change master to中多设定两个参数master_log_file='mysql-bin.000003'和master_log_pos='107'即可,然后启动slave:start slave,这样slave就可以接着107的位置进行复制了。

change master to master_host='10.1.6.159',master_port=3306,master_user='rep',
master_password='123456',master_log_file='mysql-bin.000003',master_log_pos='107';
start slave;

有时候master并不克不及让你锁住表进行复制,由于可能跑一些不间断的办事,要是这时master已经有了一个slave,我们则可以通过这个slave进行再次扩展一个新的slave。道理同在master上进行复制差未几,关键在于寻到binlog的位置,你在复制的同时可能该slave也在和master进行同步,操纵如下:

(1)为了防止数据变更,还是需要休止slave的同步:stop slave。

(2)然后刷新表,并用mysqldump逻辑备份数据库。

(3)运用show slave status查看slave的相干信息,记载下两个字段的值Relay_Master_Log_File和Exec_Master_Log_Pos,这个用来肯定从背面哪里开端复制。

(4)对slave解锁,把备份的逻辑数据库导入新的slave的数据库中,然后设定change master to,这一步和复制master同样。

六、深入理解Mysql主从配置

1、一主多从

由一个master和一个slave组成复制系统是最简略的状况。Slave之间并不彼此通讯,只能与master进行通讯。在现实利用场景中,MySQL复制90%以上都是一个Master复制到一个或者多个Slave的架构模式,主要用于读压力比拼大的利用的数据库端便宜扩展解决方案。

这种构造的长处就是供给了冗余。在地理上散布的复制构造,它不存在单一节点故障题目,并且还可以将读密集型的要求放到slave上。

5、MySQL-5.5支撑半同步复制

早前的MySQL复制只能是基于异步来实现,从MySQL-5.5开端,支撑半主动复制。在之前的异步(asynchronous)复制中,主库在施行完一些事务后,是不会管备库的进度的。要是备库处于降后,而更不幸的是主库此时又涌现Crash(例如宕机),这时备库中的数据就是不完备的。简而言之,在主库产生故障的时候,我们没法运用备库来继续供给数据一致的办事了。Semisynchronous Replication(半同步复制)则一定程度上保障提交的事务已经传给了至少一个备库。Semi synchronous中,仅仅保障事务的已经通报到备库上,但是并不确保已经在备库上施行完成了。

此外,还有一种状况会致使主备数据纷歧致。在某个session中,主库上提交一个事务后,会期待事务通报给至少一个备库,要是在这个期待历程中主库Crash,那么也可能备库和主库纷歧致,这是很致命的。要是主备网络故障或者备库挂了,主库在事务提交后期待10秒(rpl_semi_sync_master_timeout的默许值)后,就会继续。这时,主库就会变回本来的异步状态。

MySQL在加载并开启Semi-sync插件后,每一个事务需期待备库接收日志后才返回给客户端。要是做的是小事务,两台主机的推迟又较小,则Semi-sync可以实此刻机能很小亏损的状况下的零数据遗失。

以上就是本篇文章的全部内容,但愿能对大家的学习有所帮忙。更多出色内容大家可以关注 百分百源码网 相干教程栏目!!!

以上就是MySql主从复制有哪些?怎样配置实现?的细致内容,更多请关注 百分百源码网 其它相干文章!

打赏

打赏

取消

感谢您的支持,我会继续努力的!

扫码支持
扫码打赏,你说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦

百分百源码网 建议打赏1~10元,土豪随意,感谢您的阅读!

共有152人阅读,期待你的评论!发表评论
昵称: 网址: 验证码: 点击我更换图片
最新评论

本文标签

广告赞助

能出一分力是一分吧!

订阅获得更多模板

本文标签

广告赞助

订阅获得更多模板