Mysql 12 复制1

备份，灾难恢复，大规模，水平扩展，高性能的基础，也是高可用，可扩展，及数据仓库的基础。

简述

开销

Mysql有两种复制方式：基于行的复制和基于语句的复制。
都是通过在主库上记录二进制日志，在备库上重放日志实现的。

主要开销来自于：

  • 主库部分启用二进制日志带来的开销。
  • 每个备库会增加网络开销
  • 主库开多线程给备库同步数据开销会累加

    通常使用读写分离，在备库中读来获得读扩展

解决的问题

  • 负载均衡 读写分离，度扩展
  • 数据分布 用复制功能来简历多个不同的数据中心
  • 备份
  • 高可用性 避免单点失败，可以很快的切换到备库，缩短宕机时间
  • 升级测试，用高版本作为备库，可以看看能否按照预期执行。

复制如何工作

  • 主库事务提交时记录事件到二进制日志中
  • 备库启动I/O线程去连接主库，主库启动一个线程来处理连接，然后又事务日志要写的时候，主库写日志给备库，备库处理到自己的中继日志中
  • 重放中继日志，回写备库数据

配置复制

拢共分三步

  • 在主备都创建复制账号
  • 配置主库和备库
  • 通知备库连接到主库复制数据

创建账号

注意权限，注意ip限制，因为有权利读取日志，所以还是限制了ip

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl1@'10.28.%.%' IDENTIFIED BY 'p4ssword';

配置主备库

主库打开二进制日志my.cnf加入：
log_bin = mysql-bin
server_id = 10
server_id是自己定的。必须是唯一的。
使用如下的语句检查：

SHOW MASTER STATUS;

备库的配置：

log_bin = mysql-bin
server_id = 2
##中继文件日志
relay_log = /var/lib/mysql/mysql-relay-bin
##允许把重复也记录到备库的binlog
log_slave_updates = 1
read_only = 1
##放弃了master_port这样的配置方式

启动复制

在备库中执行：

CHANGE MASTER TO MASTER_HOST='主库ip',
-> MASTER_USER='repl', ## 刚才创建的
-> MASTER_PASSWORD='p4ssword',
-> MASTER_LOG_FILE='mysql-bin.000001', ## 主库中执行SHOW MASTER STATUS得到的
-> MASTER_LOG_POS=0; 从头读起

执行完成后使用 SHOW SLAVE STATUS来查看一下发现Slave_IO_Runing为NO
在执行
START SLAVE;来启动

还可以从主库上检查复制线程
SHOW PROCESSLIST

有库不是新库时

把已有库编成另一个的备库，我们需要如下的信息：

  • 某一时刻快照
  • 主库当前的二进制文件和快照在二进制文件中的坐标
  • 从快照时间到现在的二进制日志
    一些克隆备库的方法：
  • 冷备 ， 关闭数据库， 把数据复制到备份。 然后配置主备，重启之后会用新的日志文件，在被库中执行CHANGE MASTER TO 命令进行同步
  • mysqldump –single-transaction –all-databases –master-data=1 –host=server1 mysql –host=server2
  • 使用Percona Xtrabackup工具

推荐的复制配置

sync_binlog=1 开启则每次提交事务都会将二进制日志同步到磁
盘。
log_bin=/ 指明二进制文件名，免得默认的因为系统不同而有问题
relay_log_purge 控制重放完后尽快删除中继日志
read_only=
relay_log=

复制原理

基于语句

简单的记录执行的语句，放到备库去执行
优点：
更容易理解
更灵活及容错，因为都是sql语句的

缺点：
存储过程，触发器不行
一些依赖环境的内置方法也不行
必须顺序执行，会带来更多的锁

基于行

日志记录行的变更。
优点：
可以直接复制变更结果，对于一些耗时sql可以节约性能
不会受到触发器等特殊情况的限制

缺点：
无法判断执行了哪些sql,有点像黑盒子
不好跟踪问题
对于一些特殊语句比如update 全表的一个状态，这种基于行的开销会很大

Mysql会自动切换，当基于语句不行的时候就会尝试基于行的。

