checkpoint

Checkpoint 我们必须记录一些信息以方便恢复现场，在Spark Streaming中使用checkpoint实现恢复操作。 Spark Streaming中有两种不同对象的checkpont操作。 元数据(Metadata) checkpointing 保存Streaming中定义流计算的相关信息到可信赖的文件系统如HDFS，这种方式用于运行Driver的节点失败之后的恢复。 元数据包括： 配置---创建context时的配置 DStream的操作---定义流应用程序的DStream操作集 未完成的批次---记录已经在队列中但是还没有完成的批次 数据(Data) checkpointing 保存生成的RDD到可信赖的存储中，有一种场景是一些有状态的transformations是跨多个批次的数据组合，生成的RDD依赖上个批次的RDD，导致RDD的依赖链随着程序运行越来越长，当程序失败后，因为依赖链过长，恢复需要相当长的时间，如果定期checkponit就可以切断依赖链以减少恢复时间。 注意 ：切断RDD之间的依赖链只是Data checkpointing顺带解决的问题，而不是设计Data checkpointing的目的，Data checkpointing的目的和作用还是保存RDD到可信赖的存储。 总的来说，元数据checkpoint主要是为了driver失败后的恢复

OGG 拆分REPLICAT进程可参考 https://www.cndba.cn/leo1990/article/2859 1.2. OGG 合并REPLICAT进程 1.2.1. 停止extract进程 GGSCI ( cndba ) 16 > stop ext1 Sending STOP request to EXTRACT EXT1 ... Request processed . 1.2.2. 检查extract进程的checkpoint信息 GGSCI ( cndba ) 17 > info ext1 , showch EXTRACT EXT1 Last Started 2018 - 06 - 12 09 : 26 Status STOPPED Checkpoint Lag 00 : 00 : 00 ( updated 00 : 00 : 09 ago ) Log Read Checkpoint Oracle Redo Logs 2018 - 06 - 12 09 : 54 : 51 Thread 1 , Seqno 54 , RBA 1670144 SCN 0.1365669 ( 1365669 ) 记录下其 Write Checkpoint 信息中的 sequence 和 RBA 值，例如： Write Checkpoint #1 GGS Log Trail

断点续训：在进行神经网络训练过程中由于一些因素导致训练无法进行，需要保存当前的训练结果下次接着训练 全连接反向传播神经网络中，训练过程的代码如下： #coding:utf-8 #1前向传播过程 import tensorflow as tf #网络输入节点为784个（代表每张输入图片的像素个数） INPUT_NODE = 784 #输出节点为10个（表示输出为数字0-9的十分类） OUTPUT_NODE = 10 #隐藏层节点500个 LAYER1_NODE = 500 def get_weight(shape, regularizer): #参数满足截断正态分布，并使用正则化， w = tf.Variable(tf.truncated_normal(shape,stddev=0.1)) #w = tf.Variable(tf.random_normal(shape,stddev=0.1)) #将每个参数的正则化损失加到总损失中 if regularizer != None: tf.add_to_collection('losses', tf.contrib.layers.l2_regularizer(regularizer)(w)) return w def get_bias(shape): #初始化的一维数组，初始化值为全 0 b = tf.Variable(tf.zeros

1、innoDB体系架构图 图解 （1）innodb存储有多个内存块、组成内存池 （2）内存池负责：维护可访问数据结构、缓存数据 （2）后台线程负责刷新缓存、修改磁盘数据、保证异常恢复 2、后台线程 innodb是多线程模型、不同后台线程，任务不同。 （1）Master Thread 主后台线程、负责根据checkpoint 机制将缓存池数据异步刷新到磁盘、保证数据一致性。 lOThread类型有 write 、read 、insert buffer 、 log 四种 。 使用innodb_read_io_threads 和 innodb_write_io_threads 配置参数可以设置read io 和 write io 的数量 show engine innodb status 命令 观察IO Thread 可以发现读线程id 总数小于写线程id ,且默认各自数量为4 用于回收undo页 （4）Page Cleaner Thread 刷新脏页、减轻Master Thread负担、减少 read Thread 阻塞 3、内存 （1）缓冲池 innodb存储引擎是基于磁盘存储的（Disk-base Database）、由于cpu 与磁盘的性能差距大 ，使用缓存提高性能，缓存池其实就是一块内存区域 数据库读取页操作，先读到缓存池 、这个过程叫 将页“FIX”到缓存池

前言 　　在 Flink原理——容错机制 一文中，已对checkpoint的机制有了较为基础的介绍，本文着重从源码方面去分析checkpoint的过程。当然本文只是分析做checkpoint的调度过程，只是尽量弄清楚整体的逻辑，没有弄清楚其实现细节，还是有遗憾的，后期还是努力去分析实现细节。 文中若是有误，欢迎大伙留言指出 ！ 　　本文基于Flink1.9。 1、参数设置 　　 1.1 有关checkpoint常见的参数如下： 1 StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); 2 env.enableCheckpointing(10000); //默认是不开启的　　 3 env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE); //默认为EXACTLY_ONCE 4 env.getCheckpointConfig().setMinPauseBetweenCheckpoints(5000);　　//默认为0，最大值为1年 5 env.getCheckpointConfig().setCheckpointTimeout(150000);　　//默认为10min

