XtraBackup

一、环境信息 CentOS Linux release 7.8.2003 (Core) 4.4.240-1.el7.elrepo.x86_64 k8s 集群版本：1.15 docker 版本：Docker version 17.03.3-ce 集群信息： NAME STATUS ROLES AGE VERSION km-1.11 Ready master 7d7h v1.15.1 kn-1.11 Ready <none> 7d7h v1.15.1 kn1-1.11 Ready <none> 31h v1.15.1 二、MySQL的高可用方案 MySQL高可用方案采用主从复制+读写分离，即由单一的master和多个slave所构成。其中，客户端通过master对数据库进行写操作，通过slave端进行读操作。master出现问题后，可以将应用切换到slave端。 此方案是MySQL官方提供的一种高可用解决方案，节点间的数据同步采用MySQL Replication技术。MySQL Replication从一个MySQL数据库服务器（master）的数据复制到一个或多个MySQL数据库服务器（slave）。在默认情况下，复制是异步的；slave不需要一直接收来自主机的更新。根据配置，可以复制数据库中的所有数据库、选定的数据库，或者特定的表。 三、架构说明 通过mysql

1、搭建mysql服务器，并实现主主复制、半同步复制 存储引擎： 表类型：也称为“表类型”，表级别概念，不建议在同一个库中的表上使用不同的ENGINE； CREATE TABLE ... ENGINE[=]STORAGE_ENGINE_NAME ... SHOW TABLE STATUS 常见的存储引擎： MyISAM, Aria, InnoDB, MRG_MYISAM, CSV, BLACKHOLE, MEMORY, PERFORMANCE_SCHEMA, ARCHIVE, FEDERATED InnoDB：InnoBase Percona-XtraDB, Supports transactions, row-level locking, and foreign keys 数据存储于“表空间(table space)"中： (1) 所有数据库中的所有类型为InnoDB的表的数据和索引存储于同一个表空间中； 表空间文件：datadir定义的目录中 文件：ibdata1, ibdata2, ... (2) innodb_file_per_table=ON，意味着每表使用单独的表空间文件； 每表的数据文件（数据和索引，存储于数据库目录）存储于自己专用的表空间文件中，并存储于数据库目录下: tbl_name.ibd 表结构的定义：在数据库目录，tbl_name.frm 事务型存储引擎

##MySQL GTID 系列之一 ###一.GTID相关概念 ####GTID:全局事务标识符,MySQL5.6版本开始在主从复制中推出的重量级特性。 ####每提交一个事务,当前执行线程都会拿到一个给定复制环境中唯一的GTID， ####GTID的格式如下: GTID = source_id:sequence_id sourceid:主服务器的唯一标识,通常用server_uuid来表示。 sequence_id:事务提交时由系统顺序分配的序列号,在Binlog中是递增且连续有序。 show master status \G ####1.1 GTID生命周期 #####1.MASTER产生GTID,保存到Binlog中。 #####2.发送Binlog到SLAVE,保存到Relay Log #####3.SQL线程从Relay Log中获取GTID,并设置为gtid_next,然后对比SLAVE端的Binlog是否有记录。 #####4.如果有记录，说明该GTID的事务已经执行，SLAVE会忽略。 #####5.如果没有记录，SLAVE就会从Relay Log中执行该GTID的事务，并记录到Binlog。 #####6.SLAVE不生成GTID ####1.2 GTID的优点 #####1.一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次 #####2

数据库技术离不开数据库环境搭建。在讨论搭建环境之前，我先推荐一篇文章给大家： 首席架构师白鳝：运维的进阶与哲学之道 。这篇文章对我影响很大，在我还只是个纯粹单一技术思想的IT男时，它让我的思维格局都得到极大的提升。 这篇文章和数据库搭建的关系 可能有些小伙伴心里会有疑问：不就是个MySQL数据库搭建吗？如此简单的内容，而且网上文档满天飞。说好的尽量不讲网上已经存在的重复知识点呢？而且你讲搭建就专心讲，扯上面那些干嘛？就想说明你多崇拜白总吗？（没错，我确实极度崇拜他。） 我先简单解释下：本篇确实主讲MySQL搭建，但是我会在搭建时融入上述文章中提到的思想，这将使搭建更精益化、规范化，且更容易实现自动化甚至智能化。后续也会引申出不少基于这个搭建模式的知识及思想。我不想只分享纯粹的技术知识，我觉得规范化，架构化等思想更为重要。也希望小伙伴们通过我的分享，能将普通的技术知识应用到企业级的架构中去。 下面将分享一下我的搭建方法，可能大家会觉得步骤和常规的比起来略显繁琐，但为了更标准化、规范化，部分操作在手动操作的情况下是无法避免的。不过由于实现了标准化，这会让后续的自动化实现起来更加容易，所以也无需过于纠结操作的繁琐。 MySQL二进制规范搭建步骤 注意：命令行头标识如下： # 表示root用户执行 $ 表示mysql用户执行 mysql> 表示myql命令行执行 1、规范信息： 内容 规范