复制拓扑

  • 一个备库只能有一个主库
  • 每个备库必须有唯一id
  • 打开log_slave_updates选项时，备库可以把其主库上的数据变化传播到其他备库

    一主多备

  • 一个备库用于灾难恢复
  • 适用于少写多读的场景。可以负载均衡
  • 使用一个备库用于测试等等
  • ALtertable这样的语句在备库执行，然后主备切换

    双主动双主库

    太乱，Mysql不支持

    主动-被动 双主结构

    可以认为是一个热备。 可以随时切换主备
    被动模式的主库也可以当备库一样使用

    主库带备库的 主动-被动 双主结构

    主动，被动两个库都各有一个备库

    分发主库

    作为被动的主库有多个备库。这种可以防止备库太多给主库带来负载
    但是这样就不能直接使用备库替换主库了。因为中转了一道bin_log不一样了

    树形

    一个主，多个备，备库又有备库的结构。
    好处跟分发主库有点像，可以减少多备库压力
    坏处在于如果沿途有节点除了问题，会影响多个节点

选择性复制

备库复制主库中不同的表。
简单的做法就是在主库中把表放入不同的数据库，然后备库只复制其中一个数据库。
这样每个备库都只有一部分的主库写入负载

备库的用途

  • 数据分离 可以专门分离一个备库出来，做在线数据分析OLAP，而不是在线事务处理OLTP
  • 数据归档 在备库上保存主库上删除的数据
    可以用过滤， 或者是user db1, replicate_ignore_db=db1这样的方式
  • 备库做全文检索 把备库中的部分表用MyISAM引擎
  • 只读备库

模拟多主库复制

Mysql不支持一个备库多主库， 可以让备库一会儿指向备库A，一会儿指向备库B， 这样增加一点额外的工作来记录bin-log位置

创建日志服务器

如果一个服务器崩溃了，我们去他的二进制日志或者中继日志，希望重放他。
这是可以勇mysqlbinlog工具。
更好的方式是，建立一个新的数据库，让他认为这些二进制文件时他的。然后启动他，让别的数据库来复制它来获得二进制文件进行重放
好处：

  • 复制的速度很快
  • 更方便处理错误
  • 复制功能被测试过，运行良好

复制和容量规划

先看个计算，假设，读写消耗一样，读写比例2:8， 服务器只能每秒1000次请求。
这个时候做读写分离。 如果支撑请求翻倍需要增加多少台备库呢？
翻倍的话，要有400次写，1600次读，每个备库都会有400次写，那么这个时候就只能支撑600次读了，所以需要三台备库。

这样算下来，使用读写分离和备库的方式负载查询代价很高。
一般不要让读超过50%的负载，避免备库出现问题的时候造成单点热点过高。

可以停止备库，过一小时之后打开，看备库多久能赶上，来得到备库的执行性能
大多数情况下性能还是比较好的，在主库执行的耗时操作往往是备库延迟的原因。

时间： 2024-03-18 23:48:48

Mysql 12 复制1的相关文章

Mysql AB 复制

目录(?)[-] 关于MySQL AB复制 快速打包和安装MySQL  MySQL AB单向复制 MySQLAB双向复制 MySQL多级主从复制 解决AB双向复制主键冲突 关于MySQL AB复制 本文讲解如何快速打包和安装MySQL, MySQL AB复制,MySQL AB双向复制,MySQL多级主从复制,解决AB双向复制主键冲突.   首先我们先介绍什么是MySQL AB复制.   AB复制又称主从复制,实现的是数据同步.如果要做MySQL AB复制,数据库版本尽量保持一致.如果版本不一致,

各版本MySQL并行复制的实现及优缺点

MySQL并行复制已经是老生常谈,笔者从2010年开始就着手处理线上这个问题,刚开始两三年也乐此不疲分享,现在再提这个话题本来是难免"炒冷饭"嫌疑.    最近触发再谈这个话题,是因为有些同学觉得"5.7的并行复制终于彻底解决了复制并发性问题", 感觉还是有必要分析一下.大家都说没有银弹,但是又期待银弹..   既然要说5.7的并行复制,干脆顺手把各个版本的并行复制都说明一下,也好有个对比.便是本次分享的初衷.   [背景] 一句话说完,因为这几年太多这样文章了,

使用MySQL自身复制来恢复binlog

