当前位置: 澳门新濠3559 > 数据库 > 正文

binlog=1表示每写缓冲一次就同步到磁盘,转载请注

时间:2019-12-09 01:05来源:数据库
MySQL复制解决了什么问题? 1、实现在不同服务器上的数据分布2、利用二进制日志增量进行3、不需要太多的带宽4、但是使用基于行的复制在进行大批量的更改时会对带宽带来一定的压力

MySQL复制解决了什么问题?

1、实现在不同服务器上的数据分布
2、利用二进制日志增量进行
3、不需要太多的带宽
4、但是使用基于行的复制在进行大批量的更改时会对带宽带来一定的压力,特别是跨IDC环境下进行复制
5、实现在不同服务上的数据分布
6、实现数据读取的负载均衡、需要其它组件配合完成、使用DNS轮训的方式把程序的读连接到不同的备份数据库
7、使用LVS,Haproxy这样的代理方式
8、实现了数据读取的负载均衡
9、增强了数据安全性
10、实现数据库高可用和故障切换
11、实现数据库在线升级

MySQL5.6基于GTID的主从复制,mysql5.6gtid主从

MySQL 5.6 的新特性之一,是加入了全局事务 ID (GTID) 来强化数据库的主备一致性,故障恢复,以及容错能力。

什么是GTID?

官方文档: ID 的官方定义是:GTID = source_id:transaction_id

MySQL 5.6 中,每一个 GTID 代表一个数据库事务。在上面的定义中,source_id 表示执行事务的主库 uuid(server_uuid),transaction_id 是一个从 1 开始的自增计数,表示在这个主库上执行的第 n 个事务。MySQL 会保证事务与 GTID 之间的 1 : 1 映射。

一、环境准备

操作系统:CentOS6.5 64位

数据库版本:MySQL5.6.23

图片 1

拓扑如下:

图片 2

三、安装主数据库(masterdb.example.com)

1、准备数据存放目录、创建用户

[[email protected] ~]#mkdir /data/mysqldata -p #创建数据存放目录
[[email protected] ~]#mkdir /data/mysqlLog/logs -p #创建日志存放目录
[[email protected] ~]#groupadd -r mysql
[[email protected] ~]#useradd -g mysql -r -s /sbin/nologin -M -d /data/mysqldata mysql
[[email protected] ~]#chown -R mysql:mysql /data/mysqldata
[[email protected] ~]#chown -R mysql:mysql /data/mysqlLog/logs

 2、安装并初始化mysql5.6.23

[[email protected] ~]# tar xf mysql-advanced-5.6.23-linux-glibc2.5-x86_64.tar.gz -C /usr/local/
[[email protected] ~]# cd /usr/local/
[[email protected] ~]# ln -sv mysql-advanced-5.6.23-linux-glibc2.5-x86_64 mysql
[[email protected] ~]# chown -R root.mysql mysql
[[email protected] ~]# cd mysql
[[email protected] ~]# cp support-files/mysql.server /etc/rc.d/init.d/mysqld
[[email protected] ~]# cp support-files/my-default.cnf /etc/my.cnf
[[email protected] ~]# chmod +x /etc/rc.d/init.d/mysqld
[[email protected] ~]# chkconfig --add mysqld
[[email protected] ~]# chkconfig mysqld on
[[email protected] ~]# ./scripts/mysql_install_db --user=mysql --datadir=/data/mysqldata/ 

3、输出mysql的man手册至man命令的查找路径:

编辑/etc/man.config,添加如下行即可:
MANPATH  /usr/local/mysql/man

4、输出mysql的头文件至系统头文件路径/usr/include:

这可以通过简单的创建链接实现:

[[email protected] ~]#ln -sv /usr/local/mysql/include /usr/include/mysql

5、输出mysql的库文件给系统库查找路径:

[[email protected] ~]#echo '/usr/local/mysql/lib' > /etc/ld.so.conf.d/mysql.conf

而后让系统重新载入系统库:

[[email protected] ~]# ldconfig

6、修改PATH环境变量,让系统可以直接使用mysql的相关命令:

[[email protected] ~]# vim /etc/profile.d/mysql.sh
export PATH=$PATH:/usr/local/mysql/bin
[[email protected] ~]#source /etc/profile.d/mysql.sh

从数据库安装同上,具体过程略过。

四、分别为主从数据库提供配置文件/etc/my.cnf

要在MySQL 5.6中使用复制功能,其服务配置段[mysqld]中于少应该定义如下选项:
binlog-format:二进制日志的格式,有row、statement和mixed几种类型;
需要注意的是:当设置隔离级别为READ-COMMITED必须设置二进制日志格式为ROW,现在MySQL官方认为STATEMENT这个已经不再适合继续使用;但mixed类型在默认的事务隔离级别下,可能会导致主从数据不一致;
log-slave-updates、gtid-mode、enforce-gtid-consistency、report-port和report-host:用于启动GTID及满足附属的其它需求;
master-info-repository和relay-log-info-repository:启用此两项,可用于实现在崩溃时保证二进制及从服务器安全的功能;
sync-master-info:启用之可确保无信息丢失;
slave-paralles-workers:设定从服务器的SQL线程数;0表示关闭多线程复制功能;
binlog-checksum、master-verify-checksum和slave-sql-verify-checksum:启用复制有关的所有校验功能;
binlog-rows-query-log-events:启用之可用于在二进制日志记录事件相关的信息,可降低故障排除的复杂度;
log-bin:启用二进制日志,这是保证复制功能的基本前提;
server-id:同一个复制拓扑中的所有服务器的id号必须惟一;

主数据库上:

[client]
port = 3306
socket = /tmp/mysql.sock
default-character-set = utf8
[mysql]
no-auto-rehash
default-character-set = utf8

[mysqld]
server-id = 1
port = 3306
user = mysql
basedir = /usr/local/mysql
datadir = /data/mysqldata
socket = /tmp/mysql.sock
default-storage-engine = INNODB
character-set-server = utf8
connect_timeout = 60
interactive_timeout = 28800
wait_timeout = 28800
back_log = 500
event_scheduler = ON
skip_name_resolve = ON;

###########binlog##########
log-bin = /data/mysqlLog/logs/mysql-bin
binlog_format = row
max_binlog_size = 128M
binlog_cache_size = 2M
expire-logs-days = 5
log-slave-updates=true
gtid-mode=on
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=4
#rpl_semi_sync_master_enabled = 1

