原文: http://blog.gqylpy.com/gqy/465
置顶：来自一名75后老程序员的武林秘籍——必读（博主推荐）
来，先呈上武林秘籍链接：http://blog.gqylpy.com/gqy/401/
你好，我是一名极客！一个 75 后的老工程师！
我将花两分钟，表述清楚我让你读这段文字的目的！
如果你看过武侠小说，你可以把这个经历理解为，你失足落入一个山洞遇到了一位垂暮的老者！而这位老者打算传你一套武功秘籍！
没错，我就是这个老者！
干研发 20 多年了！我也年轻过，奋斗过！我会画原理图，会画 PCB，会模拟，会数字！玩过 PLC，玩过单片机，会用汇编，会用 C！玩过 ARM，比如 PLC，STM32，和时下正在起飞的 NXP RT1052！搞过 DSP，比如 TMS320F28335！搞过 FPGA，不管 Xilinx 还是 Altera，也不管是 Verilog 还是 VHDL，或者直接画数字电路图！我懂嵌入式系统，比如 uCOS 和 Linux！我懂开源的硬件，比如 Arduino 和树莓派!我也搞软件，学了一堆上位机的语言C#，JAVA，Python，Kotlin，Swift！会写爬虫工具，又自学写APP，不管Android 还是 IOS！
可是这一切有什么用呢？土鸡瓦狗！不值一提！干技术的永远就是最苦逼的那个人！
我相信看到这里的你，应该是个 IT 圈的人！或许是个学生，在学习某个技能！或者是个初入职场的年轻人，在啃某个技术！或者是个工程师，被项目困住，想找个资料快速突破阻碍！反正不管怎么样，你们都不会是泛泛之辈，不可能轻易交出智商税！
所以我把这份资料放进我的收费资源里，以证明接下去我要跟你讲的这本武功秘籍是可以真真实实的帮你赚到钱的！
我不知道叫它什么好，我把它写的像武林秘籍！所以我姑且叫它《武林秘籍》或者叫《赚钱秘籍》!
《武林秘籍》里封装了一个本人近期创造的一个可以一劳永逸的赚钱方法！你可以理解为躺着赚钱，或者挂机赚钱！请你放心，不是让你去违法！
我是一个IT男，从来不忽悠别人，这是我做人的原则。若此举能帮助你付起房子首付与月供，减轻一些目前高房价的压力，何乐而不为呢！
我提取里边几个要点：
- 将你手里有的资源按照说明书一步一步完成所有动作就可以躺着赚钱。
- 你不可能不劳而获，但是用这个方法确实是可以一劳永逸!
- 我用业余时间操作这个项目三个月，现在每天稳定收入300+。
- 里边会告诉你哪些是资源，怎么源源不断的获取资源。
- 里边会告诉你怎么获取爆炸的流量。
- 里边会告诉你很多黑技能（不是干坏事）。
- 总之，里边字字如金，有些东西我不告诉你可能这辈子都不会知道!
交了这波智商税，你的能力会爆涨，我说的不是你的专业能力，而是在这个社会生存的基础能力！
以上所有的东西可以规为武功的招式，但如果你想短期就实现目标，我还在说明书的最后留下了一些现成资源的下载链接，包括一些稀缺的资源，保证物有所值。这部分内容可以规为内功，继不继承由你自已决定！
好了，最后跟所有的老者不一样的是：这个老人要问你收取一点点小费，才会把无比珍贵的秘籍交到你手中！
以下是付款链接，付款后你将获取《武林秘籍》的访问密码。随后你将解锁另外一个谋生技能，在工作挣着死工资的同时，该技能也能同时帮你赚另一份钱，终身受用！
http://www.gqylpy.com/get_wlmj_pwd
能在此遇见是我们的缘分，我愿意帮助你，祝你取得成功！
传说中的武林秘籍：http://blog.gqylpy.com/gqy/401/

