一、数据库数据备份
1.1什么是数据备份
数据库数据备份是指将数据库中的数据和结构复制并保存到另一个存储位置，以防止数据丢失或损坏，并在需要时能够恢复。
核心目的：
-
防止数据丢失：硬件故障、人为误操作、软件缺陷、病毒攻击、自然灾害等可能导致数据丢失。
-
满足合规要求：很多行业法规要求数据必须备份并保留一定期限。
-
支持数据恢复：当数据损坏或丢失时，可以通过备份恢复到正常状态。
1.2 备份内容
-
数据本身：表中的记录
-
数据库结构：表、索引、视图、存储过程等
-
用户权限：账号、密码、权限配置
-
二进制日志：记录所有变更操作，用于增量恢复
1.3 数据库备份类型
1.3.1 逻辑备份
逻辑备份是对数据库逻辑组件的备份.表示为逻辑数据库结构 这种类型的备份适用于可以编辑数据值或表结构
从数据库的备份策略角度来看，备份又可分为完全备份、差异备份和增量备份
备份的常见方式：
| 类型 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| 完全备份 | 备份整个数据库 | 恢复简单 | 占用空间大，耗时长 |
| 增量备份 | 只备份上次备份后变化的数据 | 节省空间，速度快 | 恢复时需要依次应用多个备份 |
| 差异备份 | 只备份上次完全备份后变化的数据 | 恢复比增量简单 | 空间比增量大 |
1.3.2 物理备份
数据库备份可以分为物理备份和逻辑备份。物理备份是对数据库操作系统的物理文件（如数据文件、日志文件等）的备份。这种类型的备份适用于在出现问题的时候需要快速恢复的大型重要数据库。
物理备份又可以成为冷备份（脱机备份）、热备份（连接备份）和温备份
备份状态：
| 状态 | 说明 | 示例 |
|---|---|---|
| 冷备份 | 数据库关闭时备份 | tar 打包数据目录 |
| 热备份 | 数据库运行时备份（不停服务） | XtraBackup |
| 温备份 | 数据库只读时备份 | mysqldump（加锁读） |
常用备份工具：
-
**
mysqldump：**逻辑备份，导出 SQL 文件 -
**
mysqlbinlog：**二进制日志备份，用于增量恢复 -
**
XtraBackup：**物理热备份，支持 InnoDB -
**
cp/tar：**物理冷备份，直接拷贝数据文件
1.4 恢复方式：
-
完全恢复：将完全备份的数据全部恢复
-
时间点恢复：利用完全备份 + 二进制日志恢复到某个具体时间点
-
位置恢复：基于二进制日志的 position 跳过错误操作
一句话总结：数据库备份就是给你的数据上"保险"，保证在出问题时能找回数据。
总结：每次增量备份都是备份在上一次完全备份或者增量备份之后的数据，不会出现重复数据的情况，也不会占用额外的磁盘空间，恢复数据，需要按照次序恢复完全备份和增量备份的数据。
1.5 MySQL 日志体系与核心功能
1.5.1 核心日志类型与排障应用
错误日志定位异常：错误日志记录返回值为非零的操作报错现象，是排查数据库启动失败、连接异常等问题的首要依据。
慢查询日志性能优化：记录执行时间超过指定阈值（如 5 秒）的 SQL 语句，用于识别因网络、系统资源或 SQL 编写不合理导致的性能瓶颈。
日志开启机制：默认情况下部分日志（如二进制日志、中继日志）未开启，需在配置文件（my.cnf）中手动添加 `log-bin` 或 `relay-log` 参数才能启用。
1.5.2 二进制日志（Binlog）与中继日志的关键作用
主从复制数据同步：二进制日志记录主库的所有数据变更事件，中继日志接收并存储这些事件，从库通过重放中继日志实现数据同步。
数据恢复与容灾：当主库宕机时，可通过解析二进制日志手动执行 SQL 语句，将数据恢复到特定时间点，解决主从不一致问题。
数据备份基础：利用二进制日志记录的数据变更（如误删除操作），结合备份文件可实现数据的增量恢复。
1.6 物理备份策略与操作规范
1.6.1 数据文件存储结构与冷备份
文件系统级备份：MySQL 数据存储在 `/var/lib/mysql` 目录下，每个数据库对应一个子目录，物理备份即直接打包这些数据文件。
冷备份 适用场景：使用 `tar` 工具打包数据目录，需在数据库关闭状态下进行，适用于可接受停机时间的非 24 小时业务环境。
1.6.2 热备份与温备份的权衡
热备份无锁机制：使用 `mysqlhotcopy` 等工具，在数据库运行期间直接备份二进制日志**，不影响业务读写** ，但工具相对复杂。
温备份 锁表风险：使用**`mysqldump`**工具进行备份时，会对正在备份的表施加写锁，导致该表在备份期间无法写入，可能引发业务支付失败等问题。
1.7 逻辑备份策略与恢复逻辑
为解决全量备份占用空间大与数据丢失风险之间的矛盾
1.7.1 完全备份与增量备份对比
完全备份基础作用：定期（如每周或每半月）对整个数据库进行全量备份，作为恢复的基准点，但占用空间大且有大量重复数据。
增量备份高效策略：仅备份自上次完全备份或增量备份以来发生变化的数据，不产生重复数据，节省磁盘空间，但恢复过程需依赖所有增量链。
1.7.2 差异备份的应用逻辑
差异备份定位：每次备份自上次完全备份之后的所有变更数据，相比增量备份会产生重复数据，但恢复时仅需最近一次完全备份和一次差异备份，操作更简便。
二、MySQL 备份策略与全量备份实现
2.1 备份类型与策略划分
物理与逻辑备份区分 ：明确物理备份（冷备、温备、热备）与逻辑备份（mysqldump）的适用场景，其中逻辑备份重点关注备份的起始位置、数据内容及备份频次。
逻辑备份策略分类：区分完全备份（从零开始）、增量备份（基于上次备份）及差异备份（基于上次完全备份）的应用逻辑，强调增量备份仅备份修改过的数据。
2.2 mysqldump 全量备份实操
多维度备份语法：使用 `mysqldump` 备份所有数据库、指定单个/多个库、指定表及仅备份表结构（`-d` 选项）的命令语法。
数据恢复机制：通过删除表及数据
后恢复的演示，验证了 `mysqldump` 恢复逻辑为"先删除旧表再重建"，因此能应对表结构丢失或数据误删的场景。
定时任务自动化：介绍了通过 `crontab` 配置定时任务（如每日凌晨 12 点）自动执行备份脚本，并明确了 `crontab` 中分、时、日、月、周的时间参数定义。
2.3 二进制日志配置与解析
日志开启与参数配置：在 `my.cnf` 中配置 `log-bin` 开启二进制日志，并设置 `binlog_format=mixed` 及 `expire_logs_days=7`（保留 7 天）。
日志内容解析：讲解了使用 `mysqlbinlog` 配合 `--base64-output=decode-rows -v` 参数解码并查看二进制日志中的 SQL 语句、执行位置（Position）及时间节点。
2.4 增量备份实施与刷新机制
增量备份逻辑：定义了增量备份基于二进制日志文件，通过每日生成新的日志文件（如 mysql-bin.000001, .000002）来记录当天所有数据变更（增删改）。
日志刷新方式：推荐使用 `mysqladmin flush-logs` 命令手动刷新生成新日志文件，或通过配置 **`max_binlog_size`**达到大小阈值自动刷新，严禁在生产环境通过重启 MySQL 来刷新日志。
2.5 数据恢复与故障模拟
2.5.1 日志文件管理与查看
日志文件生成机制：演示了开启二进制日志后，所有 SQL 操作（如插入、删除）均被记录在 `mysql-bin` 系列文件中，且刷新日志会生成新文件，旧文件内容不再变更。
日志内容解析命令：介绍了使用 `mysqlbinlog --no-defaults --base64-output=decode-rows -v` 命令查看二进制日志的详细内容，建议将输出重定向至文件以便后续查阅。
2.5.2 基于位置点的断点恢复
精准恢复操作：通过 `--start-position` 和 `--stop-position ` 参数，仅恢复指定位置点之间的 SQL 语句，从而跳过误删除或错误插入的数据。
Commit 位置的重要性：强调恢复的停止位置必须位于 `COMMIT` 语句之后，否则事务不会被提交，导致数据恢复失败。
多文件恢复顺序：明确当操作分散在多个二进制日志文件中时，必须按文件生成顺序依次恢复，先恢复旧文件再恢复新文件。
2.5.3 基于时间点的恢复
时间格式要求：指出基于时间恢复时，必须使用完整的 `YYYY-MM-DD HH:MM:SS ` 格式，相较于位置点恢复更为繁琐且易错。
恢复策略建议：鉴于时间点恢复的复杂性，建议在实际生产环境中优先使用基于位置点的恢复方式。
2.6 自动化备份脚本编写实战
2.6.1 备份策略与架构设计
混合备份策略 ：要求实现"每三天一次全量备份，每天一次增量备份"的策略，全量备份使用 `mysqldump` ，增量备份基于二进制日志。
文件命名规范：备份文件需存储在指定目录（如 `/opt` 或 `/mysql/data`），并以时间戳或日期命名（如 `mysql_20240514.backup`）。
2.6.2 脚本实现逻辑
计划任务调度：推荐使用**`crontab`** 来调度备份脚本的执行频率，将全量备份和增量备份拆分为两个独立的脚本。
增量备份实现：增量备份脚本的核心逻辑包括刷新二进制日志（`flush logs`）和复制前一天的日志文件到备份目录。
三、逻辑备份类型与核心要素
3.1 完全备份与增量备份
完全备份（Full Backup）：起始位置为数据开头（从零开始），备份内容为所有数据，建议备份频次为3天、5天或一周一次。
增量备份（Incremental Backup）：起始位置为上一次备份的结束点，备份内容仅为修改过的数据，建议频次为1-3天一次，数据量少时可扩展至5天一次。
3.2 差异备份与应用场景
差异备份（Differential Backup）：起始位置为上一次的完全备份点，备份内容为修改过的数据，通常用于数据要求较高的环境。
策略选择建议：在实际生产环境中，通常推荐使用"完全备份+增量备份"的组合策略，差异备份使用相对较少。
3.3 冷备份与温备份实操演示
3.3.1 冷备份（Cold Backup）实施
操作流程：关闭数据库服务后，直接使用 `tar` 命令打包数据文件目录（如 `/usr/local/mysql/data` 或根据配置文件指定路径）。
恢复机制：恢复时直接解压打包文件至原路径即可，属于脱机备份方式。
3.3.2 温备份（Warm Backup）工具 mysqldump
工作原理：mysqldump 将数据库对象转化为 SQL 语句存储。备份过程中会对表加写锁（Lock Table Write），阻止写入操作，待数据导出为 Insert 语句后解锁。
备份逻辑：备份文件包含创建数据库（If Not Exists）、删除旧表（Drop Table If Exists）、重建表结构及插入数据的完整 SQL 逻辑。
3.4 mysqldump 命令格式详解
mysqldump 的四种核心命令格式，覆盖不同粒度的备份需求：
sql
mysqldump 备份逻辑： 把指定数据库内的表结构转化为sql、备份记录行时，锁住写入操作，把所有
的表记录转为SQL语句进行备份，然后解锁
mysqldump 备份单个或多个数据库
mysqldump -u -p --databases 库名1 库名2 > /opt/abc.sql
mysqldump 备份数据库所有子库+表
mysqldump -u -p --all-databases > /opt/all.sql
mysqldump 备份指定数据库中的单个/多个表
mysqldump -u -p 库名1 表名1 表名2 > /opt/all.sql
mysqldump 只备份表结构
在执行备份时，加上-d 的选项就可以只备份表结构3.4.1 数据库级备份
备份单个或多个库：使用 `--databases` 参数指定库名，可同时备份多个库的结构和数据。
备份所有库：使用 `--all-databases` 参数，无需指定具体库名，备份服务器上所有数据库。
3.4.2 表级与结构级备份
备份指定库中的表：直接指定库名和表名（无需 `--databases`），可备份单个或多个表。
仅备份表结构：使用 `-d` 参数，仅导出表结构而不包含数据，适用于项目模板迁移或环境初始化。
3..5 数据恢复与导入方法
3.5.1 命令行恢复方式
Source 命令：在 MySQL 客户端内部执行 `source /path/to/file.sql`，适用于交互式恢复。
重定向导入：使用 `mysql -u root -p < /path/to/file.sql` 命令，支持脚本化自动恢复。
执行 SQL 语句：利用 `mysql -u root -p -e "SQL Statement"` 在命令行直接执行 SQL，便于脚本编写。
sql
导入备份的数据（3种方式）
1、source /opt/school_szsxjd.sql (需要在数据库内部执行source 命令)
2、在命令行执行mysql -u -p [库名] < 备份文件.sql
3、使用工具导入 导出 比如navicat 3.5.2 图形化工具与远程备份
图形化工具支持：推荐使用 Navicat 等工具进行导入导出，支持多种文件格式（如 SQL、JSON、CSV）。
远程备份能力：mysqldump 支持远程连接备份，可在代理节点安装客户端工具对远程数据库进行备份。
总结
sql
是什么？干嘛的? 怎么做/用？
读写分离：
proxy 区分读写任务，给对应的数据库（地址池）
干嘛的？
从请求的类型这个维度来给master 分压（MySQL 读/写 存储数据）
怎么做的/用的？
amoeba 怎么做：
1、先把主从做好
2、安装amoeba 服务程序
3、配置访问用户 amoeba 123456 连接后端数据库的用户 test 123.com
配置读与写的任务，该分配给哪些后端的数据库服务器
4、验证
pkill -9 mysqld
kill -9 进程id
yum install -y mariadb mariadb-server
mysql有哪些日志：
二进制日志 中继日志 慢日志 错误日志 mysqld.log
⭐⭐日志与备份
是什么？干嘛的？有什么用?
错误日志： 提示信息
二进制 中继日志 ：
第一个：用于主从复制
第二个：可以手动把二进制日志中的语句执行在数据库中，用于"恢复"数据
第三个：用于备份 --> 然后恢复
mysql
10:00
create database
create table a
insert into a values(),(),()
alter table a add
update
10:02
delete from a where id=10;
备份：本质上，逻辑备份：看2个东西 ，1、备份的起始位置 2、备份的数据内容 3、备份频次
备份的类型：
物理备份：备份数据方式（冷备份 tar 、温备份 mysqldump 热备份 mysqlhotcopy）
温备份：mysqldump --》会锁定正在备份表格的写入操作，备份完才会解锁
逻辑备份：备份数据的频次以及如何备份数据
⭐完全备份： 从0开始备份、所有数据 （3天 5天 7天）
⭐增量备份： 从上一次的完备或增倍为起始，修改过的数据 （1~3天一次）
差异备份： 从上一次的完备作为起始，修改过的数据 （在数据要求比较高的环境使用）
szsxjd 数据库
info1
info2
mysqldump 备份逻辑： 把指定数据库内的表结构转化为sql、备份记录行时，锁住写入操作，把所有
的表记录转为SQL语句进行备份，然后解锁
mysqldump 备份单个或多个数据库
mysqldump -u -p --databases 库名1 库名2 > /opt/abc.sql
mysqldump 备份数据库所有子库+表
mysqldump -u -p --all-databases > /opt/all.sql
mysqldump 备份指定数据库中的单个/多个表
mysqldump -u -p 库名1 表名1 表名2 > /opt/all.sql
mysqldump 只备份表结构
在执行备份时，加上-d 的选项就可以只备份表结构
导入备份的数据（3种方式）
1、source /opt/school_szsxjd.sql (需要在数据库内部执行source 命令)
2、在命令行执行mysql -u -p [库名] < 备份文件.sql
3、使用工具导入 导出 比如navicat
核心是备份，备份的类型 备份的策略
物理备份：冷备、温备、热备
逻辑备份: 看2个东西 ，1、备份的起始位置 2、备份的数据内容 3、备份频次
⭐完全备份： 从0开始备份、所有数据 （3天 5天 7天）
⭐增量备份： 从上一次的完备或增备为起始，只备份修改过的数据 （1~3天一次）
差异备份： 从上一次的完备作为起始，只备份修改过的数据 （在数据要求比较高的环境使用）
温备份
使用mysql 自带的备份工具
mysqldump -uroot -pabc123
增量备份：
依靠：二进制日志文件
时间节点14:00：
开启二进制日志
执行sql：
二进制日志文件中
at 219
create database
at 310
create table
insert into
insert into
alter table intext add
update intext set
update intext set
二进制日志--记录的mixed混合模式，只看3个内容：
① 执行的SQL语句
② 执行SQL的执行位置（起始到结束的 at 位置 position）
③ 执行SQL的时间节点（起始到结束的时间区间）
查看二进制日志文件的命令：
mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000001 > /opt/mysql-bin.report
恢复数据的：
mysqlbinlog --no-defaults --start-position='2162' /var/lib/mysql/mysql-bin.000001 | mysql -uroot -p
#表示数据从2162这个位置开始恢复/开始导入数据库
断点恢复
mysqlbinlog --no-defaults --start-position='2162' --stop-position='2366' /var/lib/mysql/mysql-bin.000001 | mysql -uroot -p
#表示的是 只恢复从2162~2366之间的SQL语句操作
crontab
cp
刷新二进制日志 mysqladmin -u -p flush-logs 部分补充
sql
一、读写分离架构与核心方法论
读写分离架构解析：明确了读写分离的本质是通过 Proxy 代理层（如 Amoeba、MyCat）区分读写任务，将读请求分发至 Slave 节点，从而减轻 Master 节点的压力。
主从复制原理回顾：详细阐述了主从复制的核心流程，即基于二进制日志（Binary Log）和中继日志（Relay Log），通过 Dump、I/O、SQL 三个线程实现数据同步。
高并发下的数据一致性问题：指出在高并发写入场景下（如百万级数据），主从同步存在延迟，若 Master 在数据未完全同步时宕机，会导致从库数据不完整。
二、故障排查与运维实战
1. 标准排查流程与工具
日志优先原则：确立了"遇错先看日志"的排查逻辑，通过 `grep` 过滤错误信息，结合上下文（Context）定位问题根源，而非盲目修改配置文件。
进程管理工具对比：详细区分了 `kill -9` 与 `pkill` 的区别。`kill -9` 针对特定 PID 强制终止进程，而 `pkill` 可根据服务名批量终止相关进程（如 `pkill mysql`）。
环境变量与编码问题：指出 JDK 版本、中文编码及虚拟机环境本身可能导致的偶发性问题，建议在排查无果时可尝试更换虚拟机环境。
2. 典型错误修复
UUID 冲突处理：针对克隆虚拟机导致的 MySQL 启动失败，指导学员修改 `/var/lib/mysql/auto.cnf` 文件中的 `server-uuid`，确保集群内各节点 UUID 唯一。
脏数据冲突解决：针对主从同步报错"数据库已存在"，分析指出这是从库提前执行了建库语句导致的"脏数据"冲突，解决方案是删除从库已有数据后重新同步。
服务安装依赖确认：纠正了仅安装 `mariadb` 无法启动服务的问题，明确必须同时安装 `mariadb-server` 包才能获取完整的服务管理能力。
配置文件语法错误：针对 Amoeba 启动失败，指出 XML 配置文件中使用了错误的注释语法（如 `<!--` 未闭合），需检查标签闭合情况。
三、MySQL 日志体系预告
MySQL 的日志分类：
错误日志（Error Log）：记录了 MySQL 服务启动、运行或停止时出现的错误信息，是排查服务异常的首选日志。
二进制日志（Binary Log）：记录了所有对数据库执行更改的语句，是主从复制的核心基础。
通用查询日志（General Query Log）：记录了所有客户端连接请求和执行的 SQL 语句，用于审计或分析查询行为。