共计 1019 个字符,预计需要花费 3 分钟才能阅读完成。
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 机制