增量更新

1.全量备份和增量备份 1.1全量备份 就是对现有的数据进行全部备份，之前做的备份均可舍弃，以最新的全备为基点。 a.全备所有数据库 Innodb引擎： [root@leader mysql]#mysqldump -uroot -proot -F -A -B --events --single-transaction --master-data=1|gzip>/data/backup/mysql_backup_$(date +%F).sql.gz Myisam引擎： [root@leader mysql]#mysqldump -uroot -proot -F -A -B --events --lock-all-tables --master-data=1|gzip >/data/backup/mysql_backup_$(date +%F).sql.gz 参数说明： -F参数：刷新binlog -A参数：备份所有库 -B参数：备份数据的时候添加建库建表等语句 --events参数相当于-E:在输出中包含转储数据库的事件调度器事件 --master-data参数：如果参数值等于1，在备份文件中添加change master语句在主从同步change master的时候就不用制定binlog日志文件以及更新的位置，如果等于2则不会添加change master语句。 --single

开源 Android App 增量更新库 版本升级 ###经过几天的重构，我将之前写的一个Android 应用增量更新的示例程序重构为了一个开源库，现在已经push 到 GitHub 上，欢迎大家Watch、Star、Fork。 ### 包含以下内容 ： 服务器端生成差异包的工程：ApkPatchLibraryServer 客户端使用的开源apk合并库：ApkPatchLibrary 引用ApkPatchLibrary，实现增量更新的ApkPatchLibraryDemo 旧版本的微博Android客户端，以及服务端生成的新旧微博差分包。 ###链接 #### 原帖地址 #### GitHub地址 来源： oschina 链接： https://my.oschina.net/u/85712/blog/309293

目录[-] 官方说明 实现原理 实现 （1）生成差异包 （2）使用旧apk+差异包，在客户端合成新apk 注意事项 demo 自从 Android 4.1 开始，Google引入了应用程序的增量更新。 官方说明 Smart app updates is a new feature of Google Play that introduces a better way of delivering app updates to devices. When developers publish an update, Google Play now delivers only the bits that have changed to devices, rather than the entire APK. This makes the updates much lighter-weight in most cases, so they are faster to download, save the device’s battery, and conserve bandwidth usage on users’ mobile data plan. On average, a smart app update is about 1/3 the sizeof a full APK

一 MySQL 增量备份概念 使用 mysqldump 进行完全备份，备份的数据中有重复数据，备份时间与恢复时间过长。而增量备份就是备份自上一次备份之后增加或改变的文件或内容。 增量备份的特点： 没有重复数据，备份量不大，时间短 恢复麻烦：需要上次完全备份及完全备份之后所有的增量备份才能恢复，而且要对所有增量备份进行逐个反推恢复。 MySQL 没有提供直接的增量备份办法，可以通过 MySQL 提供的二进制日志（ binary logs(binlog) ）间接实现增量备份。 MySQL 二进制日志对备份的意义： 二进制日志保存了所有更新或者可能更新数据库的操作。 二进制日志在启动 MySQL 服务器后开始记录，并在文件达到 max_binlog_size 所设置的大小或者接收到 flush logs 命令后重新创建新的日志文件。 [root@localhost ~]# vim /etc/my.cnf 52 max_binlog_size = 1024000 // 二进制日志最大 1M 只需定时执行 flush logs 方法重新创建新的日志，生成二进制文件序列，并及时把这些日志保存到安全的地方就完成了一个时间段的增量备份。 要进行 MySQL 的增量备份，首先要开启二进制日志功能，开启 MySQL 的二进制日志功能。 方法一： MySQL 的配置文件的 [mysqld] 项中加入

一、备份的目的 做灾难恢复：对损坏的数据进行恢复和还原 需求改变：因需求改变而需要把数据还原到改变以前 测试：测试新功能是否可用 二、备份需要考虑的问题 可以容忍丢失多长时间的数据； 恢复数据要在多长时间内完； 恢复的时候是否需要持续提供服务； 恢复的对象，是整个库，多个表，还是单个库，单个表。 三、备份的类型 1、根据是否需要数据库离线 冷备（cold backup） ：需要关mysql服务，读写请求均不允许状态下进行； 温备（warm backup） ： 服务在线，但仅支持读请求，不允许写请求； 热备（hot backup） ：备份的同时，业务不受影响。 注： 1、这种类型的备份，取决于业务的需求，而不是备份工具 2、MyISAM不支持热备，InnoDB支持热备，但是需要专门的工具 2、根据要备份的数据集合的范围 完全备份：full backup，备份全部字符集。 增量备份: incremental backup 上次完全备份或增量备份以来改变了的数据，不能单独使用，要借助完全备份，备份的频率取决于数据的更新频率。 差异备份：differential backup 上次完全备份以来改变了的数据。 建议的恢复策略： 完全+增量+二进制日志 完全+差异+二进制日志 3、根据备份数据或文件 物理备份：直接备份数据文件 优点： 备份和恢复操作都比较简单，能够跨mysql的版本，