在MySQL手册中一直是推荐使用mysqlbinlog工具来实现指定时间点的数据恢复,事实上,这是一个经常"让人郁闷"的办法.更好的办法是,使用MySQL内部复制线程中的SQL Thread来做恢复. 这个idea来自Lazydba同学:在Google稍作搜索,在Xaprb上Baron Schwartz也很早提到了使用类似的方法来恢复binlog,在那篇讨论中,还可以看到Jeremy Cole也提到:使用MySQL手册中推荐的方法是困难重重的,而且mysqlbinlog这个办法从逻辑上

大众点评工程师：从黄金圈法则看MySQL数据库复制

每当我们讨论一项(新的)领域技术的时候,最好的方式通常是首先抛出一些问题,这些问题大致分为三类:  诶?这项技术又是什么玩意(What)? 这项技术为什么会存在?我们已经有那么多解决方案(Method)了,我们问什么要用它(Why)? 如果这项技术那么好且我们正好有场景可以用到这项技术,且能使我们的系统得到很乐观的优化,那么我们怎么用呢(How)?   大概已经有同学觉得这些问题很熟悉了,是的,这就是黄金圈法则提出的三个问题,对于每种新鲜事物我们首先基于这三个问题去了解,更有利于弄清楚事情的本质

各版本 MySQL 并行复制的实现及优缺点

MySQL并行复制已经是老生常谈,笔者从2010年开始就着手处理线上这个问题,刚开始两三年也乐此不疲分享,现在再提这个话题本来是难免"炒冷饭"嫌疑. 最近触发再谈这个话题,是因为有些同学觉得"5.7的并行复制终于彻底解决了复制并发性问题", 感觉还是有必要分析一下.大家都说没有银弹,但是又期待银弹.. 既然要说5.7的并行复制,干脆顺手把各个版本的并行复制都说明一下,也好有个对比.便是本次分享的初衷. [背景] 一句话说完,因为这几年太多这样文章了, 就是MySQL

基于MySQL数据库复制Master-Slave架构的分析_Mysql

为了应用系统的可伸缩性,往往需要对数据库进行scale out设计,scale out设计也就是通过增加数据库处理节点来提高系统整体的处理能力,即增加数据库服务器的数量来分担压力.通过这种方式系统的伸缩性增强了,成本也降低了,但是系统的架构复杂了,维护困难了.难免出现系统的宕机或故障.因此,理论上来说,系统的安全性(可能数据丢失)降低了,可用性也降低了.那么要提高数据安全性,以及系统的高可用性,很简单的办法就是所有软硬件都避免单点隐患,所有数据都保存多份.从技术上来说,就可以通过数据库复制技术实

MySQL快速复制数据库数据表的方法_Mysql

某些时候,例如为了搭建一个测试环境,或者克隆一个网站,需要复制一个已存在的mysql数据库.使用以下方法,可以非常简单地实现. 假设已经存在的数据库名字叫db1,想要复制一份,命名为newdb.步骤如下: 1. 首先创建新的数据库newdb #mysql -u root -ppassword mysql>CREATE DATABASE `newdb` DEFAULT CHARACTER SET UTF8 COLLATE UTF8_GENERAL_CI; 2. 使用mysqldump及mysql的

MySQL级联复制中的数据同步（第二篇）

今天解决了两个蛮有意思的MySQL问题,简单分享出来. 首先是昨天说的级联复制的情况,因为架构做了调整,我们要删除其中的一个中继节点(新加坡节点),而直接使用北京节点去连接北美的节点. 更多的信息可以参考. MySQL级联复制中的数据同步(r11笔记第20天) 大体的架构方式如下: 如此一来,为了避免重建从库,而且没有GTID的情况下,我们可以统一规划一下偏移量,平滑迁移. 实现后的架构图如下: 看起来还是比较简单,但是偏移量真是一个比较琐碎细致的活儿.在此也感谢我的同事程振,我们一起讨论了实现

MySQL级联复制中数据同步

    最近开发的同事反馈了一个问题,说有一台北京节点的MySQL数据库数据延迟太大,想让我们帮忙看看怎么解决.     这个问题一下子让我想起了之前"水深火热"的日子,因为这是一套MySQL级联复制的环境.这么做的目的也是为了能够方便数据查询和统计任务,看起来虽好,但是老是有一些不可控因素.    北美使用AWS在北美,都是实时的业务数据,考虑了灾备和读写分离使用了一主一从的架构,新加坡节点2是一个中继节点,也使用了AWS,可以看到新加坡节点是北美节点的从库,但是北京的主库. 北京节