mysql高可用架构设计(主从复制，复制拓扑）

web服务器：对于web服务器可通过增加web服务器来分担负载

MySQL：MySQL复制功能提供分担负载（读负载），通过水平增加数据库，复制基于主库的二进制

日志，可能会存在延迟

复制解决了什么问题：

1、实现在不同服务器上的数据分布：利用二进制日志增量进行，不需要

太多的带宽，但是使用基于行的复制在进行大批量的更改时会对带宽带来

一定的压力（特别是在跨IDC环境下进行复制），复制应该分批进行

2、实现数据读取的负载均衡：需要其他组件配合完成，利用DNS轮询的方式把程序的读

连接到不同的备份数据库，使用LVS，haproxy这样的代理方式，非共享架构，同样的数据

分布在多台服务器上

3、增加了数据安全性：利用备库的备份来减少主库负载，复制并不能代替备份

4、实现数据库高可用和故障切换

5、实现数据库在线升级

 

二进制日志：记录了所有对MySQL的修改事件，包括增删改查事件和对表结构的修改事件

二进制日志的格式：

1、基于段的格式 binlog_format = STATEMENT

优点：日志记录量少，节约磁盘和网络I/O（只对一条记录修改或插入，row格式小于段产生的日志量）

缺点：必须记录上下文信息，保证语句在从服务器和主服务器上数据相同；可能造成主备服务器数据不一致；

查看show variables like 'binlog_format';       mixed

设置：set session binlog_format = statement;

2、基于行的日志格式：binlog_format = ROW

row格式可以避免主从不一致问题，同一sql语句修改10000条数据的情况下，基于段的日志只

记录这条sql语句，基于行会有10000条记录分别记录每一行的数据修改

优点：主从复制更加安全，对于每一行数据的修改比基于段的复制高效

误操作修改了数据库中的数据，同时又没有备份可以恢复，我们就可以通过

分析二进制日志，对日志中记录的数据修改操作做反向处理的方式来达到恢复数据的目的

缺点：记录日志量较大 binlog_row_image= [FULL|MININAL|NOBLOB] (三种存储日志模式,高版本才有）

full：默认值，记录所有的行信息，和5.6之前记录的没有区别

minimal:只记录要修改列的记录

noblob:记录除了blog和text之外的所有字段

show variables like 'binlog_row_image';

 

 

 

 

查看二进制日志：

1、先手动生成日志，在MySQL命令行

show binary logs;

flush logs;（刷新日志）

show binary logs;

create database crn;

use crn;

create table t(id int,c1 varchar(10));

insert into t values(1,'aa'),(2,'bb');

 update t set c1 = 'dd' where id = 1;

2、查看日志

cd  /usr/local/mysql/var

mysqlbinlog mysql-bin.000015;

 

基于日志点的复制：

第一步备份主库数据

授权连接主库用户：grant replication slave on *.* to 'tang'@'%' identified by '123';（授予复制权限）

mysqldump --single-transaction --master-data --triggers --routines --all-databases -uroot -proot >> all.sql（备份所有库）

mysqldump --single-transaction --master-data --triggers --routines crn -uroot -proot>> all.sql（备份crn库）

scp all.sql root@106.14.14.321:/root

从服务器导入all.sql

mysql -uroot -proot <all.sql

change master to master_host='106.14.14.231',master_user='tang',master_password='123', master_log_file='mysql-bin.000003',master_log_pos=1839;

启动从服务器：start slave

停止从服务器：slave stop;重置slavereset slave;

show slave status \G

 

 

 

基于GTID复制：

1、授权用户

2、bin_log = /usr/local/mysql/log/mysql-bin

server_id =100

gtid_mode =on (记录事务GTID值，必须设置）

enforce-gtid-consiste(启动后不能使用create table ... select  ,不能在事务中国使用Create temporary table 建立临时表，

不能使用关联事务表和非事务表）

log-slave-updates = on （<5.6时必须开启，从服务器中记录主服务器传来的修改日志，开启会加大负载）

read_only = on (建议）

master_info_repository = TABLE(建议）

relay_log_info_repository = TABLE(建议）

初始化从服务器数据

mysqldump --master-data=2 -single-transaction

xtarbackup --slave-info

记录备份时最后的事务的GTID

 

启动基于GTID的复制

change master to master_host = 'ip',master_user='repl',master_password='pwd',master_auto_position=1

 

基于GTID复制的优缺点：

优点：可以很方便的进行故障转移，从库不会丢失主库上的任何修改

缺点：故障处理比较复杂，对执行的sql有一定的限制

 

选择复制模式的问题：1、GTID复制需>5.6（或5.6后期版本）

2、复制架构及主从切换的方式（GTID可以很方便切换）

3、所使用的高可用管理组件

4 、对应用的支持程度 

 

MySQL复制拓扑：

1、一主多从的复制拓扑：

优点-①配置简单②可以用多个从库分担读负载

用途--①为不同业务使用不同的从库②将一台从库放到远程IDC，用作灾备恢复3分担主库的读负载

2、主-主复制拓扑

①主备模式的主主复制模式（两个主，只有一个对外提供服务，当一个主服务器坏掉时另一台才会对外服务）
比主主复制的主主复制模式常用，

注意事项：确保两台服务器上的初始数据相同，确保两台服务器上已经启动binlog并且

有不同的server_id,在两台服务器上启用log_slave_updates参数，在初始的备库上启用read_only

 

②主主复制的主主复制模式 

不经常使用，冗余造成数据冲突，耗费大量时间，造成数据丢失。（使用场景在两个地区部署两个服务器，

需要这两个服务器都同步另一个服务器中的内容，常设为主主复制）

注意事项：两个主中操作的表最好能够分开（上海只操作上海机房的库，北京只操作北京机房的库）

使用下面两个参数控制自增id的生成

auto_increment_increment = 2

auto_increment_offset = 1|2

 

 

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

4、级联复制