## FontMagic

一个开源字体（ttf、woff、woff2）处理软件，可以在 macOS、Windows 平台使用。

FontMagic拥有4大核心功能：

- 解析字体文件的所有unicode及字形，可以通过快捷键将选中的字形以svg字符串的形式进行拷贝。可以一键导出选择的所有字形
- 可以对字体文件进行过滤，只保留你需要的字符
- 可以对字体文件的格式进行转换，可以在ttf、woff、woff2三种格式中互相转换
- 可以快速获取字体文件的base64编码，仅仅需要点击一次按钮

## 下载地址

FontMagic：[https://arayofsunshine.dev/zh-Hans/fontmagic](https://arayofsunshine.dev/zh-Hans/fontmagic)


FontMagic-开源字体ttf、woff、woff2处理软件 支持macOS、Windows平台

## SEEK FLAG

是一个在线世界国旗大全网站，提供高质量世界国旗SVG和PNG格式免费下载，可以按照各大洲和板块查找世界国旗，也可以搜索关键字，而且还提供国旗颜色十六进制、RGB和CMYK代码，可用于Web HTML/CSS等等，非常不错的世界国旗大全素材网站。

## 网站地址

SEEK FLAG：[https://seekflag.com/](https://seekflag.com/)


SEEK FLAG-在线世界国旗大全SVG PNG格式免费下载

## 备份

### mysqldump

是逻辑备份工具，备份的是SQL语句。

备份方式:

- InnoDB表可采取快照备份的方式，开启一个独立事务，获取当前最新的一致性快照。将快照数据，放在临时表中，转换成SQL，保存到sql文件中
- 非InnoDB表需要锁表备份。触发FTWRL，全局锁表。转换成SQL，保存到sql文件中

备份参数：

- -A 全备：mysqldump -A > /backup/full.sql
- -B 备份1或多个库：mysqldump -B test1 test2 > /backup/db.sql

备份单表或多表：mysqldump database_name table1 table2 > /backup/tab.sql

加不加-B参数的区别：

- 加-B参数，例如，-B test备份的是：create database test;use test;
- 没加-B参数，备份的是表，在应用时如果test库不存在，需要手工创建，并且use到test库下再恢复

备份高级参数：

- 
--master-data，功能：

- 备份时自动记录binlog信息
- 自动锁表和解锁
- 配合--single-transaction可以减少锁表时间
- --master-data=1会将change master语句写入dump文件中，--master-data=2会将change master 语句写入dump文件中，但是会被注释掉

- -R：备份存储过程和函数
- -E：备份事件
- --triggers：备份触发器
- --max_allowed_packet=128M：控制备份时传输数据包大小

每天全备：

    mysqldump -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M > /backup/full_`date +%F`.sql

mysqldump小结：

- 优点：可读性较强，压缩比，节省空间，不需要下载安装
- 缺点：备份时间较长，恢复时间也长
- 数据量较少100G以内，建议使用mysqldump

从mysqldump全备中获取库和表备份：

    # 获得表结构
    sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `city`/!d;q' full.sql >createtable.sql
    # 获得INSERT INTO语句
    grep -i 'INSERT INTO `city`'  full.sqll >data.sql &
    # 获取单库备份
    sed -n '/^-- Current Database: `world`/,/^-- Current Database: `/p' all.sql >world.sql

### Percona Xtrabackup（XBK）

是物理备份工具，支持全备和增量备份。有两个主要的工具：xtrabackup、innobackupex

- xtrabackup只能备份InnoDB和XtraDB两种数据表
- innobackupex则封装了xtrabackup，同时可以备份MyISAM数据表

InnoDB表：
热备份：业务正常发生时，影响较小的备份方式

- checkpoint，将已提交数据页刷新到磁盘，记录一个LSN
- 拷贝InnoDB表相关文件(ibdata1、frm、ibd...)
- 备份期间产生新数据变化的redo也会被备份走

非InnoDB表：
温备份：锁表备份

- FTWRL，触发全局锁
- 拷贝非InnoDB表数据
- 解锁

再次统计LSN，写入到专用文件，记录二进制日志位置，所有备份文件统一存放在一个目录下。

#### 全量备份

命令：

    innobackupex --no-timestamp /data/xbk/full_`date +%F`

--no-timestamp：表示不创建时间戳目录来存储备份，而是指定备份文件夹

全备恢复：

- 准备备份：`innobackupex --apply-log /data/xbk/full_*/`，redo前滚，undo回滚，模拟CSR过程
- 数据恢复：`cp -a /data/xbk/full_*/* /data/3306/`，前提是被恢复目录/data/3306/为空，被恢复数据库实例是关闭
- 数据授权：chown -R mysql.mysql /data/*
- 启动数据库

#### 增量备份

增量备份无法单独恢复，必须依赖于全备进行恢复，所有增量必须要按顺序合并到全备中。

增量备份命令：innobackupex --no-timestamp --incremental --incremental-basedir=/backup/full  /backup/inc1

--incremental-basedir：增量备份基目录（上次全量备份路径）

恢复过程，备份整理（apply-log）+ 合并备份（full+inc1+inc2）：

- 基础全备整理：innobackupex --apply-log --redo-only /backup/full
- 合并inc1到full中：innobackupex --apply-log --redo-only --incremental-dir=/backup/inc1 /backup/full
- 合并inc2到full中（最后一个增量不用加--redo-only）：innobackupex --apply-log --incremental-dir=/backup/inc2 /backup/full
- 最后一次全备整理：innobackupex --apply-log /backup/full

截取binlog并恢复：

- 找到起点：cat /backup/inc2/xtrabackup_binlog_info
- 找到终点：文件末尾
- position截取：mysqlbinlog --skip-gtids --start-position=219 binlog文件 >/tmp/binlog.sql
- 临时关闭日志：set sql_log_bin=0;
- 导入SQL语句：source /tmp/bin.sql;
- 恢复日志：set sql_log_bin=1;

source命令执行sql脚本优点：可支持大文件。

## 恢复

恢复全备：source /backup/full.sql

截取binlog：

- 找到起点：`grep "\-- CHANGE MASTER TO" /backup/tab.sql`
- 找到终点：show binlog events in 'binlog文件';
- position截取：mysqlbinlog --skip-gtids --start-position=219 --stop-position=335 binlog文件 >/tmp/binlog.sql

恢复binlog：

- 临时关闭日志：set sql_log_bin=0;
- 导入SQL语句：source /tmp/bin.sql;
- 恢复日志：set sql_log_bin=1;


MySQL备份与恢复

## 错误日志

记录MySQL从启动以来，所有的状态、警告、错误。为我们定位数据库问题，提供帮助。

查看数据库日志路径：select @@log_error;

默认是开启状态，文件位于/datadir/hostname.err，也可以通过my.cnf自定义文件位置：log_error=/tmp/mysql.log，重启MySQL生效。

## 二进制日志

作用是记录数据库变化（DDL，DCL，DML）性质的日志，是逻辑层性质日志。应用在数据恢复，主从复制中。

8.0版本以前，默认没有开启，建议生产开启，且一定要和数据盘分开。

配置方法：vim /etc/my.cnf

    server_id=6 # 主机编号。主从中使用，5.7以后开binlog要加此参数
    log_bin=/data/binlog/mysql-bin # 日志存放目录+日志名前缀，例如mysgl-bin.000001、mysq1-bin.000002
    sync_binlog=1 # binlog日志刷盘策略，1是每次事务提交立即刷写binlog到磁盘
    binlog_format=row # binlog记录格式为row模式

### 记录内容

bin1og是SQL层的功能，记录变更的SQL语句，不记录查询语句。

记录SQL语句种类

- DDL：原封不动记录当前DDL语句
- DCL：原封不动记录当前DCL语句
- DML：只记录已经提交的事务DML（insert、update、delete）

DML三种记录方式，受binlog_format参数影响，建议使用row记录模式：

- statement（statement based replication, SBR）5.6默认：以语句模式原封不动记录当前DML
- row（row based replication, RBR）5.7 默认：以行模式记录数据行的变化，用户看不懂，需要工具分析
- mixed（mixed based replication, MBR）：混合模式，以上两种模式的混合

🤔SBR与RBR模式对比？

- statement：可读性较高，日志量少，不够严谨
- row：可读性很低，日志量大，足够严谨

### 记录单元

事件是二进制日志的最小记录单元。对于DDL、DCL，一个语句就是一个event，对于DML语句来讲，只记录已提交的事务。

例如以下列子，就被分为了4个event：

            position（start-stop）
    begin;  120 - 340
    DML1    340 - 460
    DML2    460 - 550
    commit; 550 - 760

位置号（position）的作用是为了方便截取事件。

事件组成：

- 事件开始标识：at 194
- 事件内容
- 事件结束标识：end_log_pos 254

### 查看日志

查看是否开启：select @@log_bin;

查看文件保存路径：select @@log_bin_basename;

查看目前有几个日志文件：show binary logs;

查看当前使用的binlog：show master status;

查看二进制日志事件：show binlog events in 'binlog文件';

事件查看：mysql -e "show binlog events in 'binlog文件'" | grep DROP

内容查看：mysqlbinlog 'binlog文件' >/tmp/a.sql

翻译数据行：mysqlbinlog --base64-output=decode-rows -vvv 'binlog文件' >/tmp/b.sql

### 恢复日志

滚动一个新日志：flush logs; 或 mysqladmin flush-logs 或 重启数据库

截取二进制日志：mysqlbinlog --start-position=219 --stop-position=335 'binlog文件' >/tmp/c.sql

恢复日志：

1. 临时关闭日志：set sql_log_bin=0;
2. 导入SQL语句：source /mnt/bin.sql
3. 恢复日志：set sql_log_bin=1;

### 日志删除

自动删除机制：select @expire_logs_days;
默认是0，代表永不删除，单位是天。设置多少天合适：一次全备份周期7+1天，生产环境一般建议，最少2个全备份周期+1，即15天。

手工删除，例如，删除某个日志之前的日志（正在使用的日志文件不能清理）：purge binary logs to 'mysql-bin.000005';

删除某个时间点之前的日志：purge binary logs before '2024-01-01 22:11:11';

全部清空：`reset master;`，比较危险，在主库执行此操作，主从必宕。

### GTID

5.6版本新加特性，5.7 8.0中做了加强。5.6中不开启，没有这个功能，5.7中GTID即使不开也会有自动生成。

GTID（Global Transaction ID）是对于一个已提交事务的编号，并且是一个全局唯一的编号。GTID组成：server_uuid:transaction_id。

开启GTID，vim /etc/my.cnf：

    gtid-mode=on
    enforce-gtid-consistency=true

基于GTID截取日志：mysqlbinlog --skip-gtids --include-gtids='d980595d-c934-11e9-bbfc-000c29d70b6d:1-2' mysql-bin.000003 mysql-bin.000004 >/tmp/gtid.sql

GTID幂等性：在基于GTID进行数据恢复时，如果在截取GTID记录时没加--skip-gtids选项，那么，在使用source命令导入sql文件进行数据恢复时，会发现数据并没有恢复成功。这是因为当前系统中已经有了这些GTID记录，而基于幂等性机制，已经有的GTID是不会进行操作的，既然不会进行操作，那自然数据恢复就不会成功了。

## 慢日志

记录了所有执行时间超过指定参数（long_query_time，单位：秒，默认10秒）的所有SQL语句的日志。

查看慢日志开关状态：`select @@slow_query_log;`，默认没有开启，需要修改配置文件/etc/my.cnf：

    # 开启慢日志查询开关
    slow_query_log=1
    设置慢查询时间阈值为2秒
    long_query_time=2

配置完毕之后，重启MySQL服务器，查看慢日志文件（查看文件存放位置：select @@slow_query_log_file;）中记录的信息。

查看慢日志文件尾部实时输出内容：tail -f localhost-slow.log

查看不走索引的语句记录：select @@log_queries_not_using_indexes;

### 慢语句分析

命令：mysqldumpslow -s c -t 5 慢日志文件：

- -s sort，表示按照何种方式排序，c、t、l、r分别按照记录次数、时间、查询时间、返回记录数来排序，ac、at、al、ar表示相应的倒序
- -t top，即返回前面多少条数据


MySQL日志管理

InnoDB规划了26种行格式，分别对应26种动物，首字母由A至Z：Antelope, Barracuda, Cheetah, Dragon, Elk, Fox, Gazelle, Hornet, Impala, Jaguar, Kangaroo, Leopard, Moose, Nautilus, Ocelot, Porpoise, Quail, Rabbit, Shark, Tiger, Urchin, Viper, Whale, Xenops, Yak, Zebra。

目前InnoDB支持的行格式只有Antelope, Barracuda。而Antelope又具体细分为Redundant和Compact，Barracuda也具体细分为Dynamic和Compressed。

可以在创建或修改表的语句中指定行格式：

    CREATE TABLE 表名 (列的信息) ROW_FORMAT=行格式名称
    ALTER TABLE 表名 ROW_FORMAT=行格式名称

## Compact

一条完整的记录可以被分为`记录额外信息`和`记录真实数据`两大部分。

### 记录额外信息

记录额外信息是服务器为了描述这条记录而不得不额外添加的一些信息，这些额外信息分为3类，分别是`变长字段长度列表`、`NULL值列表`和`记录头信息`。

#### 变长字段长度列表

在Compact行格式中，把所有变长字段的真实数据占用字节长度都存放在记录的开头部位，从而形成一个变长字段长度列表，各变长字段数据占用字节数（十六进制表示）按照列的顺序**逆序**存放。

用1个还是2个字节来表示真实数据占用字节数，InnoDB有它的一套规则：

1. 假设某个字符集中表示一个字符最多需要使用的字节数为`W`，也就是使用`SHOW CHARSET`语句结果中的`Maxlen`列，比方说`utf8`字符集中`W`就是`3`，`gbk`字符集中`W`就是`2`，`ascii`字符集中`W`就是`1`
2. 对于变长类型`VARCHAR(M)`来说，这种类型表示能存储最多`M`个字符（注意是字符不是字节），所以这个类型能表示的字符串最多占用的字节数就是`M × W`
3. 假设实际存储的字符串占用字节数是`L`

所以确定使用1个字节还是2个字节表示真正字符串占用字节数规则就是这样：

- 如果`M×W <= 255`，那么使用1个字节来表示真正字符串占用字节数
- 
如果`M×W > 255`，则分为两种情况：

- 如果`L <= 127`，则用1个字节来表示真正字符串占用字节数
- 如果`L > 127`，则用2个字节来表示真正字符串占用字节数

InnoDB在读记录的变长字段长度列表时会先查看表结构，如果某个变长字段允许存储的最大字节数大于255时，该怎么区分它正在读的某个字节是一个单独的字段长度还是半个字段长度呢？InnoDB使用该字节的第一个二进制位作为标志位：如果该字节的第一个位为0，那该字节就是一个单独的字段长度（使用一个字节表示不大于127的二进制的第一个位都为0），如果该字节的第一个位为1，那该字节就是半个字段长度。

需要注意的是，变长字段长度列表中只存储值为**非NULL**的列内容占用长度，值为**NULL**的列长度是不储存的。

对于**CHAR(M)**类型的列来说，当列采用的是定长字符集时，该列占用字节数不会被加到变长字段长度列表，而如果采用变长字符集时，该列占用字节数也会被加到变长字段长度列表。

最后，并不是所有记录都有这个变长字段长度列表部分，比方说表中所有列都不是变长数据类型，这一部分就不需要有。

#### NULL值列表

如果把NULL值都放到`记录真实数据`中存储会很占地方，所以Compact行格式把这些值为NULL的列统一管理起来，存储到NULL值列表中，它的处理过程是这样的：

1. 首先统计表中允许存储NULL的列有哪些
2. 如果表中没有允许存储NULL值的列，则NULL值列表也不存在，否则将每个允许存储NULL的列对应一个二进制位，二进制位按照列的顺序**逆序**排列，二进制位表示的意义：值为`1`时，代表该列的值为`NULL`；值为`0`时，代表该列的值不为`NULL`
3. MySQL规定NULL值列表必须用整数个字节的位表示，如果使用的二进制位个数不是整数个字节，则在字节的高位补`0`。如果一个表中有9列允许为NULL，那这个NULL值列表部分就需要2个字节来表示

#### 记录头信息

由固定的5个字节组成，即40个二进制位，不同的位代表不同的意思。这些二进制位代表的详细信息如下：
名称大小（bit）描述预留位11没有使用预留位21没有使用delete_mask1标记该记录是否被删除min_rec_mask1B+树每层非叶子节点中的最小记录都会添加该标记n_owned4表示当前记录拥有的记录数heap_no13表示当前记录在记录堆的位置信息record_type3表示当前记录的类型，0表示普通记录，1表示B+树非叶子节点记录，2表示最小记录，3表示最大记录next_record16表示下一条记录的相对位置
`delete_mask`这个属性标记当前记录是否被删除，值为0代表记录并没有被删除，为1代表记录被删除掉了。这些被删除的记录之所以不立即从磁盘上移除，是因为移除它们之后把其他的记录在磁盘上重新排列需要性能消耗，所以只是打一个删除标记而已，所有被删除掉的记录都会组成一个所谓的`垃圾链表`，在这个链表中的记录占用的空间称之为所谓的`可重用空间`，之后如果有新记录插入到表中的话，可能会把这些被删除记录占用的存储空间覆盖掉。

`heap_no`这个属性表示当前记录在记录堆的位置信息，InnoDB会自动给每个页里边儿加了两个记录，由于这两个记录并不是我们自己插入的，所以有时候也称为伪记录或者虚拟记录。这两个伪记录一个代表最小记录（heap_no值为0），一个代表最大记录（heap_no值为1）。

`next_record`非常重要，它表示从当前记录真实数据到下一条记录真实数据的地址偏移量。比方说第一条记录的next_record值为32，意味着从第一条记录真实数据的地址处向后找32个字节便是下一条记录真实数据。

### 记录真实数据

记录真实数据除了自己定义的列数据外，MySQL会为每个记录默认添加一些列（也称为隐藏列），具体如下：
列名是否必须占用空间描述row_id否6字节行ID，唯一标识一条记录transaction_id是6字节事务IDroll_pointer是7字节回滚指针
实际上这几个列的真正名称是：DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR。

需要注意的是，变⻓字符集的CHAR(M)类型列要求⾄少占⽤M个字节，⽽VARCHAR(M)却没有这个要求。

## Redundant

该行格式是MySQL 5.0之前使用的一种行格式，也就是说它已经非常老了，这里就不介绍了。

## 行溢出

对于VARCHAR(M)类型的列最多可以占用65535个字节，其实这个65535除了列本身的数据之外，还包括一些其他数据（storage overhead）。如果该VARCHAR类型列没有NOT NULL属性，那最多只能存储`65532`个字节数据，因为真实数据长度可能占用2个字节，NULL值标识需要占用1个字节。

在Compact和Reduntant行格式中，对于占用存储空间非常大的列，在记录真实数据处只会存储该列的一部分数据，剩余数据分散存储在几个其他页中，然后记录真实数据处用20个字节存储指向这些页的地址，从而可以找到剩余数据所在的页。这个过程也叫做行溢出，存储剩余数据所在页也被称为溢出页。

发生行溢出的临界点是什么呢？也就是说在列存储多少字节数据时会发生`行溢出`？其实，不用关注这个临界点是什么，只要知道如果一个行中存储了很大的数据时，可能发生行溢出的现象就行了。

## Dynamic和Compressed行格式

MySQL 5.7默认行格式就是Dynamic，这俩行格式和Compact行格式挺像，只不过在处理行溢出数据时有点儿分歧，它们不会在记录真实数据处存储字段真实数据的前`768`个字节，而是把所有字节都存储到其他页面中，只在记录真实数据处存储其他页面的地址。

Compressed和Dynamic不同的一点是，Compressed行格式会采用压缩算法对页面进行压缩，以节省空间。


MySQL存储引擎InnoDB行格式

这里是 aboss.top 的自留地。写了十几年野路子代码，攒了些摸爬滚打的经验，做成系列课程慢慢讲；也留了一小块地方，记记代码之外的胡思乱想。