导读
MySQL 8.0.17开始支持的redo log归档能干嘛用呢，好吃吗
今天，MySQL 8.0.17发布了，看了下release note，发现果真如之前预期的那样，恢复了redo log归档（redo log archiving）功能。之所以说是“恢复”，那是因为在InnoDB非常古老的版本（MySQL 4.0.6之前的版本）才存在，之后就取消了，当时还支持redo log mirror，老一点的MySQL DBA可能都还有印象，不过这两个功能当时没什么卵用，所以取消了。
此次，InnoDB重启redo log归档功能，按照开发团队的说法，主要是为了解决备份一致性的问题。文档里是这么写的：
Backup utilities that copy redo log records may sometimes fail to keep pacewith redo log generation while a backup operation is in progress, resultingin lost redo log records due to those records being overwritten. The redolog archiving feature addresses this issue by sequentially writing redo logrecords to an archive file. Backup utilities can copy redo log records fromthe archive file as necessary, thereby avoiding the potential loss of data.
in lost redo log records due to those records being overwritten. The redo
log archiving feature addresses this issue by sequentially writing redo log
records to an archive file. Backup utilities can copy redo log records from
the archive file as necessary, thereby avoiding the potential loss of data.简言之，就是备份速度跟不上redo log生成的速度，结果导致redo log被覆盖了，然后备份就无法保证一致性。有了redo log归档，就可以在备份启动时同步启动redo log归档，备份结束时同步停止redo log归档，这样就可以避免这个问题了，备份结束后可以利用这期间生成的redo log进行数据恢复。
想要启用redo log归档功能，只需设置innodb_redo_log_archive_dirs选项即可，该选项可支持在线动态修改，例如：
[root@yejr.me]> SET GLOBAL innodb_redo_log_archive_dirs = "redolog-archiving-for-backup:/data/mysql8-redologs/";
指定 /data/mysql8-redologs/ 目录作为redo log归档存放路径，并且指定label为 "redolog-archiving-for-backup"，也就是这是专用于备份的redo log归档存放目录。
我们还可以指定另一个目录用于未来基于redo log的物理复制用途（我瞎猜的，可能没那么快实现）。
[root@yejr.me]> SET GLOBAL innodb_redo_log_archive_dirs = "redolog-archiving-for-backup:/data/mysql8-redologs1/;redolog-archiving-for-repl:/data/mysql8-redologs2";
选项innodb_redo_log_archive_dirs可以指定多个目录作为归档redo log存放位置。不过这个选项有几个限制：
设置完后，就可以开始进行redo log归档了。
第一个参数是我们之前定义过的一个label，第二个参数是该label对应目录下的子目录，也就是 "/data/mysql8-redologs/20190722"。我们在相应目录下就可以看到这样的redo log归档文件了：
[root@yejr.me]> ls -l /data/mysql8-redologs/20190722-r--r-----. 1 mysql mysql 0 Jul 22 20:54 archive.f0ff5743-97be-11e9-a5d6-0050568bba82.000001.log文件名中常常的那串字符，就是本实例的UUID。此时文件的大小是0字节。
我们在另一个session发动一个sysbench oltp测试。执行完sysbench测试结束后，我们停止redo log归档工作：
[root@yejr.me]> DO innodb_redo_log_archive_stop();Query OK, 0 rows affected (0.00 sec)我分别记录了测试前后redo log LSN的变化如下：
# 测试前的LSNLOG---Log sequence number 27938813989...# 测试后的LSNLOG---Log sequence number 27945024531
---
Log sequence number 27938813989
...
# 测试后的LSN
LOG
---
Log sequence number 27945024531两次LSN的差值是：6210542 字节。
然后我们查看redo log归档文件大小是多少：
[root@yejr.me]> ls -l /data/mysql8-redologs/20190722-r--r-----. 1 mysql mysql 6213632 Jul 22 21:19 archive.f0ff5743-97be-11e9-a5d6-0050568bba82.000001.log可以看到文件大小是 6213632 字节，和上面的 6210542 字节只相差了 3090 字节，和本次测试产生的redo log日志大小相当。后面我们就可以利用这个redo log做数据恢复之用了（不过，相应的官方工具还没开发出来，拭目以待吧）。
一般情况下，redo log归档对性能的影响比较小（顺序写入），在大量高并发事务的场景下，可能对性能影响会稍大点，不过也不用太担心，以后有机会我再做个性能对比测试吧。
发车前，月月提醒我，MySQL企业版的备份工具已经提前支持redo归档了，希望Percona Xtrabackup也能尽快支持哈。
最后，再多说一句。大家也能注意到，MySQL 8.0版本之后，和ORACLE是越来越像了。有ORACLE这个最成功的商业数据库大哥在前面，我们完全有理由不用担心MySQL的未来。
Enjoy MySQL 8.0 :)
延伸阅读
[root@yejr.me]> DO innodb_redo_log_archive_start("redolog-archiving-for-backup","20190722");Query OK, 0 rows affected (0.02 sec)