slow_query_log = 1
slow_query_log_file = /data/mysqlLog/logs/mysql.slow
long_query_time = 1

log_error = /data/mysqlLog/logs/error.log
max_connections = 3000
max_connect_errors = 32767
log_bin_trust_function_creators = 1
transaction_isolation = READ-COMMITTED

binlog=1表示每写缓冲一次就同步到磁盘,转载请注明出处。从数据库上:

[client]
port = 3306
socket = /tmp/mysql.sock
default-character-set = utf8

[mysql]
no-auto-rehash
default-character-set = utf8

[mysqld]
server-id = 205
port = 3306
user = mysql
basedir = /usr/local/mysql
datadir = /data/mysqldata
socket = /tmp/mysql.sock
default-storage-engine = INNODB
character-set-server = utf8
connect_timeout = 60
wait_timeout = 18000
back_log = 500
event_scheduler = ON

###########binlog##########
log-bin = /data/mysqlLog/logs/mysql-bin
binlog_format = row
max_binlog_size = 128M
binlog_cache_size = 2M
expire-logs-days = 5
log-slave-updates=true
gtid-mode=on 
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=4
#rpl_semi_sync_slave_enabled = 1
skip-slave-start

slow_query_log = 1
slow_query_log_file = /data/mysqlLog/logs/mysql.slow
long_query_time = 2

log-error = /data/mysqlLog/logs/error.log
max_connections = 3000
max_connect_errors = 10000
log_bin_trust_function_creators = 1
transaction_isolation = READ-COMMITTED

五、分别在主从数据库上启动mysqld服务

[[email protected] ~]# service mysqld start
Starting MySQL......          [ OK ]
[[email protected] ~]# 


[[email protected] ~]# service mysqld start
Starting MySQL......          [ OK ]
[[email protected] ~]# 

六、在主数据库上创建复制用户
复制代码 代码如下:mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected] IDENTIFIED BY 'replpassword';
说明:172.16.88.205是从节点服务器;如果想一次性授权更多的节点,可以自行根据需要修改;

七、启动从数据库上的复制线程

mysql> CHANGE MASTER TO MASTER_HOST='masterdb.example.com', MASTER_USER='repluser', MASTER_PASSWORD='replpassword', MASTER_AUTO_POSITION=1;
mysql>start slave;

八、在从数据库上查看复制状态

mysql> show slave statusG;
*************************** 1. row ***************************
    Slave_IO_State: Waiting for master to send event
     Master_Host: masterdb.56xyl.com
     Master_User: repluser
     Master_Port: 3306
    Connect_Retry: 60
    Master_Log_File: mysql-bin.000002
   Read_Master_Log_Pos: 191
    Relay_Log_File: slavedb-relay-bin.000003
    Relay_Log_Pos: 401
  Relay_Master_Log_File: mysql-bin.000002
    Slave_IO_Running: Yes #IO线程已正常运行
   Slave_SQL_Running: Yes #SQL线程已正常运行
    Replicate_Do_DB: 
   Replicate_Ignore_DB: 
   Replicate_Do_Table: 
  Replicate_Ignore_Table: 
  Replicate_Wild_Do_Table: 
 Replicate_Wild_Ignore_Table: 
     Last_Errno: 0
     Last_Error: 
     Skip_Counter: 0
   Exec_Master_Log_Pos: 191
    Relay_Log_Space: 1899
    Until_Condition: None
    Until_Log_File: 
    Until_Log_Pos: 0
   Master_SSL_Allowed: No
   Master_SSL_CA_File: 
   Master_SSL_CA_Path: 
    Master_SSL_Cert: 
   Master_SSL_Cipher: 
    Master_SSL_Key: 
  Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
    Last_IO_Errno: 0
    Last_IO_Error: 
    Last_SQL_Errno: 0
    Last_SQL_Error: 
 Replicate_Ignore_Server_Ids: 
    Master_Server_Id: 1
     Master_UUID: 971d7245-c3f8-11e5-8b6b-000c2999e5a5
    Master_Info_File: mysql.slave_master_info
     SQL_Delay: 0
   SQL_Remaining_Delay: NULL
  Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
   Master_Retry_Count: 86400
     Master_Bind: 
  Last_IO_Error_Timestamp: 
  Last_SQL_Error_Timestamp: 
    Master_SSL_Crl: 
   Master_SSL_Crlpath: 
   Retrieved_Gtid_Set: 971d7245-c3f8-11e5-8b6b-000c2999e5a5:1-6
   Executed_Gtid_Set: 89e78301-c3f4-11e5-8b51-00505624d26a:1-3,
971d7245-c3f8-11e5-8b6b-000c2999e5a5:1-6
    Auto_Position: 1
1 row in set (0.00 sec)

ERROR: 
No query specified

mysql> 

九、测试

在主库上创建数据库:

mysql> create database log_statics;
Query OK, 1 row affected (0.11 sec)

mysql> use log_statics;
Database changed
到从数据库上查看log_statics是否已经复制过去
mysql> show databases;
+--------------------+
| Database   |
+--------------------+
| information_schema |
| log_statics  |
| mysql    |
| performance_schema |
+--------------------+
4 rows in set (0.01 sec)

mysql>

可以看到log_statics数据库已经存在于从数据库上。

以上就是本文的全部内容,希望对大家的学习有所帮助。

MySQL复制解决了什么问题?

前言

系列文章:1.MySQL主从复制2.OneProxy实现MySQL读写分离3.MySQL数据库结构设计4.MySQL基于GTID主从复制的杂谈5.MySQL复制性能优化和常见问题分析

先来说说影响MySQL复制性能的几个参数吧

二进制日志文件并不是每次写的时候都会同步到磁盘,当发生宕机的时候,可能会有最后一部分数据没有写入到binlog中,这给恢复和复制带来了问题。当sync_binlog=1表示每写缓冲一次就同步到磁盘,表示同步写磁盘的方式来写binlog。也就是说每当向MySQL提交一次事务,MySQL将进行一次fsync之类的磁盘同步命令来将binlog_cache的数据强制刷到磁盘中sync_binlog的值默认为0,sync_binlog=0时表示采用操作系统机制进行缓冲数据同步。采用sync_binlog=1时,会增加磁盘IO的次数,会影响写入性能。sync_binlog=1时,并不是100%安全,会存在相应的问题。比如说使用Innodb引擎时,在一个事务发出commit前,会将binlog立即刷到磁盘中。如果这时候已经写入到binlog中,但是还没有提交就已经挂了,那么MySQL重启时,会将通过Redo log、Undo log将这个事务回滚掉,但是binlog已经记入了该事务信息,不能回滚掉。所以我们需要设置innodb_support_xa=1确保MySQL服务层的binlog和MySQL存储引擎层的Redo log、Undo log之间的数据一致性。

