一.高可用架构方案

1.负载均衡

有一定高可用性
LVS 
Nginx

2.主备系统

有高可用性,但是需要切换
Keepalived
MHA
MMM

3.真正高可用

Oracle RAC
innoDB cluster (MGR)
NDB Cluster
Sysbase cluster 

二. 主从复制

1.主从复制简介

a.基于二进制日志复制的
b.主库的修改操作会记录二进制日志
c.从库会请求新的二进制日志并回放,最终达到主从数据同步
d.主从复制优势:处理物理损坏
  逻辑损坏:drop,delete,truncate(数据库内部误操作)
  物理损坏:磁盘,数据,系统(数据库外部损坏)

2.主从复制核心作用

a.辅助备份,处理物理损坏
b.扩展新型的架构:高可用,高性能,分布式架构等

3.主从复制前提

a.两台以上mysql实例 ,server_id,server_uuid不同
b.主库开启二进制日志
c.专用的复制用户
d.保证主从开启之前的某个时间点,从库数据是和主库一致(补课)
e.告知从库,复制user,passwd,IP port,以及复制起点(change master to)
f.线程(三个):Dump thread  IO thread  SQL thread 开启(start slave)

三. 搭建主从

1.主授权

grant replication slave on *.* to repl@'10.0.0.%' identified by '123';

2.将主库全备

mysqldump  -S /data/3307/mysql.sock -A -R --triggers -E --master-data=2 --single-transaction >/tmp/full.sql
(有账户和密码记得 -uroot -p)
(-R 存储过程)
(--triggers 触发器)
(-E 触发事件)
(--single-transaction 基于快照备份)

3.进从库进行导入

a.临时关闭日志
set sql_log_bin=0
b.进行备份数据
source /tmp/full.sql
c.开启从库设置参数
CHANGE MASTER TO
  MASTER_HOST='10.0.0.205',
  MASTER_USER='repl',
  MASTER_PASSWORD='123456',
  MASTER_PORT=3307,
  MASTER_LOG_FILE='mysql-bin.000004',
  MASTER_LOG_POS=1394,
  MASTER_CONNECT_RETRY=10;
d.开启从库
start slave

四.主从复制牵扯的东东

1.主从复制过程中涉及到的文件

a.主库:
  二进制日志(binlog)
b.从库:
  中继日志(relaylog)
  master.info(主库信息)
  relay-loh.info(中继日志信息)

2.主从复制过程中涉及到的线程

a.主库:
  Binlog_Dump_Thread(DT)
b.从库:
  Slave_IO_Thread     (IT)
  Slave_SQL_Thread  (ST)

3.主从故障

1.IO线程故障

a.连接主库
  IP
  Port
  用户信息
  防火墙 
  网络
  连接数上限
b.请求和接受二进制日志
  日志不全

2.主从延时

a.主库做了修改操作,从库比较长时间才能追上
b.外在因素
  网络
  主从硬件差异较大
  版本差异
  参数因素

1.主库问题

  1.二进制日志写入不及时
  2.CR的主从复制中,binlog_dump线程,事件为单元,串行传送二进制日志(5.5/5.6版本)
  3.主从并发量事务大,主库亦可以并行,传送时串行
  4.主库由于串行传送,会产生阻塞后续事务
d.解决方案
  5.6开始，开启GTID实现GC（group commit）机制，可以并行传输日志给从库IO
  5.7开始，不开启GTID，胡自动维护匿名的GTID，也能实现GC，我们建议还是人为开启GTID
  大事务拆成多个小事务，可以有效的减少主从延时

2.从库问题

a.SQL线程导致的主从延时
  在CR复制情况下: 从库默认情况下只有一个SQL,只能串行回放事务SQL
  1.主库如果并发事务量较大,从库只能串行回放
  2.主库发生了大事务,会阻塞后续所有事务运行
b.解决方案
  1. 5.6版本开启GTID后,加入SQL多线程特性,但是只能针对不同库下的事务进行并发回放
  2. 5.7版本开启GTID后,在SQL方面基于逻辑时钟(logical_clock),主库同一时段,binlog记录时加入seq_no机制,从而时间事务级别并发回放 
  (多线程从库 MTS)

3.SQL线程功能：

(1)读写relay-log.info 
(2)relay-log损坏,断节,找不到
(3)接收到的SQL无法执行

4.导致SQL线程故障原因分析：

1. 版本差异，参数设定不同，比如：数据类型的差异，SQL_MODE影响
2.要创建的数据库对象,已经存在
3.要删除或修改的对象不存在  
4.DML语句不符合表定义及约束时.  
归根揭底的原因都是由于从库发生了写入操作.
Last_SQL_Error: Error 'Can't create database 'db'; database exists' on query. Default database: 'db'. Query: 'create database db'

5.处理方法(以从库为核心的处理方案)：

方法一：
stop slave; 
set global sql_slave_skip_counter = 1;
将同步指针向下移动一个，如果多次不同步，可以重复操作。
start slave;
方法二：
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突