关于 MariaDB 系列其他文章的传送门
一、关于数据库的备份和恢复¶
1. 备份的概念¶
为什么要备份？¶
一个好的备份恢复策略，帮助应对各种灾难，比如硬件故障（冗余）、软件故障（bug）、自然灾害、黑客攻击、误操作等等。
第一步是备份，把数据存储一个副本；但是注意备份后原始数据是在持续改变的；
重要的是第二步–恢复，这个过程就是把副本应用到线上系统，就算数据备份的再好，如果无法恢复回去也是竹篮打水一场空；注意仅能恢复至备份操作那一时刻的数据状态，备份后持续在改变的数据还是无法恢复；
所以备份策略应该注意：
- 能容忍最多丢失多少数据；
- 恢复数据需要在多长时间内完成；
- 需要恢复哪些数据；
- 要经常做恢复演练，可以测试备份的可用性，增强恢复操作效率；
备份的数据集的范围¶
- 全量备份：完整的备份整个数据集；
- 部分备份：只备份数据集的一部分，比如某个表；
- 差异备份：仅备份自上一次全量备份后发生变化的部分数据；比如周日做了全量，周一就备份有差异的数据也就是从周日到周一的，周二时备份从周日到周二，周四时备份从周日到周四；
- 优点是恢复速度快，恢复时只需要恢复一次即可；缺点是容量大，备份慢；
- 线上业务建议使用这种，以空间换时间，恢复的越快损失越小。
- 增量备份：仅备份自上一次全量备份或增量备份后发生变化的数据；比如周日做了全量，周一就备份增长了的数据也就是从周日到周一的，和差异不一样的是，周二时只备份从周一到周二的即可，周三只备份从周二到周三的即可；
- 优点是备份容量小，备份快；缺点是恢复时要一天一天的恢复，速度慢。
备份数据集的方式有两种¶
- 物理备份：直接复制数据文件进行的备份；
- 逻辑备份：从数据库导出数据另存在一个或多个文件中；
根据数据服务是否在线，有三种备份状态¶
- 热备：读写操作均可进行的状态下所做的备份；
- 温备：可读但不可写状态下进行的备份；
- 冷备：读写操作均不可进行的状态下所做的备份；
备份需要考虑因素¶
- 锁定资源多长时间？
- 备份过程的时长？
- 备份时的服务器负载？
- 恢复过程的时长？
要注意数据是时时刻刻在发生变化的，举个例子：
周日 3 点时做了全量备份，到周一的 3 点又做了增量备份，但是 6 点时数据库宕机了，那么从备份只能恢复到周一的 3 点，而从 3 点都 6 点的数据就全没了。
这时就需要使用二进制文件来填补了，可用的备份策略：
- 全量+差异 + binlogs
- 全量+增量 + binlogs
2. 备份工具¶
mysqldump：MariaDB 服务自带的备份工具；属于逻辑备份工具；- 支持完全、部分备份；不支持差异和增量；
- 对 InnoDB，支持热备；
- 对 MyISAM，支持温备；
Innobackup/xtrabackup：由 Percona 提供，开源工具，支持对 InnoDB 做热备，属于物理备份工具；- 支持完全备份、部分备份、增量备份、差异备份；功能强大，建议使用 xtrabackup。
如果想学习 xtrabackup 的使用方法，建议看这篇文章，非常强大。
mysql/mariadb知识点总结（29）
3. mysqldump 使用方法¶
mysqldump 的备份方式是先使用 select 查询，然后转成 CREATE、INSERT 等 SQL 语句并保存在文件里。属于逻辑备份。支持完全备份、部分备份；
mysqldump -uroot -hlocalhost --all-databases > back.sql：备份所有库；mysqldump -uroot -hlocalhost --databases db1,db2 > back.sql：备份指定一个或多个数据库；mysqldump -uroot -hlocalhost --databases db1 --tables tbl1 tbl2 > back.sql：备份指定的表:mysqldump -uroot -proot --databases db1 --tables tbl1 --where='id=1' > back.sql：备份单个表中所有的目标对象。
InnoDB 存储引擎：支持温备和热备；
--single-transaction：通过将导出操作封装在一个事务内来使得导出的数据是一个一致性快照，基于此快照执行备份；
如果是 MyISAM 存储引擎：支持温备，所以备份时要锁定表；
-x, --lock-all-tables：锁定所有库的所有表，读锁；-l, --lock-tables：锁定指定库所有表；
其它选项：
-R, --routines：存储过程和存储函数；--triggers：备份指定库的触发器；-E, --events：备份事件调度器。--master-data[=#]：该选项在备份 MASTER 时将 binlog 的字节位置和文件名追加到输出文件中。使得构建 SLAVE 时知道应当从哪个坐标开始复制。1：当 # 为 1 时，记录为CHANGE MASTER TO语句，此语句不被注释，使得 SLAVE 知道应当从哪个坐标开始复制；2：当 # 为 2 时，记录为CHANGE MASTER TO语句，此语句被注释，使得 SLAVE 知道应当从哪个坐标开始复制；
--flush-logs：锁定表完成后，即进行日志刷新操作；即滚动一个新的日志文件。
备份示例：
1 | mysqldump -uroot -hlocalhost --all-databases -x -R --triggers -E --master-data=2 --flush-logs > /root/backup.sql |
恢复示例：
1 | mysql -uroot -hlocalhost < backup.sql |
二、关于 TIDB 数据库¶
实际上 MariaDB 在规模特别大的环境中，还是会有很多很多的问题，如果不是特别专业的 DBA，与其一直折腾分片、分表、高可用、数据一致性等等等的问题，不如使用 TIDB。
TIDB 是国人自己研发的分布式数据库，由 Ping CAP 公司研发，是一个 K/V 类型的分布式存储，但是面向用户时是兼容所有 MySQL 协议的。
目前已经有例如美团这样的公司在大规模使用了，可见还是很有发展前景的，详情可以查看：
新一代数据库 TiDB 在美团的实践
说到分布式协作服务，最著名的就是 Paxos 协议，这是分布式协作服务元祖协议，但是非常非常复杂。
后来就有了简装版的分布式协作服务 Raft 协议，而 TIDB 就是使用了实现此种协议的 Etcd 来实现分布式协作的。
关于 Raft 一致性算法论文的中文翻译
三、innoDB 存储引擎的相关优化参数¶
建议使用：
innodb_buffer_pool_size：定义整个数据库的索引、数据、插入数据时的缓冲区，默认为 128MB；当服务器是 Mysql 专用时时，应该尽量调大，可以使用 70-80%。innodb_buffer_pool_instances：定义缓冲区的分片数量；当缓存区比较大时，进行分片管理，可以减少内存碎片。innodb_flush_logs_at_trx_commit：每当有事务提交时，定义如何将缓冲区的事务日志同步至磁盘中，以保证事务的安全性。建议同时关闭单语句事务 autocommit，而后将此值设置为 1 或 2。0：每一秒，将 log buffer（内存）同步一次至 log file（事务日志）；且同时将 log file 同步到 data file（数据文件）；1：每次提交时，将 log buffer 同步至 log file，且同时将 log file 同步到 data file；偏安全性高；2：每次提交时，将 log buffer 同步至 log file，但不会将 log file 同步到 data file；偏性能好；
innodb_file_per_table=ON：每表使用单独的表空间；innodb_read_io_threads,innodb_write_io_threads：文件读写的 I/O 线程数；可根据并发量和 CPU 核心数适当调整；innodb_open_files：InnoDB 可打开的文件数量上限；innodb_flush_method：定义用户提交时数据的刷写方法；innodb_thread_concurrency：InnoDB 自己的工作线程，建议等于自己的 CPU 核心数；skip_name_resolve：跳过主机名解析；max_connections：MariaDB 最大连接数，可适量调大；
