MySQL-12mysql主从复制与备份

2021-09-28  本文已影响0人  安晓生

大家好，本片总结一下MySQL的主从复制，有些不对的地方可以评论，一起交流。

mysql主从复制与备份

MySQL数据库支持单向、双向、链式级联、环状等不同业务场景的复制。在复制过程中，一台服务器充当 主服务器(Master)，接收来自用户的内容更新，而一个或多个其他的服务器充当从服务器(Slave)，接 收来自主服务器binlog文件的日志内容，解析出SQL重新更新到从服务器，使得主从服务器数据达到一致。

1.1 应用场景

MySQL主从复制集群功能使得MySQL数据库支持大规模高并发读写称为可能，同时有效地保护了物理服务器宕机场景的数据备份。

主从服务器架构的设置，可以大大加强MySQL数据库架构的健壮性。例如:当主服务器出现问题时，我们 可以人工或设置自动切换到从服务器继续提供服务，此时从服务器的数据和宕机时的主数据库几乎是一致的。
这类似NFS存储数据通过inotify+rsync同步到备份的NFS服务器，只不过MySQL的复制方案是其自带的工 具。
利用MySQL的复制功能做备份时，在硬件故障、软件故障的场景下，该数据备份是有效的，但对于人为地 执行drop、delete等语句删除数据的情况，从库的备份功能就没有用了，因为从服务器也会执行删除的语 句。

主从服务器架构可通过程序(PHP、Java等)或代理软件(mysql-proxy、Amoeba)实现对用户(客户 端)的请求读写分离，即让从服务器仅仅处理用户的select查询请求，降低用户查询响应时间及读写同时在 主服务器上带来的访问压力。对于更新的数据(例如update、insert、delete语句)仍然交给主服务器处理，确保主服务器和从服务器保持实时同步。

可以把几个不同的从服务器，根据公司的业务进行拆分。例如:有为外部用户提供查询服务的从服务器， 有内部DBA用来数据备份的从服务器，还有为公司内部人员提供访问的后台、脚本、日志分析及供开发人员 查询使用的从服务器。这样的拆分除了减轻主服务器的压力外，还可以使数据库对外部用户浏览、内部用 户业务处理及DBA人员的备份等互不影响。

1.2 优点与解决的问题

注意:由于 mysql 实现的异步复制，所以主库和从库数据之间存在一定的差异，在从库执行查询 操作需要考虑这些数据的差异，一般只有更新不频繁和对实时性要求不高的数据可以通过从库查询，实行要求高的仍要从主库查询。

2. 主从复制原理

MySQL主从复制涉及到三个线程，一个运行在主节点(log dump thread)，其余两个(I/O thread, SQL thread)运行在从节点，如下图所示

主从节点.png

3个节点介绍

当从节点连接主节点时，主节点会为其创建一个log dump 线程，用于发送和读取bin-log的内容。在读取 bin-log中的操作时，log dump线程会对主节点上的bin-log加锁，当读取完成，在发送给从节点之前，锁会 被释放。主节点会为自己的每一个从节点创建一个log dump 线程。

当从节点上执行 start slave 命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点的blog dump进程发来的更新之后，保存在本地relay-log(中继日志)中。

  • SQL线程负责读取relay-log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。

对于每一个主从连接，都需要这三个进程来完成。
当主节点有多个从节点时，主节点会为每一个当前连接 的从节点建一个log dump 进程，而每个从节点都有自己的I/O进程，SQL进程。
从节点用两个线程将从主 库拉取更新和执行分成独立的任务，这样在执行同步数据任务的时候，不会降低读操作的性能。
比如，如 果从节点没有运行，此时I/O进程可以很快从主节点获取更新，尽管SQL进程还没有执行。
如果在SQL进程 执行之前从节点服务停止，至少I/O进程已经从主节点拉取到了最新的变更并且保存在本地relay日志中，当 服务再次起来之后，就可以完成数据的同步。

重点：
要实施复制，首先必须打开Master 端的binary log(bin-log)功能，否则无法实现。

