Hbase 的长久化等级

援用自《Hbase 原理和实际》第六章 6.1 Hbase 的写入流程
HBase 能够通过设置 HLog 的长久化等级决定是否开启 HLog 机制以及 HLog 的落盘形式。HLog 的长久化等级分为如下五个等级。
• SKIP_WAL：只写缓存，不写 HLog 日志。因为只写内存，因而这种形式能够极大地晋升写入性能，然而数据有失落的危险。在理论利用过程中并不倡议设置此等级，除非确认不要求数据的可靠性。
• ASYNC_WAL：异步将数据写入 HLog 日志中。
• SYNC_WAL：同步将数据写入日志文件中，须要留神的是，数据只是被写入文件系统中，并没有真正落盘。HDFS Flush 策略详见 HADOOP-6313。
• FSYNC_WAL：同步将数据写入日志文件并强制落盘。这是最严格的日志写入等级，能够保证数据不会失落，然而性能绝对比拟差。
• USER_DEFAULT：如果用户没有指定长久化等级，默认 HBase 应用 SYNC_WAL 等级长久化数据。

Mysql 的长久化等级

redo log 的长久化

1、长久化策略通过参数 innodb_flush_log_at_trx_commit 管制。

设置为 0 的时候，示意每次事务提交时都只是把 redo log 留在 redo log buffer 中 ; MySQL 解体就会失落。
设置为 1 的时候，示意每次事务提交时都将 redo log 间接长久化到磁盘（将 redo log buffer 中的操作全副进行长久化，可能会蕴含其余事务还未提交的记录）；断电也不会失落。
设置为 2 的时候，示意每次事务提交时都只是把 redo log 写到 page cache。MySQL 解体不会失落，断电会失落。

2、InnoDB 后盾还有一个线程会每隔一秒钟将 redo log buffer 中记录的操作执行 write 写到 page cache，而后再 fsync 到磁盘上。

未提交的事务操作也可能会长久化，未提交事务操作的长久化触发场景如下：

1、redo log buffer 被占用的空间达到 innodb_log_buffer_size（redo log buffer 大小参数）的一半时，后盾会被动写盘，无论是否是已实现的事务操作都会执行。

2、innodb_flush_log_at_trx_commit 设为 1 时，在每次事务提交时，都会将 redo log buffer 中的所有操作（包含未提交事务的操作）都进行长久化。

3、后盾有线程每秒清空 redo log buffer 进行落盘。

参考文章：
MySQL 中的 WAL 机制