MySQL基于多实例构建主从复制及常见故障排查
文章目录
-
-
- 主从复制介绍
- 搭建主从复制的前提
- 主从复制工作过程
- 主从复制的作用
- 主从复制搭建
-
- 构建MySQL多实例
- 主从复制故障
- 主从延时监控主要原因
- 主从复制对事物的影响
- 分库分表面临的问题
-
主从复制介绍
- 主从复制基于binlog来实现的
- 主库发生新的操作,都会记录到binlog
- 从库取得主库的binlog进行“回放”
- 主从复制的过程是异步的
搭建主从复制的前提
- 2个或以上的数据库实例
- 主库需要开启二进制日志
- server_id要不同,区分不同的节点
- 主库需要建立专用的复制用户 (replication slave)
- 从库应该通过备份主库,恢复的方法进行"补课"
- 人为告诉从库一些复制信息(CHANGE MASTER TO)
- 从库应该开启专门的复制线程
主从复制工作过程
- 从库执行change master to 命令(主库的连接信息+复制的起点)
- 从库会将以上信息,记录到master.info文件
- 从库执行 start slave 命令,立即开启IO线程和SQL线程
- 从库 IO线程,读取master.info文件中的信息
- 从库IO线程请求连接主库,主库专门提供一个DUMP线程,负责和IO线程交互
- IO线程根据binlog的位置信息(mysql-bin.000004 , 444),请求主库新的binlog
- 主库通过DUMP线程将最新的binlog,通过网络TP给从库的IO线程
- IO线程接收到新的binlog日志,存储到TCP/IP缓存,立即返回ACK给主库,并更新master.info
- IO线程将TCP/IP缓存中数据,转储到磁盘relaylog中.
- SQL线程读取relay.info中的信息,获取到上次已经应用过的relaylog的位置信息
- SQL线程会按照上次的位置点回放最新的relaylog,再次更新relay.info信息
- 从库会自动purge应用过的relay进行定期清理
一旦主从复制构建成功,主库当中发生了新的变化,都会通过dump线程发送信号给IO线程,增强了主从复制的实时性.
主从复制的作用
- 备份。主库down了自动切换到从库
- 在数据库层面上实现读写分离
主从复制搭建
构建MySQL多实例
-
准备多个数据目录
[root@localhost ~]# mkdir -p /data/3307/data -
准备配置文件
cat > /data/3307/my.cnf < -
初始化数据库
mv /etc/my.cnf /etc/my.cnf.bak mysqld --initialize-insecure --user=mysql --datadir=/data/3307/data --basedir=/application/mysql -
设置以systemd的方式启动数据库(Centos6省略)
cd /etc/systemd/system cp mysqld.service mysqld3307.service vim mysqld3307.service # 修改为: ExecStart=/application/mysql/bin/mysqld --defaults-file=/data/3307/my.cnf -
授权数据目录
chown -R mysql.mysql /data/* -
启动数据库
systemctl start mysqld3307.service //Centos6启动方式 mysqld_safe --defaults-file=/data/3307/my.cnf & //Centos6关闭方式 mysqladmin -S /data/3307/mysql.sock shutdown //Centos6设置多实例密码 mysqladmin -uroot -S /data/3307/mysql.sock password '2' -
验证多实例
netstat -lnp|grep 330 -
开启binlog
log_bin=/data/3307/mysql-bin -
在主库创建复制用户（主）
mysql -uroot -p1 -e "grant replication slave on *.* to repl@'192.168.63.%' identified by '123'" flush privileges; show master status; -
要求数据完全一致则先备份主库的数据导入从库（主）
mysqldump -uroot -p2 -p 3306 -A --master-data=2 --single-transaction -R -E --triggers >/tmp/full.sql -
在从库导入数据（从）
mysql> source /tmp/full.sql -
告诉从库信息（从）
CHANGE MASTER TO MASTER_HOST='192.168.63.128', //主库IP地址 MASTER_USER='repl', 主库授权给从库的用户名及密码 MASTER_PASSWORD='123', MASTER_PORT=3306, 主库端口 #MASTER_LOG_FILE='mysql-bin.xxxxx', vim /tmp/full.sql查看主库的binlog及pos #MASTER_LOG_POS=xxx, 主库pos MASTER_AUTO_POSITION=1;开启了GTID模式则不需加以上两行 #MASTER_AUTO_POSITION=？;如果是导如通过xtrabackup备份的数据应该查看binlog填写 MASTER_CONNECT_RETRY=10; 重连次数 -
从库开启复制线程(IO,SQL)
mysql> start slave; -
检查主从复制状态、排错
mysql> show slave status \G
主从复制故障
- IO线程故障（connecting）
可能原因：
(1)网络、防火墙、连接数上限
解决：
stop slave;
reset slave all;
change master to
start slave
(2)请求binlog遇到的问题，比如binlog没开启或者损坏
解决：
主库：reset master
从库：stop slave；
reset slave all；
change master to
start slave
- SQL线程故障
可能原因：
relay-log损坏
合理解决方法：
把握一个原则,一切以主库为准进行解决.
如果出现问题,尽量进行反操作
最直接稳妥办法,重新构建主从
暴力的解决方法
方法一：
stop slave;
set global sql_slave_skip_counter = 1;
start slave;
#将同步指针向下移动一个，如果多次不同步，可以重复操作。
start slave;
方法二：
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常见的错误代码：
1007：对象已存在
1032：无法执行DML
1062：主键冲突，或约束冲突
为了很大程度避免SQL线程故障，我们一般配置主从读写分离:
从库只读：
read_only
super_read_only
使用读写分离中间件，比如mycat、atlas、proxySQL、Maxscale
主从延时监控主要原因
(1) binlog写入不及时
sync_binlog=1
(2) 默认情况下dump_t 是串行传输binlog *****
在并发事务量大时或者大事务,由于dump_t 是串行工作的,导致传送日志较慢，如何解决问题?
必须启用GTID,使用Group commit方式.可以支持DUMP_T并行
(3) 主库极其繁忙
慢语句
锁等待
从库个数
网络延时
从库方面可能原因：
(1) 传统复制(Classic)中
如果主库并发事务量很大,或者出现大事务，由于从库是单SQL线程,导致不管传的日志有多少,只能一次执行一个事务.
5.6 版本,有了GTID,可以实现多SQL线程,但是只能基于不同库的事务进行并发回放.(database)
5.7 版本中,有了增强的GTID,增加了seq_no,增加了新型的并发SQL线程模式(logical_clock),MTS技术
(2) 主从硬件差异太大
(3) 主从的参数配置
(4) 从库和主库的索引不一致
(5) 版本有差异
主从复制对事物的影响
对于写操作，包括开启事物、提交或回滚要在一台机器上执行，分散到多台master执行后数据库原生的单机事物就会失效。对于事务中同时包含写操作，与数据库中设置的隔离级别有关，如果事务隔离级别为read-uncommitted或者read-committed，读写分离没影响，如果隔离级别为repeatable-read、serializable，读写分离就有影响，因为在slave上会看到新数据，而正在事务中的master看不到新数据。
分库分表面临的问题
事务支持
- 分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
多库结果集合并（group by，order by）
跨库join
- 分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表， 结果原本一次查询能够完成的业务，可能需要多次查询才能完成。 粗略的解决方法： 全局表：基础数据，所有库都拷贝一份。 字段冗余：这样有些字段就不用join去查询了。 系统层组装：分别查询出所有，然后组装起来，较复杂。
水平分表出现的主键问题
- 如果把数据表分到集群中的其它机器上，自增的字段可能会出现重复的情况。各种解决方案的利弊如下：
1. UUID
UUID是通用唯一识别码（Universally Unique Identifier)的缩写，开放软件基金会(OSF)规范定义了包括网卡MAC地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素。利用这些元素来生成UUID。
UUID是由128位二进制组成，一般转换成十六进制，然后用String表示。
550e8400-e29b-41d4-a716-446655440000
UUID的优点:
- 通过本地生成，没有经过网络I/O，性能较快
- 无序，无法预测他的生成顺序。(当然这个也是他的缺点之一)
UUID的缺点:
- 128位二进制一般转换成36位的16进制，太长了只能用String存储，空间占用较多。
- 不能生成递增有序的数字
- 数据库主键自增
主键自增（auto increment）是我们最常用的方法。如果是单独的数据库，可以设置自增记录主键值；如果分成多个库每个库分别设置不同的自增起始值和固定步长，如：
第一台 start 1 step 9
第二台 start 2 step 9
第三台 start 3 step 9
优点：
简单方便，有序递增，方便排序和分页
缺点:
- 分库分表会带来问题，需要进行改造。
- 并发性能不高，受限于数据库的性能。
- 简单递增容易被其他人猜测利用，比如你有一个用户服务用的递增，那么其他人可-以根据分析注册的用户ID来得到当天你的服务有多少人注册，从而就能猜测出你这个服务当前的一个大概状况。
- 数据库宕机服务不可用
3. Redis
Redis中有两个命令Incr，IncrBy，因为Redis是单线程的所以能保证原子性。
优点：
性能比数据库好，能满足有序递增。
缺点：
由于redis是内存的KV数据库，即使有AOF和RDB，但是依然会存在数据丢失，有可能会造成ID重复。
依赖于redis，redis要是不稳定，会影响ID生成。
4. 雪花算法-Snowflake
Snowflake是Twitter提出来的一个算法，其目的是生成一个64bit的整数:
1bit: 一般是符号位，不做处理
41bit: 用来记录时间戳，这里可以记录69年，如果设置好起始时间比如今年是2018年，那么可以用到2089年，到时候怎么办？要是这个系统能用69年，我相信这个系统早都重构了好多次了。
10bit: 10bit用来记录机器ID，总共可以记录1024台机器，一般用前5位代表数据中心，后面5位是某个数据中心的机器ID
12bit: 循环位，用来对同一个毫秒之内产生不同的ID，12位可以最多记录4095个，也就是在同一个机器同一毫秒最多记录4095个，多余的需要进行等待下毫秒。
上面只是一个将64bit划分的标准，当然也不一定这么做，可以根据不同业务的具体场景来划分，比如下面给出一个业务场景：
- 服务目前QPS10万，预计几年之内会发展到百万。
- 当前机器三地部署，上海，北京，深圳都有。
- 当前机器10台左右，预计未来会增加至百台。
这个时候我们根据上面的场景可以再次合理的划分62bit,QPS几年之内会发展到百万，那么每毫秒就是千级的请求，目前10台机器那么每台机器承担百级的请求，为了保证扩展，后面的循环位可以限制到1024，也就是2^10，那么循环位10位就足够了。
机器三地部署我们可以用3bit总共8来表示机房位置，当前的机器10台，为了保证扩展到百台那么可以用7bit 128来表示，时间位依然是41bit,那么还剩下64-10-3-7-41-1 = 2bit,还剩下2bit可以用来进行扩展。
时钟回拨
因为机器的原因会发生时间回拨，我们的雪花算法是强依赖我们的时间的，如果时间发生回拨，有可能会生成重复的ID，在我们上面的nextId中我们用当前时间和上一次的时间进行判断，如果当前时间小于上一次的时间那么肯定是发生了回拨，算法会直接抛出异常。
雪花算法Python代码实现：
# Twitter's Snowflake algorithm implementation which is used to generate distributed IDs.
# https://github.com/twitter-archive/snowflake/blob/snowflake-2010/src/main/scala/com/twitter/service/snowflake/IdWorker.scala
import time
import logging
class InvalidSystemClock(Exception):
"""
时钟回拨异常
"""
pass
# 64位ID的划分
WORKER_ID_BITS = 5
DATACENTER_ID_BITS = 5
SEQUENCE_BITS = 12
# 最大取值计算
MAX_WORKER_ID = -1 ^ (-1 << WORKER_ID_BITS) # 2**5-1 0b11111
MAX_DATACENTER_ID = -1 ^ (-1 << DATACENTER_ID_BITS)
# 移位偏移计算
WOKER_ID_SHIFT = SEQUENCE_BITS
DATACENTER_ID_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS
TIMESTAMP_LEFT_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS + DATACENTER_ID_BITS
# 序号循环掩码
SEQUENCE_MASK = -1 ^ (-1 << SEQUENCE_BITS)
# Twitter元年时间戳
TWEPOCH = 1288834974657
logger = logging.getLogger('flask.app')
class IdWorker(object):
"""
用于生成IDs
"""
def __init__(self, datacenter_id, worker_id, sequence=0):
"""
初始化
:param datacenter_id: 数据中心（机器区域）ID
:param worker_id: 机器ID
:param sequence: 其实序号
"""
# sanity check
if worker_id > MAX_WORKER_ID or worker_id < 0:
raise ValueError('worker_id值越界')
if datacenter_id > MAX_DATACENTER_ID or datacenter_id < 0:
raise ValueError('datacenter_id值越界')
self.worker_id = worker_id
self.datacenter_id = datacenter_id
self.sequence = sequence
self.last_timestamp = -1 # 上次计算的时间戳
def _gen_timestamp(self):
"""
生成整数时间戳
:return:int timestamp
"""
return int(time.time() * 1000)
def get_id(self):
"""
获取新ID
:return:
"""
timestamp = self._gen_timestamp()
# 时钟回拨
if timestamp < self.last_timestamp:
logging.error('clock is moving backwards. Rejecting requests until {}'.format(self.last_timestamp))
raise InvalidSystemClock
if timestamp == self.last_timestamp:
self.sequence = (self.sequence + 1) & SEQUENCE_MASK
if self.sequence == 0:
timestamp = self._til_next_millis(self.last_timestamp)
else:
self.sequence = 0
self.last_timestamp = timestamp
new_id = ((timestamp - TWEPOCH) << TIMESTAMP_LEFT_SHIFT) | (self.datacenter_id << DATACENTER_ID_SHIFT) | \
(self.worker_id << WOKER_ID_SHIFT) | self.sequence
return new_id
def _til_next_millis(self, last_timestamp):
"""
等到下一毫秒
"""
timestamp = self._gen_timestamp()
while timestamp <= last_timestamp:
timestamp = self._gen_timestamp()
return timestamp
if __name__ == '__main__':
worker = IdWorker(1, 2, 0)
print(worker.get_id())