sync_binlog=1

指定master_info和replay_log_info信息的存储方式为table。如果MySQL挂了的后,由于Innodb存储引擎的特点,可以对这2张表进行故障恢复,保证slave能从正确的位置进行数据恢复。

master_info_repository=TABLErelay_log_info_repository=TABLE

可以看到slave_master_info这张表存储着master的binlog以及当前master写入binlog的位置等信息。

mysql> select * from slave_master_infoG*************************** 1. row *************************** Number_of_lines: 25 Master_log_name: mysql-bin.000001 Master_log_pos: 914 Host: 192.168.10.21 User_name: gtid User_password: gtid Port: 3306 Connect_retry: 60 Enabled_ssl: 0 Ssl_ca: Ssl_capath: Ssl_cert: Ssl_cipher: Ssl_key: Ssl_verify_server_cert: 0 Heartbeat: 30 Bind: Ignored_server_ids: 0 Uuid: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026 Retry_count: 86400 Ssl_crl: Ssl_crlpath: Enabled_auto_position: 1 Channel_name: Tls_version: 1 row in set 

可以看到slave_relay_log_info记录了slave的relay log的位置、master binlog的名称,master binlog当前偏移量,relay log当前偏移量等信息。

mysql> select * from slave_relay_log_infoG*************************** 1. row *************************** Number_of_lines: 7 Relay_log_name: ./mysql-relay-bin.000004 Relay_log_pos: 831 Master_log_name: mysql-bin.000001 Master_log_pos: 914 Sql_delay: 0Number_of_workers: 16 Id: 1 Channel_name: 1 row in set 

当slave挂了后导致中继日志损坏后,导致一部分中继日志没有处理,则放弃所有未执行的relay log,并且重新从master获取日志,这样就保证了relay log的完整性。

relay_log_recovery=1

这些参数和sync_binlog参数一样,slave的IO线程每次接收到master发送过来的日志都要写入到系统缓冲区,然后再刷到磁盘中。这样master崩溃时,最多丢失一个事务。虽安全,但是会造成大量的磁盘IO。sync_relay_log、sync_relay_log_info、sync_master_info默认值都为10000

sync_relay_log=1sync_relay_log_info=1sync_master_info=1

图片 3image.png

默认是1,自动清空不需要的中继日志。

relay_log_purge=1

MySQL5.6有基于库的并行复制,可以设置slave-parallel-workers参数设置workers的个数。当开启并行复制功能后,那么SQL线程就变成了Coordinator线程。不同schema下的表并发提交的数据不会有影响,slave会对relay log中不同schema分配workers线程,来回放relay log中master已经提交的事务,保持数据一致性。如果单实例仅有一个库,开启并行复制功能后,那么就无法实现并行回放,甚至性能会比以前的单线程更差。

在MySQL5.7,引入了基于组提交的并行复制,设置slave-parallel-type=LOGICAL_CLOCK。支持在同一个schema下,支持slave-parallel-worker个worker线程并发回放relay log中master的事务。一个组提交的事务是可以并行回放的。在slave中的relay log中具有相同的last_committed值(sequence_num不同)的事务是属于同一个组的。

slave-parallel-type=LOGICAL_CLOCKslave-parallel-workers=16

图片 4image.png

选择复制模式需要考虑的几个点:1.所使用的MySQL。如果是5.6以上,可以考虑GTID复制。如果是5.6以下的,可以考虑binlog复制。2.复制架构及主从切换的方式。如果是一主多从,还是推荐GTID复制,不会为新master的binlog偏移量而担心。3.所使用的高可用管理组件。MMM只支持基于日志的方式。而MHA支持日志、GTID复制。

在MySQL5.7之前,一个从库只能有一个主库。MySQL5.7之后,支持一从多主架构。

一主多从的复制拓扑架构,配置简单,可以用多个从库分担读负载,使数据差异最小化。用途:1.为不同的业务使用不同的从库。2.将一台从库放到远程IDC,用于灾备恢复。3.分担主库的读负载。

主主复制拓扑架构,并不能分担写负载。缺点:1.经常产生数据冲突从而造成复制链路中断。2.耗费大量的时间,造成数据丢失。所以建议两个主库所操作的表最好能够分开,使用auto_increment_incrementauto_increment_offset=1|2参数控制自增ID的生成。

主主复制拓扑架构,只有一台主服务器对外提供服务,另一台服务器处于只读状态并且只作为热备使用。在对外提供服务的主库出现故障或是计划性的维护时才会进行切换。使用这种拓扑架构,需要注意以下几点:1.确保两台服务器上的初始数据相同。2.确保两台服务器上已经启动binlog,并且有不同的server_id。3.在两台服务器上启动log_slave_updates参数。4.在初始备库上启动ready_only。

影响主从延迟的因素:1.主库写入到二进制的时间。2.控制主库的事务大小,分割大事务。3.二进制日志传输时间取决于传输日志量的多少。推荐使用mixed日志格式。4.默认情况下从库只有一个sql线程。也就是说master上并发的修改在slave变成了串行。可以采用多线程复制(设置slave-parallel-type=LOGICAL_CLOCKslave-parallel-workers=16)。

在MySQL主从复制过程中,要注意以下问题:1.主库意外重启或者主库的二进制文件损坏。我们可以在slave上通过change master命令来重新指定binlog偏移量,同时配置sync_binlog=1使每次写入对binlog进行同步,落地磁盘,减少宕机所丢失的事务数。2.从库上的中继日志损坏。3.从库宕机,引起master.info文件没有及时更新到磁盘上。master.info记录着从库同步主库的相关信息,会引起从库重复同步的操作。4.在从库上进行数据修改造成的主从复制错误。5.不唯一的server_id或者server_uuid。6.max_allowed_packet设置引起的主从复制错误。