之前我们了解了一条查询语句的执行流程，并介绍了执行过程中涉及的处理模块。一条查询语句的执行过程一般是经过连接器、分析器、优化器、执行器等功能模块，最后到达存储引擎。 那么，一条 SQL 更新语句的执行流程又是怎样的呢？ 首先我们创建一个表 user_info，主键为 id，创建语句如下： CREATE TABLE `T` ( `ID` int( 11) NOT NULL, `c` int( 11) DEFAULT NULL, PRIMARY KEY ( `ID`) ) ENGINE= InnoDB DEFAULT CHARSET=utf8mb4; 插入一条数据： INSERT INTO T VALUES ('2', '1'); 如果要将 ID=2 这一行的 c 的值加 1，SQL 语句为： UPDATE T SET c = c + 1 WHERE ID = 2; 前面介绍过 SQL 语句基本的执行链路，这里把那张图拿过来。因为，更新语句同样会走一遍查询语句走的流程。 通过连接器，客户端与 MySQL 建立连接 update 语句会把 T 表上的所有查询缓存结果清空 分析器会通过词法分析和语法分析识别这是一条更新语句 优化器会决定使用 ID 这个索引（聚簇索引） 执行器负责具体执行，找到匹配的一行，然后更新 更新过程中还会涉及 redo log（重做日志）和 binlog（归档日志

深度学习模型花费时间大多很长, 如果一次训练过程意外中断, 那么后续时间再跑就浪费很多时间. 这一次练习中, 我们利用 Keras checkpoint 深度学习模型在训练过程模型, 我的理解是检查训练过程, 将好的模型保存下来. 如果训练过程意外中断, 那么我们可以加载最近一次的文件, 继续进行训练, 这样以前运行过的就可以忽略. 那么如何 checkpoint 呢, 通过练习来了解. 数据: Pima diabete 数据 神经网络拓扑结构: 8-12-8-1 1.效果提升检查 如果神经网络在训练过程中, 其训练效果有所提升, 则将该次模型训练参数保存下来. 代码 : # -*- coding: utf-8 -*- # Checkpoint NN model imporvements from keras.models import Sequential from keras.layers import Dense from keras.callbacks import ModelCheckpoint import numpy as np import urllib url = "http://archive.ics.uci.edu/ml/machine-learning-databases/pima-indians-diabetes/pima-indians-diabetes

1.Apache Kafka官网介绍 http://kafka.apache.org 发布 & 订阅: 类似于一个消息系统，读写流式的数据. 处理: 编写可扩展的流处理应用程序，用于实时事件响应的场景。 存储: 安全的将流式的数据存储在一个分布式，有副本备份，容错的集群。 Kafka@用于构建实时的数据管道和流式的app.它可以水平扩展，高可用，速度快，并且已经运用在数千家公司的生产环境。 2.CDH Kafka官网介绍 https://docs.cloudera.com/documentation/kafka/latest/topics/kafka.html 3.生产如何选择版本 生产上绝大部分是CDH来构建企业级大数据平台，那么Kafka属于需要自定义部署《CDK部署课程》。 故企业里现在使用CDH5.15.1版本，那么默认zookeeper的版本即为zookeeper-3.4.5-cdh5.15.1， 这是固定的，无法改变。 那么Kafka版本如何选择呢？一般我们选择，当前的CDH官网的Kafka安装包最新版本即可。 当然我司经典版本是选择[0.10.2.0+kafka2.2.0+110]，主要是历史时间原因+Spark Streaming对接Kafka的起始版本0.10。 CDH Kafka: wget http://archive.cloudera.com/kafka

第一次info rlzsi，showch REPLICAT RLZSI Last Started 2019-10-26 02:14 Status RUNNING Checkpoint Lag 57:14:58 (updated 00:00:05 ago) Log Read Checkpoint File ./dirdat/si001435 2019-10-23 17:19:11.523405 RBA 6342975 Current Checkpoint Detail: Read Checkpoint #1 GGS Log Trail Startup Checkpoint (starting position in the data source): Sequence #: 1435 RBA: 14327 Timestamp: 2019-10-23 17:09:06.523711 Extract Trail: ./dirdat/si Current Checkpoint (position of last record read in the data source): Sequence #: 1435 RBA: 6342975 Timestamp: 2019-10-23 17:19:11.523405 Extract Trail: ./dirdat/si Header:

Reference: https://www.askmaclean.com/archives/rman-06026-absolute_fuzzy_change.html https://blog.csdn.net/songxixi/article/details/7010934 RMAN> run{ debug on; set until time "to_date('2013-08-08 19:12:03','yyyy-mm-dd hh24:mi:ss')"; restore database ; debug off; } 2> 3> 4> 5> 6> RMAN-03036: Debugging set to level=9, types=ALL RMAN-03023: executing command: SET until clause RMAN-03090: Starting restore at 2013-08-15 10:19:14 RMAN-06009: using target database control file instead of recovery catalog RMAN-08030: allocated channel: ORA_DISK_1 RMAN-08605: channel ORA_DISK_1: SID=661 instance