MySQL双主（主主）架构方案

MySQL双主（主主）架构方案思路是:
1.两台mysql都可读写，互为主备，默认只使用一台（masterA）负责数据的写入，另一台（masterB）备用；
2.masterA是masterB的主库，masterB又是masterA的主库，它们互为主从；
3.两台主库之间做高可用,可以采用keepalived等方案（使用VIP对外提供服务）；
4.所有提供服务的从服务器与masterB进行主从同步（双主多从）;
5.建议采用高可用策略的时候，masterA或masterB均不因宕机恢复后而抢占VIP（非抢占模式）；
这样做可以在一定程度上保证主库的高可用,在一台主库down掉之后,可以在极短的时间内切换到另一台主库上（尽可能减少主库宕机对业务造成的影响），减少了主从同步给线上主库带来的压力；
1.masterB可能会一直处于空闲状态（可以用它当从库，负责部分查询）；
2.主库后面提供服务的从库要等masterB先同步完了数据后才能去masterB上去同步数据，这样可能会造成一定程度的同步延时；

1. 安装数据库
A库IP10.1.5.58，B库IP10.1.5.59，VIP：10.1.5.57
A库
补充到/etc/my.cnf
server-id=58 #里的ID号与从库上或者主库上的ID必须保证不一样
log-bin=mysql-bin #可以自定义 这里定义为 log-bin=/data/log-bin/log-bin-3310
binlog_format=row #主从复制模式
log-slave-updates=true #slave 更新是否记入日志
gtid-mode=on #启用gtid类型，否则就是普通的复制架构
enforce-gtid-consistency=true #强制GTID 的一致性
master-info-repository=TABLE #主服信息记录库=表 /文件
relay-log-info-repository=TABLE #中继日志信息记录库
sync-master-info=1 #同步主库信息
slave-parallel-workers=4 #从服务器的SQL 线程数，要复制库数目相同
binlog-checksum=CRC32 # 校验码 ，可以自定义
master-verify-checksum=1 #主服校验
slave-sql-verify-checksum=1 #从服校验
binlog-rows-query-log_events=1 #二进制日志详细记录事件
report-port=3306 #提供复制报告端口，当前实例端口号
report-host=10.1.5.58 #提供复制报告主机，本机的ip地址
B库
补充到/etc/my.cnf
server-id=59 #里的ID号与从库上或者主库上的ID必须保证不一样
log-bin=mysql-bin #可以自定义 这里定义为 log-bin=/data/log-bin/log-bin-3310
binlog_format=row #主从复制模式
log-slave-updates=true #slave 更新是否记入日志
gtid-mode=on #启用gtid类型，否则就是普通的复制架构
enforce-gtid-consistency=true #强制GTID 的一致性
master-info-repository=TABLE #主服信息记录库=表 /文件
relay-log-info-repository=TABLE #中继日志信息记录库
sync-master-info=1 #同步主库信息
slave-parallel-workers=4 #从服务器的SQL 线程数，要复制库数目相同
binlog-checksum=CRC32 # 校验码 ，可以自定义
master-verify-checksum=1 #主服校验
slave-sql-verify-checksum=1 #从服校验
binlog-rows-query-log_events=1 #二进制日志详细记录事件
report-port=3306 #提供复制报告端口，当前实例端口号
report-host=10.1.5.59 #提供复制报告主机，本机的ip地址

A服务器mysql实例3306：
grant replication slave,replication client on . to slave@'10.1.8.59’identified by ‘xxxxxxA’;
B服务器mysql实例3306：
grant replication slave,replication client on . to slave@'10.1.8.58’identified by ‘xxxxxxB’;
A服务赋权实例3306：
change master to master_host=‘10.1.5.59’,master_port=3306,master_user=‘slave’,master_password='xxxxxxA’,master_auto_position=1;
B服务赋权实例3306：
change master to master_host=‘10.1.5.58’,master_port=3306,master_user=‘slave’,master_password='xxxxxxB’,master_auto_position=1;

A、B服务器上开启主从复制：start slave；
show slave status\G 查看同步状态。
show processlist;查看mysql内线程

验证：数据库A创建数据库test，数据库B同时创建数据库test。
数据库B创建数据库test2，数据库A同时创建数据库test2。

开启高可用
安装keepalived
yum install keepalived
A配置(master)
vi /etc/keepalived/

global_defs
{
router_id mysql_01
}

vrrp_script chk_mysql
{
script “/etc/keepalived/check_mysql.sh”
interval 2
weight -20
}

vrrp_instance VI_1
{
state MASTER
interface ens160
virtual_router_id 87
mcast_src_ip 10.1.5.58
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress
{
10.1.5.57/25
}

track_script
{
chk_mysql
}
}

B服务器相同操作

global_defs
{
router_id mysql_02
}

vrrp_script chk_mysql
{
script “/etc/keepalived/check_mysql.sh”
interval 2
weight -20
}

vrrp_instance VI_1
{
state BACKUP
interface ens160
virtual_router_id 87
mcast_src_ip 10.1.5.59
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress
{
10.1.5.57/25
}

track_script
{
chk_mysql
}
}

在/etc/keepalived下创建监听脚本mysql_check.sh

