20200720——关于hdfs/mysql/redis的持久化技术

先说mysql，个人觉得是比较难理解的

redo log是物理页面，而bin log 是逻辑页面。
redo log是引擎innodb特有的，而bin log是数据库层面的。
redo log为重做日志，bin log为归档日志
redo log是循环写的问题，一组4个文件，一个文件1gb，重复使用。
bin log写完这一页，继续写下一页。

理解一下crash-safe

crash-safe表示在mysql数据库宕机之后，能够保证
已经提交的数据仍然存在
没有提交的数据进行回滚

innodb_flush_log_at_trx_commit系统变量

这个变量可以根据用户应用的需求进行自行调改
这个值分为0 1 2

0 – 每N秒将Redo Log Buffer的记录写入Redo Log文件，并且将文件刷入硬件存储1次。N由innodb_flush_log_at_timeout控制。

1 – 每个事务提交时，将记录从Redo Log Buffer写入Redo Log文件，并且将文件刷入硬件存储。

2 – 每个事务提交时，仅将记录从Redo Log Buffer写入Redo Log文件。Redo Log何时刷入硬件存储由操作系统和innodb_flush_log_at_timeout决定。这个选项可以保证在MySQL宕机，而操作系统正常工作时，数据的完整性。

如何保证redo log和bin log的一致性

mysql引入两阶段提交（2pc），mysql内部会自动将一个普通事事务转换为一个xa事务

– 自动为每个事务分配一个唯一的ID（XID）。

– COMMIT会被自动的分成Prepare和Commit两个阶段。

– Binlog会被当做事务协调者(Transaction Coordinator)，Binlog Event会被当做协调者日志。

可以看到上面的图
1）准备阶段的时候，也就是在prepare阶段之前，已经生产了XID，redo和undo的内存日志也已经生成了。然后调用prepare，让redo log刷入磁盘。

2）提交阶段开始。write方法，将bin log内存写入缓存区，fsync将缓存区永久写入磁盘。此时事务马上要进行提交了，最后，调用引擎的commit完成事务的提交。会清除undo信息，刷redo日志，将事务设为TRX_NOT_STARTED状态。

这就是整个事务提交的过程，一旦提交阶段完成，事务就完成了提交。

HDFS中namenode的元空间

首先明确元空间中有什么

fsimage：用来存储所有目录和文件的序列化信息（id，类型，目录，所属用户，用户权限，时间戳等等）
edits log：用来记录hdfs系统的一些列操作，客户端执行的文件操作都会被记录到edits log文件中

涉及到了元数据的存储问题

元数据以文件的形式存储是否可以？
hdfs是分布式文件存储系统，如果大量的用户上传或者下载同时进行，都要对元数据进行修改。这样影响太慢。
如果单纯的存在内存中，namenode宕机了，导致数据丢失

实际上hdfs如何做到的呢

磁盘有空间为fsimage的文件，内存中也会加载这个文件
有读写分离，就有数据的一致性

写入的数据的时候，也就是操作，都写在了edits log文件中
当一个文件上传的时候，namenode为这个这个文件分配的时候，就会把信息记录在edits log中，然后将edits log数据载入内存fsimage，这样内存中的数据都保持了一致性

当edits log文件过大或者满足1h的时候，secondary namenode/ha namenode会进行checkpoint操作

1）辅助节点要求namenode停止使用edits （old），然后重新开启一个edits（new）
2）辅助节点要求namenode用http get 获取fsiamge和edits文件
3）进行合并操作
4）辅助节点用http post传回整理好的fsimage文件
5）namenode替换为新的fsimage文件，并且将edits（new）替换旧的fsimage文件

redis中的aof和rdb

redis默认的是rdb的持久化机制，但是一般我们用于aof机制

rdb

第一个redis的持久化机制策略 rdb快照
redis将当前的数据形成一个快照

一个持续写入数据的数据库如何生成快照

redis借助了fork命令的copy on write的机制。当生成的快照的时候，从该进程fork出一个子进程，在子进程中循环所有的数据，将数据写成rdb文件。

Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。

rdb的问题

那么redis一旦出现问题，数据库的信息不一定是最新的
从上次生成rdb文件到现在的redis数据全部丢失
但是对于一些对数据丢失零容忍的业务，我们就不能使用rdb了

aof

aof的全称称为 append only file，追加写入的日志文件。
与一般的数据库不同的是，aof就是一个可识别的文本，上面记录了都是redis的命令

aof重写

如果每一条指令都生成一条日志，那么aof文件会不会一直膨胀。
redis提供了一个功能，aof rewrite 。其功能是重写aof文件，新的aof文件的操作只会有一次，不会像老得文件，会有多条日志对一条数据进行操作。

其生成过程与rdb一样，fork一个子进程，直接遍历文件，写入写的aof文件。在写入新的文件的时候，操作还会写入老的aof文件，同时写入缓冲区，当新的文件写完之后，会把缓存区中的数据在写入新的aof文件，最终替换。

aof与rdb对比

rdb比aof启动的时候，加载到内存比aof快，因为
1）rdb文件中只有一条日志，不会像aof那样会有很多关于一条数据的多次操作的日志
2）rdb存储的格式与redis是一样的，不需要再进行数据加载工作，消耗更少量的cpu