checkpoint

一、状态一致性分类 （1）最多一次（at most once） 当故障发生，什么都不干，既不恢复丢失状态，也不重播丢失的数据。 （2）至少一次（at least once） 所有事件都处理了，有的事件可能被处理多次 （3）精确一次（exactly once） 所有事件仅仅被处理一次 二、端到端的状态一致性 （1）内部保证（checkpoint） （2）source端（可重设数据的读取位置） （3）sink端（从故障恢复时数据不会重复写入外部系统，比如幂等写入，事务写入） 事务写入的实现思想：构建的事务对应着checkpoint，等到checkpoint真正完成的时候，才把所有对应的结果写入sink中 实现方式有两种：预写日志，两阶段提交 1）预写日志 把结果数据先当成状态保存，然后在收到的checkpoint完成通知时一次性写入sink DataStream API提供了一个模板类，GenericWriteAheadSink，来实现事务性sink 注意：checkpoint完成了，但是写入sink只有一半写入成功，则不能保证一致性 2）两阶段提交 i）每个checkpoint，sink任务会启动一个事务，并将接下来的所有接受的数据添加到事务里 ii）然后将这些数据写入外部sink系统，但不是提交，这次是预提交 iii）当收到checkpoint完成通知时，它才会正式提交事务

简介 SQL Server2012新增的Indirect CheckPoint允许CheckPoint的恢复间隔设置到数据库级别，而不是以前那样实例级别。 在数据库级别设置的恢复时间以秒为单位，而不是在实例级别的以分钟为单位。这可以更精确的保证数据库Recovery的最大时间。 配置Indirect CheckPoint Indirect Checkpoint是数据库级别的。在SQL SERVER中，包括Contained Database,SQL Server把一些设置从实例级别转到了数据库级别。 按照MSDN上对Indirect CheckPoint的描述，我对Indirect CheckPoint的理解是独立于实例级别CheckPoint的的额外线程。仅仅负责其所在的数据库。因此带来的好处可以归结如下。 1.更少的数据库恢复时间(CheckPoint间隔小了，自然恢复时间就少了) 2.更精确的恢复时间。现在不仅仅CheckPoint的范围缩小了，并且最大恢复时间是以秒为单位。 3.由于这个Indirect CheckPoint线程将其所负责数据库范围内的Dirty Page写入磁盘，所以实例级别的CheckPoint可以减少对磁盘的一次性写入量。从而减少了实例级别CheckPoint的负载 但是，设置Indirect

MySQL的Checkpoint机制介绍   Mysql对于持久性的实现是基于 Write ahead log 来实现的，在其管理的文件系统中有一个文件叫做 重做日志(redo log) ，其 作用是在服务器宕机重启后通过它来实现数据恢复的功能 。重做日志中记录的是事务对数据库所做的逻辑操作。这句话怎么理解呢？举个例子：   在事务A中修改了studenet表的一条记录： update student set sname = '张三' where sno = '1001'; 那么对于这个操作redo log记录的就是：修改sno='1001’的那条记录的sname=‘张三’， 即对数据页的哪一行做什么操作 ， 并不是直接记录sql操作后的数据值 。另外需要理解的是，redo log采用了循环写机制，它被保存在共享表空间的ib_logfile0和ib_logfile1中，循环写的意思就是ib_logfile0写满了就写ib_logfile1，ib_logfile1满了就重写ib_logfile0。   那么它和Checkpoint机制有什么关系呢？所谓的 Checkpoint机制其实就是什么时间将InnoDB缓存中的脏页刷新到磁盘中去，其隐含的语义是：保持redo log中的日志信息与磁盘数据一致。 即使服务器宕机了，也不会造成数据丢失。  

检查点是一个数据库事件，它把修改数据从高速缓存写入磁盘，并更新控制文件和数据文件。 检查点分为三类： 1）局部检查点：单个实例执行数据库所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件。 触发命令： svmrgrl>alter system checkpoint local; 这条命令显示的触发一个局部检查点。 2）全局检查点：所有实例（对应并行数据服务器）执行数据库所有所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件。 触发命令 svrmgrl>alter system checkpoint global; 这条命令显示的触发一个全局检查点。 3）文件检查点：所有实例需要执行数据文件集的一个检查点操作，如使用热备份命令alter tablespace USERS begin backup，或表空间脱机命令alter tablespace USERS offline，将执行属于USERS表空间的所有数据文件的一个检查点操作。 检查点处理步骤： 1）获取实例状态队列：实例状态队列是在实例状态转变时获得，ORACLE获得此队列以保证检查点执行期间，数据库处于打开状态； 2）获取当前检查点信息：获取检查点记录信息的结构，此结构包括当前检查点时间、活动线程、进行检查点处理的当前线程、日志文件中恢复截止点的地址信息； 3）缓存区标识：标识所有脏缓存区

checkpoint 和 commit没什么关系 checkpoint为了保证数据一致性，在下面情况下触发写事件： a 手工checkpoint,alter system checkpoint b alter tablespace offline/begin backup; c 正常shutdown数据库 写事件就是它会将数据文件头和控制文件中写入同一个id，以便于在数据库打开时，通过id知道数据库是否需要恢复 而commit只是当数据提交后，触发将redo buffer写入redo file的事件，从而能在恢复时用到日志文件内容 也就是说commit之后没有写入到datafile，如果insert 了一条数据没有alter system checkpoint并且recover的时候没有copy rodo log，那么这条数据将不能恢复？ 那么日常使用数据库数据文件在逐渐增大都是什么时候写入的？ 各种后台进程的作用： Ckpt、lgwr、dbwn之间的协作。 Ckpt：每隔3秒或更频繁写一次，写入控制文件，记录DBWN从SGA写入磁盘的块的位置。 LGWR:每3秒，1/3满buffer，commit，DBWN写之前。将buffer中数据写入物理文件。 DBWN：将SGA中脏块写入datafile。 Oracle 写入数据过程： Oracle 写数据过程：dml操作一执行

一、简介 开源流式处理系统在不断地发展，从一开始只关注低延迟指标到现在兼顾延迟、吞吐与结果准确性，在发展过程中解决了很多问题，编程API的易用性也在不断地提高。本文介绍一下 Flink 中的核心概念，这些概念是学习与使用 Flink 十分重要的基础知识，在后续开发 Flink 程序过程中将会帮助开发人员更好地理解 Flink 内部的行为和机制。 这里引用一张图来对常用的实时计算框架做个对比： Flink 是有状态的和容错的，可以在维护一次应用程序状态的同时无缝地从故障中恢复。它支持大规模计算能力，能够在数千个节点上并发运行。它具有很好的吞吐量和延迟特性。同时，Flink 提供了多种灵活的窗口函数。Flink 在流式计算里属于真正意义上的单条处理，每一条数据都触发计算，而不是像 Spark 一样的 Mini Batch 作为流式处理的妥协。Flink的容错机制较为轻量，对吞吐量影响较小，而且拥有图和调度上的一些优化，使得 Flink 可以达到很高的吞吐量。而 Strom 的容错机制需要对每条数据进行ack，因此其吞吐量瓶颈也是备受诟病。 二、工作原理 Flink基本工作原理如下图： JobClient：负责接收程序，解析和优化程序的执行计划，然后提交执行计划到JobManager。这里执行的程序优化是将相邻的Operator融合，形成Operator Chain