#!/bin/bash
counter=$(netstat-na|grep"LISTEN"|grep"3306"|wc-l)if["${counter}" -eq 0 ]; then
service keepalived stop
fi

chmod 755 mysql_check.sh （赋权监听脚本）

service keepalived start （启动keepalived 服务验证）

验证：当mysql服务停止后，VIP漂移到B服务器上。对数据库进行操作无影响。

show slave status\G参数解释
我们需要特别注意的参数如下：
Master_Log_File：SLAVE中的I/O线程当前正在读取的主服务器二进制日志文件的名称
Read_Master_Log_Pos：在当前的主服务器二进制日志中，SLAVE中的I/O线程已经读取的位置
Relay_Log_File：SQL线程当前正在读取和执行的中继日志文件的名称
Relay_Log_Pos：在当前的中继日志中，SQL线程已读取和执行的位置
Relay_Master_Log_File： 由SQL线程执行的包含多数近期事件的主服务器二进制日志文件的名称
Slave_IO_Running：I/O线程是否被启动并成功地连接到主服务器上
Slave_SQL_Running： SQL线程是否被启动
Seconds_Behind_Master：从属服务器SQL线程和从属服务器I/O线程之间的时间差距，单位以秒计。

主从同步延迟的情况：
1、show slave status显示参数Seconds_Behind_Master不为0，这个数值可能会很大
2、show slave status显示参数Relay_Master_Log_File和Master_Log_File显示bin-log的编号相差很大，说明bin-log在从库上没有及时同步，所以近期执行的bin-log和当前IO线程所读的bin-log相差很大
3、mysql的从库数据目录下存在大量mysql-relay-log日志，该日志同步完成之后就会被系统自动删除，存在大量日志，说明主从同步延迟很厉害
a、MySQL数据库主从同步延迟原理
mysql主从同步原理：
主库针对写操作，顺序写binlog，从库单线程去主库顺序读”写操作的binlog”，从库取到binlog在本地原样执行（随机写），来保证主从数据逻辑上一致。
mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生binlog，binlog是顺序写，所以效率很高，slave的Slave_IO_Running线程到主库取日志，效率比较高，下一步，问题来了，slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的，不是顺序的，成本高很多，还可能可slave上的其他查询产生lock争用，由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。
有朋友会问：“主库上那个相同的DDL也需要执行10分，为什么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。
MySQL数据库主从同步延迟是怎么产生的？
当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。
首要原因：数据库在业务上读写压力太大，CPU计算负荷大，网卡负荷大，硬盘随机IO太高
次要原因：读写binlog带来的性能影响，网络传输延迟。

MySQL数据库主从同步延迟解决方案
架构方面
1.业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。
2.单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。
3.服务的基础架构在业务和mysql之间加入memcache或者redis的cache层。降低mysql的读压力。
4.不同业务的mysql物理上放在不同机器，分散压力。
5.使用比主库更好的硬件设备作为slave
总结，mysql压力小，延迟自然会变小。
硬件方面
1.采用好服务器，比如4u比2u性能明显好，2u比1u性能明显好。
2.存储用ssd或者盘阵或者san，提升随机写的性能。
3.主从间保证处在同一个交换机下面，并且是万兆环境。
总结，硬件强劲，延迟自然会变小。一句话，缩小延迟的解决方案就是花钱和花时间。
mysql主从同步加速
1、sync_binlog在slave端设置为0
2、–logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志。
3、直接禁用slave端的binlog
4、slave端，如果使用的存储引擎是innodb，innodb_flush_log_at_trx_commit =2
从文件系统本身属性角度优化
master端
修改linux、Unix文件系统中文件的etime属性， 由于每当读文件时OS都会将读取操作发生的时间回写到磁盘上，对于读操作频繁的数据库文件来说这是没必要的，只会增加磁盘系统的负担影响I/O性能。可以通过设置文件系统的mount属性，组织操作系统写atime信息，在linux上的操作为：
打开/etc/fstab，加上noatime参数
/dev/sdb1 /data reiserfs noatime 1 2
然后重新mount文件系统
#mount -oremount /data
PS：
主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置是需要的
而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率
1、sync_binlog=1
MySQL提供一个sync_binlog参数来控制数据库的binlog刷到磁盘上去。
默认，sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。
如果sync_binlog>0，表示每sync_binlog次事务提交，MySQL调用文件系统的刷新操作将缓存刷下去。最安全的就是sync_binlog=1了，表示每次事务提交，MySQL都会把binlog刷下去，是最安全但是性能损耗最大的设置。这样的话，在数据库所在的主机操作系统损坏或者突然掉电的情况下，系统才有可能丢失1个事务的数据。
但是binlog虽然是顺序IO，但是设置sync_binlog=1，多个事务同时提交，同样很大的影响MySQL和IO性能。
虽然可以通过group commit的补丁缓解，但是刷新的频率过高对IO的影响也非常大。对于高并发事务的系统来说，
“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。
所以很多MySQL DBA设置的sync_binlog并不是最安全的1，而是2或者是0。这样牺牲一定的一致性，可以获得更高的并发和性能。
默认情况下，并不是每次写入时都将binlog与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能binlog中最后的语句丢失了。要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog写入后与硬盘同步。即使sync_binlog设置为1,出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。
2、innodb_flush_log_at_trx_commit （这个很管用）
抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。