mysql主从复制+mysql主从复制延迟解决方案

1. 为什么需要mysql主从复制

  1. 数据热备

  2. 在复杂的业务场景中, 可能因为某一条sql造成了锁表, 这样就会影响正常的业务运行。在复杂的业务场景中, 我们可以使用mysql主从复制, 主库负责写, 从库负责读这样即使主库出现了锁表的场景通过从库读的业务也可以保证正常运行。

  3. 架构扩展。 业务访问量越来越大, io访问频率过高, 单机无法满足需求, 此时做多库存储降低单机的磁盘io访问频率,从而提高单机io的性能。

2. 什么是主从复制

主从复制是指数据从一个mysql主节点复制到一个或者多个从节点。mysql 默认是异步复制的方式, 从节点可以复制主节点中的所有数据或者指定的库或者表.

3. 主从复制原理

  1. 主库开启binlog, 将数据和表结构的改变记录在二进制文件binlog
  2. slave 会在一定的时间间隔内对master的二进制文件进行探测是否改变, 如果改变则开启一个 io Thread 请求master的 binlog
  3. 同时master会为每一 io thread 开一个 dump Thread, 用于向其传输二进制文件(binlog), 并保存到slave的中继日志(relay log)中.
  4. slave 启动sql Thread 从中继日志(relay log)中读取二进制数据 在本地进行重放, 使得slave 和 master数据保持一致. 最后 slave 的 io Threadsql Thread 进入睡眠状态等待再次被唤醒.

即:

  1. master 的dump Thread根据slave的请求, 将本地的binlogevents的方式发送给 IO Thread
  2. slave IO Thread 接收到binlog events后保存到中继日志(relay log)中, 传过来的信息会记录在master.info文件中.
  3. slave sql Thread获取中继日志中的内容进行重发, 并把应用过的记录到relay-log.info中, 默认情况下已经应用过的relay会自动被清理

注意:

  1. master 将操作语句记录在bin log中, 授权slave远程访问的权限.
  2. master和slave节点的时间需要同步

4. mysql主从复制的具体操作步骤

  1. 准备两台mysql, 可以在同一台机上也可以在不同的机上.
  2. 开启主节点的binlog, 在/etc/my.cnf 文件的 mysqld 下添加如下内容
# 开启 BinLog日志
log-bin=mysql-bin
# 服务器的唯一id, 默认是 1, 一般去ip最后一段
server-id=13
  1. 修改从节点的 /etc/my.cnf文件
# 开启 BinLog日志, 从节点可以开启binlog日志 也可以不开启, 我这里是开启了.
log-bin=mysql-bin
# 服务器的唯一id, 默认是 1, 一般去ip最后一段
server-id=14
  1. 重启master和slave
  2. 登录master执行 show master status 命令查看binlog日志文件和偏移量.
    image.png
  3. 登录从库通过 change master to 语句连接master.
CHANGE MASTER TO MASTER_HOST = 'ip或者域名', MASTER_USER = '用户名',MASTER_PASSWORD = '密码', MASTER_PORT = 端口, MASTER_LOG_FILE='binlog文件名', MASTER_LOG_POS=偏移量;
  1. 启动slave, 执行如下命令
start slave
  1. 执行 show slave status \G; 得到如下结果便是启动成功
    image.png

5. Mysql主从同步延迟分析

Mysql 主从同步都是单线程的, master所有的DDLDML都会写入binlog中, 由于binlog是顺序读写, 所以效率很高, slave的sql Thread将master的DDLDML操作事件都在slave中重发. DDLDML 的IO操作是随机的, 不是顺序的, 所以成本要高很多, 另一方面由于SQL Thread也是单线程, 当master并发高的时候,产生的DML数量超出了slaveSQL Thread的处理速度, 或者当slave有大型的query语句产生了锁, 那么延迟就产生了.

解决方案:

  1. 业务的持久化层的实现采用分库架构, mysql服务器可以平行扩展, 分散压力
  2. 单个主库, 多个从库, 主写从读
  3. 服务的基础架构在业务层和持久化层间加入memcache或者redis构成的cache层. 降低mysql的读写压力

4.不同的业务的mysql放在不同的物理机上,分散压力.

  1. 使用更加好的硬件设备
  2. mysql5.7 之后使用MTS并发复制技术, 永久解决复制延迟问题
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,607评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,047评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,496评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,405评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,400评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,479评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,883评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,535评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,743评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,544评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,612评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,309评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,881评论 3 306
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,891评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,136评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,783评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,316评论 2 342