因为整个复制过程实际上就是Slave 从Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。如下图所示:
执行顺序.png

2.1 复制的基本过程

3.主从复制备份

不同类型的数据库备份，所能应付的情况是不一样的， 而且，数据库的备份同时也还具有其他很多的作 用。相信每个人对数据库备份作用的理解都会有差别。
1. 数据丢失应用场景
(1)人为操作失误造成某些数据被误操作;
(2)软件BUG造成数据部分或全部丢失;
(3)硬件故障造成数据库数据部分或全部丢失;
(4)因安全漏洞，入侵者将数据恶意破坏。

2. 非数据丢失应用场景
(1)特殊应用场景下基于时间点的数据恢复;
(2)开发测试环境数据库搭建;
(3)相同数据库的新环境搭建;
(4)数据库或数据迁移。

注：啰嗦点话：

上面所列出的只是一些常见的应用场景，除了这几种场景，数据库备份还会有很多其他应用场景。
没有哪一种数据库备份能够解决以上列举的所有场景，即使仅只是数据丢失的各种场景都无法通过某一种 数据库 备份完美解决，当然就更不用说能够解决所有备份的应用场景了。比如:

  1. 当我们遇到磁盘故障，丢失了整个数据库的所有数据，并且无法从已经出现故障的硬盘上面恢复出来 的时候，就可能必须通过一个实时或有短暂时间差的复制备份数据库来进行恢复。当然如果没有这样 的一个数据库，就必须有最近时间点的整个数据库的物理或逻辑备份数据，并且有该备份之后的所有 物理或逻辑增量备份，以期望尽可能地将数据恢复到出现故障之前最近的时间点。
  2. 而当我们遇到操作失误造成数据被误操作时，就要有一个能恢复到错误操作时间点之前的瞬间备份， 当然这个备份可能是整个数据库的备份，也可以仅仅是被误操作的表的备份。
  3. 而当我们要做跨平台的数据库迁移时，则需要一个逻辑的数据库备份，因为平台的差异可能使物理备 份的文件格式在两个平台上无法兼容。
    既然没有哪一种数据库备份能够完美地解决所有应用场景的需要，而每个数据库环境要面对的数据库备份 应用场景又可能各不一样，也许只是须要面对很多种场景中的某种或儿种， 那么就非常有必要指定一个合 适的备份方案和备份策略，通过最简单的技术和最低廉的成本来满足我们的需求。

3.1 冷备份与恢复

3.1.1 逻辑备份
逻辑备份可以说是最简单，也是目前中小型系统最常使用的备份方式。
1.mysqldump
2.mydumper

2. 在从服务上通过连接主服务器上的数据库，通过mysqldump备份数据到从数据库中

在主服务器上，设置读锁定有效，这个操作为了确保没有数据库操作，以便获得一致性的快照。

flush tables with read lock;

然后在从服务器上进行数据的备份，并同步导入备份数据。

在数据备份完成之后这个时候就可以恢复主数据库的写操作执行命令如下:

unlock tables;
3.1.2 物理备份

最暴力的备份：停止主库，然后复制主库中的data放到从库中。

3.1.3 使用mydumper

mydumper是一个针对MySQL和drizzle的高性能多线程的备份和恢复工具。此工具的开发人员分别来自 MySQL、facebook、skysql公司、目前已经有一些大型产 品业务测试并使用了该工具。我们在恢复数据库 时也可使用myloader工具。

特性

剩下的可以自己百度

3.2 热备份与恢复

热备份的方式也是直接复制数据物理文件，和冷备份一样，但热备份可以不停机直接复制，一般用于7×24小时不间断的重要核心业务。
注：有很多其他热备份的工具，MySQL社区版的热备份 工具ImnoDB Hot Backup是付费的所以不考虑这个了。用一下这个，Percona公司发布了一个xtrabackup热备份工具。

安装：

yum localinstall percona-xtrabackup-80-8.0.14-1.el7.x86_64.rpm
xtrabackup