原文链接： https://www.cnblogs.com/onepixel/p/7674659.html 注意 ： 原文中的算法实现都是基于JS，本文全部修改为C实现，并且统一排序接口，另外增加了一些描述信息，后面会持续更新本文。 0、算法概述 0.1 算法分类 十种常见排序算法可以分为两大类： 比较类排序 ：通过比较来决定元素间的相对次序，由于其时间复杂度不能突破O(nlogn)，因此也称为非线性时间比较类排序。 非比较类排序 ：不通过比较来决定元素间的相对次序，它可以突破基于比较排序的时间下界，以线性时间运行，因此也称为线性时间非比较类排序。 0.2 算法复杂度 0.3 相关概念 稳定 ：如果a原本在b前面，而a=b，排序之后a仍然在b的前面。 不稳定 ：如果a原本在b的前面，而a=b，排序之后 a 可能会出现在 b 的后面。 时间复杂度 ：对排序数据的总的操作次数。反映当n变化时，操作次数呈现什么规律。 空间复杂度： 是指算法在计算机内执行时所需存储空间的度量，它也是数据规模n的函数。 0.4 在线学习 这里提供两个算法可视化网站，方便理解这些排序算法： https://visualgo.net/en/sorting https://www.cs.usfca.edu/~galles/visualization/ComparisonSort.html

1.准备 1.1.组件 　　 JDK ：1.8版本及以上； 　　 ElasticSearch ：6.x版本，目前貌似不支持7.x版本； 　 Canal.deployer： 1.1.4 　　 Canal.Adapter： 1.1.4 1.1.配置 需要先开启MySQL的 binlog 写入功能，配置 binlog-format 为 ROW 模式 找到my.cnf文件，我的目录是/etc/my.cnf，添加以下 配置： log-bin=mysql-bin 　　# 开启 binlog binlog-format=ROW 　　# 选择 ROW 模式 server_id=1 　　　　 # 配置 MySQL replaction 需要定义，不要和 canal 的 slaveId 重复 然后 重启mysql ，用以下命令检查一下binlog是否正确启动： mysql> show variables like 'log_bin%'; +---------------------------------+----------------------------------+ | Variable_name | Value | +---------------------------------+----------------------------------+ | log_bin | ON |

本文转载于: 猿2048 网站➫ https://www.mk2048.com/blog/blog.php?id=h1b2b2cibb 自从vue、react或者angular这类框架流行后，单页应用的数量也越来越多。但是限制于单页应用的一些缺点，比如：seo、首屏时间等因素，很多应用的结构还是保持了多页面结构。此篇讲述的是如何在多页面应用结构的基础上，利用webpack生成带hashcode文件名的方式实现静态资源的增量更新方案。 多页应用的结构在用户访问时往往会在当前页面加载一些公共资源和当前页面的js和css，可能有些应用还在用比较传统的： https://url/[版本号]/xxx.[js|css] 或 https://url/xxx.js?r=xxx 的方式来保证当应用更新时客户端也能及时获取到最新的资源文件。而当前流行的前端的架构中单页应用在发布时，往往可以通过编译时在生成的资源文件名中加入文件的hashcode值来保证每个资源都有自己独立的"版本号"。客户端加载带有hashcode文件名的资源文件，当某个资源文件更新时也不会影响其他资源文件的名称，可以有效利用客户端的强缓存策略，增加资源文件的缓存命中率。 下面我们将实现在多页架构中如何实现静态文件名加入hashcode，并在服务端引用文件的例子： 1.Webpack编译生成文件追加hashcode webpack

博文目录 一、MySQL完全备份与恢复 二、数据库备份类型 三、常见的备份方法 四、数据库完全备份操作 五、MySQL增量备份与恢复 一、MySQL完全备份与恢复 备份的主要目的是灾难恢复，备份还可以测试应用、回滚数据修改、查询历史数据、审计等。 1、数据备份的重要性 在企业中数据的价值至关重要，数据保障了企业业务的正常运行。因此，数据的安全性及数据的可靠性是运维的重中之重，任何数据的丢失都可能对企业产生严重的后果。通常情况下造成数据丢失的原因如下几种： 程序错误 人为操作错误 运算错误 磁盘故障 灾难（火灾、地震）和盗窃 三、常见的备份方法 二、数据库备份类型 1、从物理与逻辑的角度： 数据库备份可以分为物理备份和逻辑备份。物理备份是对数据库操作系统的物理文件（如数据文件、日志文件等）的备份。这种类型的备份适用于在出现问题时需要快速恢复的大型重要数据库。 物理备份又可以分为冷备份（脱机备份）、热备份（联机备份）和温备份。 冷备份：在数据库关闭状态下进行备份操作； 热备份：在数据库处于运行状态时进行备份操作，该备份方法依赖数据库的日志文件； 温备份：数据库锁定表格（不可写入，但可读取）的状态下进行备份； 逻辑备份是对数据库逻辑组件（如表等数据库对象）的备份，表示为逻辑数据库结构（create database、create table语句）和内容（insert语句或分隔文本文件

Hive增量更新方案 方案一（总结出来业界可行方案）： 1、Hive原始表提前规划好以时间分区，初始化装载源库记录为base_table（最新数据） 2、每个相关表都会有一个timestamp列，对每一行操作做了修改，都会重置这列timestamp为当前时间戳； 3、新增数据通过sqoop（支持当天抽取）或者导出当天文件两种形式，抽取或导入到hive表，记录为新增表incremental_table 4、（1）如果incremental_table表中数据不涉及到更新，直接导入到以时间分区的base_table表中 （2）如果某几个分区涉及到更新操作，将这段时间分区内的base_table和incremental_table数据进行合并，有相同主键的取timestamp最新的那条，合并后新数据重新写回base_table分区中； （3）如果涉及到删除数据操作，分软删除（打标签）和硬删除；如果是软删除，记录数据也会存在incremental_table，只是在合并base_table和incremental_table表中过滤掉此记录写回base_table即可。如果是硬删除，需将删除的数据行放入额外审计表中audit_table，与base_table和incremental_table一起进行合并过滤处理后，再写回base_table。 采用Oozie