一般我们可以采用以下几种方法解决主从复制问题:1.跳过二进制日志文件。2.注入空事务的方式先恢复被中断的复制链路再使用其他方法来对比主从服务器上的数据。

MySQL复制无法解决的问题有哪些:1.分担主数据库的写负载。2.自行进行故障转移及主从切换。3.提供读写分离功能。

在这里,我们要可以引出一个概念,高可用。高可用性(HA,High Availability)指的是通过尽量缩短因日常维护操作和突发的系统崩溃所导致的停机时间,以提高系统和应用的可用性。

我们应该避免导致系统不可用的因素,减少系统不可用的时间。1.严重的主从延迟。2.主从复制中断。3.锁引起的大量阻塞。4.服务器磁盘空间耗尽,比如备份或者各种查询日志快速增长导致磁盘空被占满。或者是MySQL由于无法记录二进制日志,无法处理新的请求而产生的系统不可用的故障。5.性能糟糕的sql。6.表结构和索引没有优化。7.主从数据不一致。8.人为的操作失败等等。

那如何实现高可用呢?1.建立完善的监控及报警系统。2.对备份数据进行恢复测试。3.正确配置数据库环境。4.对不需要的数据进行归档和清理。5.增加系统冗余,保证发生系统不可用时可以尽快恢复。(避免存在单点故障,可以进行主从切换及故障转移)

在这里我们又要引出一个概念,单点故障。它是指在一个系统中提供相同功能的组件只有一个,如果这个组件失效了,就会影响整个系统功能的正常使用,组成应用系统的各个组件都有可能成为单点。那么我们如何避免MySQL单点故障呢?1.利用SUN共享存储或者DRBD磁盘复制来解决MySQL单点故障。2.MySQL主从复制(关于主从复制,我们该考虑3个点。一是主服务器切换后,该如何通知应用新master的ip地址。二是如何检查MySQL主服务器是否可用。三是如何处理从服务器和新主服务器之间的那种复制关系)

为了解决MySQL主从复制管理的痛点,才衍生出了MMM,MHA这些高可用的管理组件。在本文章的末尾,简单介绍一下MMM是什么。

MMM的主要作用是监控和管理MySQL的主主复制拓扑结构,并在当前的主服务器失效时,进行主和主备服务器之间的主从切换和故障转移等工作。

MMM可以在主库出现宕机时进行故障转移并且自动配置其他从服务器对新主服务器的复制。

使用MMM要考虑两点:一是如何找到从库对应的新主服务器的日志同步点。二是如果存在多个从库出现数据不一致的情况,如何处理。在一个繁忙的系统中,使用MMM有可能会造成数据丢失。

MMM提供了读,写虚拟IP。在主从服务器出现问题时可以自动迁移虚拟IP。

MySQL二进制日志

基于段的格式binlog_format=STATMENT
    优点:
       日志记录量相对较小,节约了磁盘及I/O网络
       只对一条记录修改或者插入
       row格式所产生的日质量小于段产生的日志量
     缺点:
        必须要记录上下文信息
        保证语句在从服务器上执行结果和在主服务器上一致

基于行的日志格式binlog_format=ROW
    优点:
        使用MySQL主从复制更加安全
        对每一行输几局的修改比基于段的复制高效
    缺点:
        记录日志量较大
        binlog_row_image=[FULL]MINIMAL|NOBLOG

混合日志格式binlog_format=MIXED
    特点:
        1、根据SQL语句由系统决策在基于段和基于行的日志格式中进行选择
        2、数据量的大小由所执行的SQL语句决定

如何选择二进制日志的格式?!
    建议
        Binlog_format=mixed 
        Binlog_fromat=row    (如果是在同一个机房内,同一个IDC机房内考虑复制数据的安全性,建议使用此选项)
            如果使用该格式,建议设置Binlog_row_image=minimal   (可以减少网络、磁盘I/O的负载)

您可能感兴趣的文章:

  • windows下MySQL5.6版本安装及配置过程附有截图和详细说明
  • Windows版Mysql5.6.11的安装与配置教程
  • linux mysql5.6版本的安装配置过程
  • shell监控脚本实例—监控mysql主从复制
  • linux系统下实现mysql热备份详细步骤(mysql主从复制)
  • MySQL主从复制的原理及配置方法(比较详细)
  • MySQL5.6基本优化配置
  • MySQL主从复制配置心跳功能介绍
  • Mysql主从复制(master-slave)实际操作案例
  • 在MySQL中使用GTIDs复制协议和中断协议的教程

MySQL 5.6 的新特性之一,是加入了全局事务 ID (GTID) 来强化数据库的主备一致性,故障恢复,以及容...

1、实现在不同服务器上的数据分布 2、利用二进制日志增量进行 3、不需要太多的带宽 4、但是使用基于行的复制在进行大批量的更改时会对带宽带来一定的压力,特别是跨IDC环境下进行复制 5、实现在不同服务上的数据分布 6、实现数据读取的负载均衡、需要其它组件配合完成、使用DNS轮训的方式把程序的读连接到不同的备份数据库 7、使用LVS,Haproxy这样的代理方式 8、实现了数据读取的负载均衡 9、增强了数据安全性 10、实现数据库高可用和故障切换 11、实现数据库在线升级
MySQL二进制日志

尾言

大家好,我是cmazxiaoma(寓意是沉梦昂志的小马),感谢各位阅读本文章。小弟不才。如果您对这篇文章有什么意见或者错误需要改进的地方,欢迎与我讨论。如果您觉得还不错的话,希望你们可以点个赞。希望我的文章对你能有所帮助。有什么意见、见解或疑惑,欢迎留言讨论。

最后送上:心之所向,素履以往。生如逆旅,一苇以航。

图片 5saoqi.png

MySQL二进制日志格式对复制的影响

基于SQL语句的复制(STATMENT)
    主库会记录进行修改的SQL语句,备库会读取重放SQL语句
   优点:
       1、生成的日质量少,节省网络传输的I/O
       2、并不强制要求主从数据库的表定义完全相同
       3、相比基于行的复制的方式更加的灵活
   缺点:
       1、对于非确定性的事件,无法保证主从数据赋值数据的一致性
       2、对于存储过程,触发器,自定义函数进行修改也可能造成数据不一致
       3、对比与基于行的复制方式在从上执行时需要更多的行锁