常用命令：

中主要包含两个工具: xtrabackup:是用于热备innodb，xtradb表中数据的工具，不能备份其他类型的表，也不能备份数 据表结构;
innobackupex:是将xtrabackup进行封装的perl脚本，提供了备份myisam表的能力。
常用选项:
--host 指定主机
--user 指定用户名
--password 指定密码
--port 指定端口
--databases 指定数据库
--incremental 创建增量备份
--incremental-basedir 指定包含完全备份的目录
--incremental-dir 指定包含增量备份的目录
--apply-log 对备份进行预处理操作 一般情况下，在备份完成后，数据尚且不能用于恢复操作，因 为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。 因此，此 时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事 务至数据文件也使得数据文件处于一致性状态。
--redo-only 不回滚未提交事务
--copy-back 恢复备份目录

开始进行备份操作,进入 主库 中

xtrabackup --defaults-file=/etc/my.cnf --user=root --password=root -- port=3306 --backup --target-dir=/home/master_slave
//找到备份的文件，进行备份：
scp -r /home/laravel-shop/ root@192.168.153.127:/home/laravel-shop

然后呢进入 从库中：

//
xtrabackup --defaults-file=/etc/my.cnf --copy-back --target- dir=/home/mysql_php/mysql_php
chown -R mysql:mysql /usr/local/mysql/data

4. 主从复制实现方式

4.1.1 Master节点配置

单MySQL问题:

  1. 性能问题
  2. 数据备份问题

多MySQL好处

  1. 性能问题--不一定提高;
  2. 数据冗余

对于MySQL的主从复制来说最重要的主要就是binlog日志，所以我们就需要开启binlog日志，并设置server- id的值。需要重启服务器之后才生效 二进制日志，也就是我们常说的binlog。

二进制日志记录了MySQL所有修改数据库的操作，然后以二进制的形式记录日志在日志文件中，其中还包 括没调语句所 执行的时间和消耗的资源，以及相关的事务信息。默认情况下二进制日志功能是没有开启 的，启动可以配置log-bin[=file_name]开启，

show global variables like '%log_bin%';

日志作用就是:

  1. 增量备份(不是所有数据备份，而是最近的写操作)
  2. 用于MySQL主从复制
vi /etc/my.cnf
//主要就是下配置文件中添加如下配置
log-bin=mysql-bin 
server-id=1

4.1.2 Slave节点配置

要先明确配置的架构Master-slave

  1. 配置主节点 1.1 配置账号 1.2 开启binlog日志
  2. 配置从节点 2.1 配置同步日志 2.2 指定主节点的ip， 端口， 用户.. 2.3 启动从节点
    修改配置
find / -name my.cnf /etc/my.cnf
vi /etc/my.cnf
find / -name mysqld /etc/rc.d/init.d/mysqld/www/server/mysql/bin/mysqld
/etc/rc.d/init.d/mysqld restart

在配置文件中添加:

# 配置从节点
server-id = 2
relay_log = /usr/local/mysql/data/mysql-relay-bin 
relay_log-index = /usr/local/mysql/data/mysql-relay-bin.index log_slave_updates = 1
read_only = 1

参数介绍:

  1. server_id:这是服务id系统会自动命名的，但如果机器名边画画肯能回答导致问题。可以讲你主库和备库 上的log-bin设置为相同的值。
  2. relay_log:指定 中继日志的位置和命名

指定主节点的ip，端口，用户

change master to master_host='192.168.29.102',master_port=3306,master_user='slave',master_password='slav e',master_log_file='mysqlbin.000002',master_log_pos=155;

start slave;
show slave status \G;

对于我们来说其中的信息主要是关注：
reset slave all 清楚slave信息 测试的方法就是在主服务器中，添加一些数据测试观察从服务其中的数据变化 情况。

可以看一下另一篇主从复制文章：https://www.jianshu.com/p/5ba7770a952f

上一篇 下一篇

猜你喜欢

热点阅读