​背景 首先交代一下背景，由于某些因素的限制，我们公司目前的备份策略采用的是隔天全备的方案，增量备份则使用的是binlog server的方式，那么如何快速恢复就成为了我们需要思考的问题。 正文 恢复需求 根据我以往的一些经验来说，通常需要从备份恢复数据的场景有如下几种： 被误删库了； 被误删表了，类型为TRUNCATE或者DROP； 被误删列了，类型为ALTER ... DROP COLUMN； 被误删数据了，类型为DELETE或者UPDATE或者REPLACE； 表空间损坏或出现坏块了。 根据场景来说，我们可以大致分为两类： 第一类为不可逆恢复，也就是通常的DDL，比如上述的1、2、3、5等场景； 第二类为可逆的恢复，通常可以利用binlog进行回滚（要求binlog格式为ROW，binlog_image为FULL），也就是对应上述的场景4。 对于第二类的恢复需求一般来说都比较容易处理，可以利用binlog回滚工具，例如业界比较著名的有binlog2sql以及MyFlash等，这里暂不赘述，我们重点来讨论第一类需求。 为了达到快速恢复的目的，业界DBA经常会采用的方式就是部署一个延迟从库来解决，我们公司目前所有的核心DB都部署了延迟从库。但是即便有了延迟从库，假设我们错过了延迟的时间，或者在后续利用延迟从库恢复的时候指定错了位点，导致了误删DDL同样应用到了从库

一、需求描述 1、自然语言来描述 是一个“主从复制”（Maser-Slave Replication）的 MySQL 集群； 有 1 个主节点（Master）； 有多个从节点（Slave）； 从节点需要能水平扩展； 所有的写操作，只能在主节点上执行； 读操作可以在所有节点上执行。 2、图形描述 二、需求分析 1、通过 XtraBackup 将 Master 节点的数据备份到指定目录。 $ cat xtrabackup_binlog_info TheMaster-bin.000001 481 2、配置 Slave 节点 Slave 节点在第一次启动前，需要先把 Master 节点的备份数据，连同备份信息文件，一起拷贝到自己的数据目录（/var/lib/mysql）下。然后，我们执行这样一句 SQL： TheSlave|mysql> CHANGE MASTER TO MASTER_HOST='$masterip', MASTER_USER='xxx', MASTER_PASSWORD='xxx', MASTER_LOG_FILE='TheMaster-bin.000001', MASTER_LOG_POS=481; 3、启动 Slave 节点 TheSlave|mysql> START SLAVE; 这样，Slave 节点就启动了。它会使用备份信息文件中的二进制日志文件和偏移量

linux系统——Mysql备份及恢复详解 一个公司最重要的价值所在就是用户数据，所以对数据库的备份是十分重要的，同时对数据库的备份策略是多种多样的，这里简单介绍一下 percona-xtrabackup工具 ，和 自带的mysqldump工具 两种备份方式。 percona-xtrabacku工具 完整备份——全部备份 增量备份——备份基于上一次备份增加的数据 差异备份——备份基于上一次完整备份增加的数据 - 部署percona-xtrabacku 官网下载：www.percona.com 因为官网速度太慢就提前下载了 安装percona需要的mysql包 yum install mysql-community-libs-compat -y - 完整备份 模拟数据产生： mysql - uroot - p '密码' - e '操作（create，insert）' ； \\ - e 在数据库外对数据库操作 完整备份： innobackupex --user=root --password='QianFeng@123' /xtrabackup/full inno主体命令 登陆用户 登录密码 备份文件存放路径 模拟数据损坏： 可以试一下，想干又不敢干的事了，删库！！不用跑路的那种 备份恢复： 生成回滚日志： innobackupex --apply-log /xtrabackup