基于行的复制:
    优点:
        1、可以应用在任何SQL的复制包括非确定函数,存储过程等
        2、可以减少数据库锁的使用
    缺点:
        1、要求主从数据库的表结构相同,否则可能会中断复制
        2、无法在从上单独执行触发器

基于段的格式binlog_format=STATMENT 优点: 日志记录量相对较小,节约了磁盘及I/O网络 只对一条记录修改或者插入 row格式所产生的日质量小于段产生的日志量 缺点: 必须要记录上下文信息 保证语句在从服务器上执行结果和在主服务器上一致 基于行的日志格式binlog_format=ROW 优点: 使用MySQL主从复制更加安全 对每一行输几局的修改比基于段的复制高效 缺点: 记录日志量较大 binlog_row_image=[FULL]MINIMAL|NOBLOG 混合日志格式binlog_format=MIXED 特点: 1、根据SQL语句由系统决策在基于段和基于行的日志格式中进行选择 2、数据量的大小由所执行的SQL语句决定 如何选择二进制日志的格式?! 建议 Binlog_format=mixed Binlog_fromat=row (如果是在同一个机房内,同一个IDC机房内考虑复制数据的安全性,建议使用此选项) 如果使用该格式,建议设置Binlog_row_image=minimal (可以减少网络、磁盘I/O的负载)
MySQL二进制日志格式对复制的影响

MySQL复制工作方式

首先来个图来说明
图片 6

基于SQL语句的复制(STATMENT) 主库会记录进行修改的SQL语句,备库会读取重放SQL语句 优点: 1、生成的日质量少,节省网络传输的I/O 2、并不强制要求主从数据库的表定义完全相同 3、相比基于行的复制的方式更加的灵活 缺点: 1、对于非确定性的事件,无法保证主从数据赋值数据的一致性 2、对于存储过程,触发器,自定义函数进行修改也可能造成数据不一致 3、对比与基于行的复制方式在从上执行时需要更多的行锁 基于行的复制: 优点: 1、可以应用在任何SQL的复制包括非确定函数,存储过程等 2、可以减少数据库锁的使用 缺点: 1、要求主从数据库的表结构相同,否则可能会中断复制 2、无法在从上单独执行触发器
MySQL复制工作方式

上图的工作流程讲解
1、主将变更写入到二进制
2、从库读取主的二进制日志变更并写入到relay_log中
3、在从上重放relay_log中的日志
    基于SQL段(statment)的日志是在从库上重新执行记录的SQL语句
    基于行(row)日志则是在从库上直接应用对数据库行的修改

首先来个图来说明

配置MySQL复制

上图的工作流程讲解

基于日志点的复制配置步骤

1、主库上开启binlog的设置,只记录增删改
    修改/etc/my.cnf配置文件,并添加修改如下数据
        bin_log = mysql-bin  (binlog日志的名称,意思就是binlog的名称以mysql-bin开头)
        server_id = 100 (动态参数,可以通过在MySQL的命令行中进行修改set global server_id=100)
2、在主DB服务器上建立复制账号
    CREATE USER 'repl'@'IP段' IDENTIFIED BY 'repl用户的登录密码';
    GRANT REPLICATION SLAVE ON *.* TO 'repl'@'ip段';
3、配置从数据库服务器
    修改/etc/my.cnf
        bin_log = mysql-bin
        server_id = 101
        relay_log = mysql-relay-bin  (中继日志的名称,默认是主机名,建议自己定义个名称,避免更改主机名以后带来不便)
        log_slave_update = on [可选]   (是否把从服务器的重放二进制日志记录到本机的二进制日志中,以作为其他从服务器的主)
        read_only = on [可选]          (是否允许没有没有sql线程的用户进行写操作)
4、在主库进行锁表,并拿到binlog的日志点,进行主库的备份并把备份拷贝到从库上,备份两种方式如下
    mysqldump --master-data --single-transaction --triggers --routines --all-databases -uroot -p --lock-tables  >> all.sql
    xtrabackup --slvae-info
5、启动复制链路
    CHANGE MASTER TO MASERT_HOST='mast_host_ip',
                     MASTER_USER=‘repl’,
                     MASTER_PASSWORD='repl用户登录密码',
                     MASTER_LOG_FILE='mysql_log_file_name',
                     MASTER_LOG_POS=4;

1、主将变更写入到二进制 2、从库读取主的二进制日志变更并写入到relay_log中 3、在从上重放relay_log中的日志 基于SQL段(statment)的日志是在从库上重新执行记录的SQL语句 基于行(row)日志则是在从库上直接应用对数据库行的修改
配置MySQL复制

主从复制实例演示

1、准备两台服务器主机,一台为MySQL的主,一台为MySQL的从
    MySQL主服务器的ip地址:192.168.1.2
    MySQL从服务器的ip地址:192.168.1.3

2、首先修改MySQL主服务的配置文件,加入如下信息
    ]# vim /etc/my.cnf

    log-bin=mysql-bin
    binlog_format=mixed
    server-id=1
    expire_logs_days=10

3、修改MySQL从服务器的配置文件,加入如下信息(如果需要从服务器作为其他的从服务器主,加入bin_log否则不需要)
    ]# vim /etc/my.cnf

    bin_log=mysql-bin
    server_id=2
    relay_log=mysql-relay-bin
    log_slave_update=on
    read_only=on

4、主库上创建主从同步账号,并进行权限分配
    ~]# mysql -uroot -p

    mysql> CREATE USER 'repl'@'192.168.1.3' IDENTIFIED BY 'repl';
            Query OK, 0 rows affected (0.00 sec)

            mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.3';
            Query OK, 0 rows affected (0.01 sec)

            mysql> FLUSH PRIVILEGES;
            Query OK, 0 rows affected (0.00 sec)

5、主库进行锁表备份数据,可以略过备份系统库--ignore-table=database.table_name
    ~]# mkdir mysql_backup
    ~]# cd mysql_backup/
    ~]# mysqldump  --master-data --single-transaction --triggers --routines --all-databases --lock-tables -uroot -p >> all.sql

6、把主服务器的MySQL备份的数据库文件拷贝到从服务器上
    ~]# scp all.sql root@192.168.1.3:/root/

7、从服务器的初始化操作
    ~]# mysql -uroot -p < all.sql 

