主从复制介绍
- 主从复制基于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 <<EOF [mysqld] basedir=/app/mysql datadir=/data/3307/data socket=/data/3307/mysql.sock log_error=/data/3307/mysql.log port=3307 server_id=7 log_bin=/data/3307/mysql-bin binlog_format=row ----------启用GTID模式构建主从 gtid-mode=on --启用gtid类型,否则就是普通的复制架构 enforce-gtid-consistency=true --强制GTID的一致性 log-slave-updates=1 --slave更新是否记入日志 sync_binlog=1 --每次事务提交都立即刷写binlog到磁盘 最高安全模式 innodb_flush_log_at_trx_commit=1(0:一秒会发生n多事务,断电可能会丢失1秒内的所有事务;2(分两步提交事务,一步只保证刷写到os buffer。)) Innodb_flush_method=O_DIRECT 最高性能: innodb_flush_log_at_trx_commit=0 innodb_flush_method=fsync EOF
-
初始化数据库
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())