1 关于备份 1.1 为什么要备份 灾难恢复 ，数据库在运行过程中，终会遇到各种各样的问题: 硬件故障、Bug 导致数据损坏、由于服务器宕机或者其他原因造成的数据库不可用。除此以外还有人为操作： DELETE 语句忘加条件、 ALTER TABLE 执行错表、 DROP TABLE 执行错表、黑客攻击，即使这些问题你都还没遇到，但是根据墨菲定律，总会有遇上的时候。 回滚 ，由于某种Bug或系统被黑造成大量的损失，这个时候就需要回滚到某个状态。常见的有区块链交易所被黑然后回滚，游戏漏洞被利用然后整体回滚。 审计 ，有时候有这样的需求：需要知道某一个时间点的数据是怎么样的，可能是年末审计，也可能是因为官司。 测试 ，一个基本的测试需求是，定时拉取线上数据到测试环境，如果有备份，就可以非常方便地拉取数据。 1.2 有哪些备份方式 1.2.1 逻辑备份 逻辑备份是最常见的方式，在数据量比较少的时候很常用。 逻辑备份的优势： 备份恢复比较简单，例如 mysqldump 就是 MySQL 自带的备份工作，无需额外安装。恢复的时候可以直接使用 mysql 命令进行恢复。 可以远程备份和恢复，也就是说，可以在其他机器执行备份命令。 备份出来的数据非常直观，备份出来后，可以使用 sed grep 等工具进行数据提取或者修改。 与存储引擎无关，因为备份文件是直接从 MySQL 里面提取出来的数据

1 前言 数据恢复的前提的做好备份，且开启 binlog , 格式为 row 。如果没有备份文件，那么删掉库表后就真的删掉了， lsof 中还有记录的话，有可能恢复一部分文件，但若刚好数据库没有打开这个表文件，那就只能跑路了。如果没有开启 binlog ，那么恢复数据后，从备份时间点开始的数据都没得了。如果 binlog 格式不为 row ，那么在误操作数据后就没有办法做闪回操作，只能老老实实地走备份恢复流程。 2 直接恢复 直接恢复是使用备份文件做全量恢复，这是最常见的场景 2.1 mysqldump备份全量恢复 使用 mysqldump 文件恢复数据非常简单，直接解压了执行 gzip -d backup.sql.gz | mysql -u<user> -h<host> -P<port> -p 2.2 xtrabackup备份全量恢复 恢复过程 # 步骤一：解压（如果没有压缩可以忽略这一步） innobackupex --decompress <备份文件所在目录> # 步骤二：应用日志 innobackupex --apply-log <备份文件所在目录> # 步骤三：复制备份文件到数据目录 innobackupex --datadir=<MySQL数据目录> --copy-back <备份文件所在目录> 2.3 基于时间点恢复 基于时间点的恢复依赖的是 binlog 日志

简介 MySQL数据库的备份可以分为逻辑备份和物理备份，逻辑备份工具主要为：mysqldump而物理备份工具主要为：xtrabackup，两种备份方式各有优缺点 备份工具 mysqldump xtrabackup 优点 支持热备份和增量备份，需要磁盘空间小 支持热备份和增量备份，业务影响小，停机时间短， 缺点 业务影响大，停机时间长 所需磁盘空间大 使用场景 1)当数据量比较大而且对业务影响要比较小，若有足够空间保存备份数据则选择使用xtrabackup 2)当数据量小，也没有大量磁盘空间存储备份数据，则选择使用mysqldump 3)当停机时间要求较短时应到使用xtrabackup进行备份 前期准备 准备两台Centos7虚拟机，配置IP地址和hostname，同步系统时间，关闭防火墙和selinux，配置IP地址和hostname映射 hostname ip master 192.168.29.132 bak 192.168.29.138 安装MySQL数据库 注:本机安装的MySQL版本为8.0.17 #官网获取mysql的yum源 [root@master ~]# yum install mysql mysql-server -y [root@bak ~]# yum install mysql mysql-server -y master结点创建数据库并添加数据 mysql