8、执行change master命令连接主库
    首先需要找到二进制日志的文件名称,以及备份的位置点信息
    ~]# grep 'CHANGE MASTER TO MASTER_LOG_FILE' all.sql 
    下面是查找到的结果
    CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000042', MASTER_LOG_POS=1717;
    ~]# mysql -uroot -p
    mysql>  CHANGE MASTER TO MASTER_HOST='192.168.1.2',MASTER_USER='repl',MASTER_PASSWORD='repl',MASTER_LOG_FILE='mysql-bin.000042', MASTER_LOG_POS=1717;
    Query OK, 0 rows affected (0.01 sec)

9、启动主从复制,从库执行
    mysql> start slave;
    mysql> show slave statusG;
        *************************** 1. row ***************************
                   Slave_IO_State: Waiting for master to send event
                      Master_Host: 192.168.1.2
                      Master_User: repl
                      Master_Port: 3306
                    Connect_Retry: 60
                  Master_Log_File: mysql-bin.000042
              Read_Master_Log_Pos: 1717
                   Relay_Log_File: mariadb-relay-bin.000002
                    Relay_Log_Pos: 404
            Relay_Master_Log_File: mysql-bin.000042
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
                  Replicate_Do_DB: 
              Replicate_Ignore_DB: 
               Replicate_Do_Table: 
           Replicate_Ignore_Table: 
          Replicate_Wild_Do_Table: 
      Replicate_Wild_Ignore_Table: 
                       Last_Errno: 0
                       Last_Error: 
                     Skip_Counter: 0
              Exec_Master_Log_Pos: 1717
                  Relay_Log_Space: 700
                  Until_Condition: None
                   Until_Log_File: 
                    Until_Log_Pos: 0
               Master_SSL_Allowed: No
               Master_SSL_CA_File: 
               Master_SSL_CA_Path: 
                  Master_SSL_Cert: 
                Master_SSL_Cipher: 
                   Master_SSL_Key: 
            Seconds_Behind_Master: 0
    Master_SSL_Verify_Server_Cert: No
                    Last_IO_Errno: 0
                    Last_IO_Error: 
                   Last_SQL_Errno: 0
                   Last_SQL_Error: 
      Replicate_Ignore_Server_Ids: 
                 Master_Server_Id: 1
    1 row in set (0.00 sec)
    备注:
          执行这条命令的时候,发现报了一个错误ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO,这个错误出现的原因是因为server_id的不一致致使的,执行show variables like 'server_id;发现server_id的值是0,并没有生效,需要修改server_id即可set global server_id=2;

10、回到主服务的MySQL中对任意一个表进行插入数据测试,然后在回到从服务器上看相应的表中是否有数据,有即表示主从同步已经实现~~~

基于日志点的复制配置步骤

基于日志点的赋值配置步骤的优缺点
优点:
    1、是MySQL最早支持的复制技术,Bug相对较少
    2、对SQL查询没有任何限制
    3、故障处理比较容易
缺点:
    1、故障转义时重新获取新主的日志点信息比较的困难

1、主库上开启binlog的设置,只记录增删改 修改/etc/my.cnf配置文件,并添加修改如下数据 bin_log = mysql-bin (binlog日志的名称,意思就是binlog的名称以mysql-bin开头) server_id = 100 (动态参数,可以通过在MySQL的命令行中进行修改set global server_id=100) 2、在主DB服务器上建立复制账号 CREATE USER 'repl'@'IP段' IDENTIFIED BY 'repl用户的登录密码'; GRANT REPLICATION SLAVE ON . TO 'repl'@'ip段'; 3、配置从数据库服务器 修改/etc/my.cnf bin_log = mysql-bin server_id = 101 relay_log = mysql-relay-bin (中继日志的名称,默认是主机名,建议自己定义个名称,避免更改主机名以后带来不便) log_slave_update = on [可选] (是否把从服务器的重放二进制日志记录到本机的二进制日志中,以作为其他从服务器的主) read_only = on [可选] (是否允许没有没有sql线程的用户进行写操作) 4、在主库进行锁表,并拿到binlog的日志点,进行主库的备份并把备份拷贝到从库上,备份两种方式如下 mysqldump --master-data --single-transaction --triggers --routines --all-databases -uroot -p --lock-tables >> all.sql xtrabackup --slvae-info 5、启动复制链路 CHANGE MASTER TO MASERT_HOST='mast_host_ip', MASTER_USER=‘repl’, MASTER_PASSWORD='repl用户登录密码', MASTER_LOG_FILE='mysql_log_file_name', MASTER_LOG_POS=4;
主从复制实例演示

基于GTID复制的优缺点

GTID的复制是从MySQL5.6开始支持的功能
图片 7

什么是GTID?

    GTID即全局事务ID,起保证为每一个在主上提交的事务在复制的急群中可以生成一个唯一的ID

    GTID=source_id:transaction_id

GTID复制的相关参数

    主库的/etc/my.cnf的配置文件参数
        bin_log = /usr/local/mysql/log/mysql-bin
        server_id = 100
        gtid_mode = on 
        enforce_gtid_consistency
        log_slave_updates = on

    从库/etc/my.cnf的配置文件参数
        server_id = 101
        relay_log = /usr/local/mysql/log/relay_log
        gtid_mode = on
        enforce_gtid_consistency

        建议从库中开启的参数
        log-slave-updates = on
        read_only = on
        master_info_repository = TABLE
        relay_log_info_repository =TABLE

启动基于GTID的复制
    CHANGE MASTER TO MASERT_HOST='mast_host_ip',
                     MASTER_USER=‘repl’,
                     MASTER_PASSWORD='repl用户登录密码',
                     MASTER_AUTO_POSITION=1;

1、准备两台服务器主机,一台为MySQL的主,一台为MySQL的从 MySQL主服务器的ip地址:192.168.1.2 MySQL从服务器的ip地址:192.168.1.3 2、首先修改MySQL主服务的配置文件,加入如下信息 ]# vim /etc/my.cnf log-bin=mysql-bin binlog_format=mixed server-id=1 expire_logs_days=10 3、修改MySQL从服务器的配置文件,加入如下信息(如果需要从服务器作为其他的从服务器主,加入bin_log否则不需要) ]# vim /etc/my.cnf bin_log=mysql-bin server_id=2 relay_log=mysql-relay-bin log_slave_update=on read_only=on 4、主库上创建主从同步账号,并进行权限分配 ~]# mysql -uroot -p mysql> CREATE USER 'repl'@'192.168.1.3' IDENTIFIED BY 'repl'; Query OK, 0 rows affected (0.00 sec) mysql> GRANT REPLICATION SLAVE ON . TO 'repl'@'192.168.1.3'; Query OK, 0 rows affected (0.01 sec) mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.00 sec) 5、主库进行锁表备份数据,可以略过备份系统库--ignore-table=database.table_name ~]# mkdir mysql_backup ~]# cd mysql_backup/ ~]# mysqldump --master-data --single-transaction --triggers --routines --all-databases --lock-tables -uroot -p >> all.sql 6、把主服务器的MySQL备份的数据库文件拷贝到从服务器上 ~]# scp all.sql root@192.168.1.3:/root/ 7、从服务器的初始化操作 ~]# mysql -uroot -p < all.sql 8、执行change master命令连接主库 首先需要找到二进制日志的文件名称,以及备份的位置点信息 ~]# grep 'CHANGE MASTER TO MASTER_LOG_FILE' all.sql 下面是查找到的结果 CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000042', MASTER_LOG_POS=1717; ~]# mysql -uroot -p mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.2',MASTER_USER='repl',MASTER_PASSWORD='repl',MASTER_LOG_FILE='mysql-bin.000042', MASTER_LOG_POS=1717; Query OK, 0 rows affected (0.01 sec) 9、启动主从复制,从库执行 mysql> start slave; mysql> show slave statusG; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.2 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000042 Read_Master_Log_Pos: 1717 Relay_Log_File: mariadb-relay-bin.000002 Relay_Log_Pos: 404 Relay_Master_Log_File: mysql-bin.000042 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 1717 Relay_Log_Space: 700 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1 1 row in set (0.00 sec) 备注: 执行这条命令的时候,发现报了一个错误ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO,这个错误出现的原因是因为server_id的不一致致使的,执行show variables like 'server_id;发现server_id的值是0,并没有生效,需要修改server_id即可set global server_id=2; 10、回到主服务的MySQL中对任意一个表进行插入数据测试,然后在回到从服务器上看相应的表中是否有数据,有即表示主从同步已经实现~~~
基于日志点的赋值配置步骤的优缺点

主从复制基于GTID

1、准备两台服务器主机,一台为MySQL的主,一台为MySQL的从
    MySQL主服务器的ip地址:192.168.1.5
    MySQL从服务器的ip地址:192.168.1.2

2、首先修改MySQL主服务的配置文件,加入如下信息
    ]# vim /etc/my.cnf

    server-id  = 1
    gtid_mod = on
    binlog_format = mixed
    expire_logs_days = 10
    log_slave_updates=on
    enforce_gtid_consistency = on
    log-bin = /usr/local/mysql/log/mysql-bin

3、修改MySQL从服务器的配置文件,加入如下信息(如果需要从服务器作为其他的从服务器主,加入bin_log否则不需要)
    ]# vim /etc/my.cnf

    binlog_format=mixed
    server-id = 2
    gtid_mode = on
    expire_logs_days = 10
    log_slave_updates = on
    enforce_gtid_consistency = on
    master-info-repository = TABLE
    relay-log-info-repository = TABLE
    log_bin = /usr/local/mysql/log/mysql-bin
    relay_log = /usr/local/mysql/log/relay-log

4、主库上创建主从同步账号,并进行权限分配
    ~]# mysql -uroot -p

    mysql> CREATE USER 'repl'@'192.168.1.2' IDENTIFIED BY 'repl';
            Query OK, 0 rows affected (0.00 sec)

    mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.2';
            Query OK, 0 rows affected (0.01 sec)

    mysql> FLUSH PRIVILEGES;
            Query OK, 0 rows affected (0.00 sec)

5、主库进行锁表备份数据,可以略过备份系统库
    ~]# mkdir mysql_backup
    ~]# cd mysql_backup/
    ~]# mysqldump  --master-data=2 --single-transaction --triggers --routines --all-databases --set-gtid-purged=OFF --lock-tables -uroot -p >> all2.sql

6、把主服务器的MySQL备份的数据库文件拷贝到从服务器上
    ~]# scp all2.sql root@192.168.1.2:/root/

7、从服务器的初始化操作
    ~]# mysql -uroot -p < all2.sql  

8、从库执行change maset to语句,进行GTID主从复制
    ~]# mysql -uroot -p
    mysql>  CHANGE MASTER TO MASTER_HOST='192.168.1.5',MASTER_USER='repl',MASTER_PASSWORD='repl',MASTER_AUTO_POSITION=1;

9、启动主从复制,从库执行
    mysql> start slave;

10、回到主服务的MySQL中对任意一个表进行插入数据测试,然后在回到从服务器上看相应的表中是否有数据,有即表示主从同步已经实现~~~

优点: 1、是MySQL最早支持的复制技术,Bug相对较少 2、对SQL查询没有任何限制 3、故障处理比较容易 缺点: 1、故障转义时重新获取新主的日志点信息比较的困难
基于GTID复制的优缺点

MySQL复制拓扑

GTID的复制是从MySQL5.6开始支持的功能

在MySQL7.7之前,一个主库只能有一个从库,MySQL5.7以后支持一主多从架构

图片 8

什么是GTID? GTID即全局事务ID,起保证为每一个在主上提交的事务在复制的急群中可以生成一个唯一的ID GTID=source_id:transaction_id GTID复制的相关参数 主库的/etc/my.cnf的配置文件参数 bin_log = /usr/local/mysql/log/mysql-bin server_id = 100 gtid_mode = on enforce_gtid_consistency log_slave_updates = on 从库/etc/my.cnf的配置文件参数 server_id = 101 relay_log = /usr/local/mysql/log/relay_log gtid_mode = on enforce_gtid_consistency 建议从库中开启的参数 log-slave-updates = on read_only = on master_info_repository = TABLE relay_log_info_repository =TABLE 启动基于GTID的复制 CHANGE MASTER TO MASERT_HOST='mast_host_ip', MASTER_USER=‘repl’, MASTER_PASSWORD='repl用户登录密码', MASTER_AUTO_POSITION=1;
主从复制基于GTID

一主多从的复制拓扑

图片 9

用途
    1、为不同业务使用不同的从库,根据不同的业务特点,使用不同的存储引擎,分割前后台查询,把不同的查询分配到从库上,以此来创建索引提升性能
    2、将一台从库放到远程IDC中,用作灾备恢复
    3、多个从库来分担主库的负载,可以分担读负载(主库负责写,查询交给多个从库)

1、准备两台服务器主机,一台为MySQL的主,一台为MySQL的从 MySQL主服务器的ip地址:192.168.1.5 MySQL从服务器的ip地址:192.168.1.2 2、首先修改MySQL主服务的配置文件,加入如下信息 ]# vim /etc/my.cnf server-id = 1 gtid_mod = on binlog_format = mixed expire_logs_days = 10 log_slave_updates=on enforce_gtid_consistency = on log-bin = /usr/local/mysql/log/mysql-bin 3、修改MySQL从服务器的配置文件,加入如下信息(如果需要从服务器作为其他的从服务器主,加入bin_log否则不需要) ]# vim /etc/my.cnf binlog_format=mixed server-id = 2 gtid_mode = on expire_logs_days = 10 log_slave_updates = on enforce_gtid_consistency = on master-info-repository = TABLE relay-log-info-repository = TABLE log_bin = /usr/local/mysql/log/mysql-bin relay_log = /usr/local/mysql/log/relay-log 4、主库上创建主从同步账号,并进行权限分配 ~]# mysql -uroot -p mysql> CREATE USER 'repl'@'192.168.1.2' IDENTIFIED BY 'repl'; Query OK, 0 rows affected (0.00 sec) mysql> GRANT REPLICATION SLAVE ON . TO 'repl'@'192.168.1.2'; Query OK, 0 rows affected (0.01 sec) mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.00 sec) 5、主库进行锁表备份数据,可以略过备份系统库 ~]# mkdir mysql_backup ~]# cd mysql_backup/ ~]# mysqldump --master-data=2 --single-transaction --triggers --routines --all-databases --set-gtid-purged=OFF --lock-tables -uroot -p >> all2.sql 6、把主服务器的MySQL备份的数据库文件拷贝到从服务器上 ~]# scp all2.sql root@192.168.1.2:/root/ 7、从服务器的初始化操作 ~]# mysql -uroot -p < all2.sql 8、从库执行change maset to语句,进行GTID主从复制 ~]# mysql -uroot -p mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.5',MASTER_USER='repl',MASTER_PASSWORD='repl',MASTER_AUTO_POSITION=1; 9、启动主从复制,从库执行 mysql> start slave; 10、回到主服务的MySQL中对任意一个表进行插入数据测试,然后在回到从服务器上看相应的表中是否有数据,有即表示主从同步已经实现~~~
MySQL复制拓扑

主-主复制拓扑

图片 10

主主模式下的主-主复制的配置注意事项
    1、两个主中所操作的表最好能够分开
    2、使用下面两个参数控制自增ID的生成
        auto_increment_increment = 2   (一台为1,3,5,7,9,另外一台的2,4,6,8,10)
        auto_increment_offset = 1 | 2 (每次自增的值)

主备模式下的主-主复制的配置注意事项
    1、只有一台主服务器对外提供服务
    2、一台服务器处于只读状态并且作为热备使用
    3、在对外提供服务的主库出现故障或是计划性的维护时才会进行切换
    4、使原来的备库成为主库,而原来的主库则会成为新的备库,并处理只读或是下线状态,待维护完毕后重新上线
    5、确保两台服务器上的初始数据相同
    6、确保两台服务器上的已经启动binlog并且有不同的sever_id
    7、在两台的服务器上启用log_slave_updates参数
    8、在初始的备库上启用read_only

在MySQL7.7之前,一个主库只能有一个从库,MySQL5.7以后支持一主多从架构

拥有备库的主-主复制拓扑

图片 11

拥有备库的主-主复制注意事项
    1、从库的数量可多可少,建议不要太多,不然会对主库造成I/O的压力
    2、每个从库都应该设置成只读状态,分担主库的读请求
    3、一个主库出现问题,将会损失这个主库下的所有从库的读冗余
    4、一个主机离线时候,要去除改主机的从库

一主多从的复制拓扑

级联复制

图片 12

实现的方式
    1、分发主库也是个从库
    2、分发主库记录主库传递过来的二进制日志并分发给下面的从库
    3、减轻主库复制所消耗的负载

用途 1、为不同业务使用不同的从库,根据不同的业务特点,使用不同的存储引擎,分割前后台查询,把不同的查询分配到从库上,以此来创建索引提升性能 2、将一台从库放到远程IDC中,用作灾备恢复 3、多个从库来分担主库的负载,可以分担读负载(主库负责写,查询交给多个从库)
主-主复制拓扑

未完待续,MySQL复制优化、常见问题、高可用架构,请等下篇博文

原创作品,转载请注明出处:

主主模式下的主-主复制的配置注意事项 1、两个主中所操作的表最好能够分开 2、使用下面两个参数控制自增ID的生成 auto_increment_increment = 2 (一台为1,3,5,7,9,另外一台的2,4,6,8,10) auto_increment_offset = 1 | 2 (每次自增的值) 主备模式下的主-主复制的配置注意事项 1、只有一台主服务器对外提供服务 2、一台服务器处于只读状态并且作为热备使用 3、在对外提供服务的主库出现故障或是计划性的维护时才会进行切换 4、使原来的备库成为主库,而原来的主库则会成为新的备库,并处理只读或是下线状态,待维护完毕后重新上线 5、确保两台服务器上的初始数据相同 6、确保两台服务器上的已经启动binlog并且有不同的sever_id 7、在两台的服务器上启用log_slave_updates参数 8、在初始的备库上启用read_only
拥有备库的主-主复制拓扑

拥有备库的主-主复制注意事项 1、从库的数量可多可少,建议不要太多,不然会对主库造成I/O的压力 2、每个从库都应该设置成只读状态,分担主库的读请求 3、一个主库出现问题,将会损失这个主库下的所有从库的读冗余 4、一个主机离线时候,要去除改主机的从库
级联复制

实现的方式 1、分发主库也是个从库 2、分发主库记录主库传递过来的二进制日志并分发给下面的从库 3、减轻主库复制所消耗的负载
未完待续,MySQL复制优化、常见问题、高可用架构,请等下篇博文
转至http://www.cnblogs.com/demon89/p/8503814.html

编辑:数据库 本文来源:binlog=1表示每写缓冲一次就同步到磁盘,转载请注

关键词: