2019年12月10日
本文介绍CacheServer中CreateBinlogFileThread线程和BackUpImp的相关配置和处理逻辑
CreateBinlogFileThread
功能:用于定时生成binlog文件。
binlog文件按模块(表)划分,里面记录了对该模块的所有增量操作,主要用于主从数据同步和故障恢复,类似于redis中的AOF。DCache的binlog分为2种:key-binlog和正常的binlog,按需开启。
相关文件:
TimerThread.h
TimerThread.cpp
配置解析
<BinLog>
#binlog日志文件名后缀
LogFile=binlog
#每次同步binlog的行数
MaxLine=10000
#是否记录binlog
Record=Y
#是否记录key binlog
KeyRecord=N
#主备同步使用key binlog
KeySyncMode=N
#同步binlog是否开启压缩
SyncCompress=Y
#采用gzip压缩格式
IsGzip=Y
#备机同步binlog缓存buffer的szie
BuffSize=10
#保存synctime文件的间隔(秒)
SaveSyncTimeInterval=10
#active binlog产生的周期(秒)
HeartbeatInterval=600
</BinLog>
该线程只读取以下配置:
LogFile | binlog日志文件名后缀,一般情况下不会修改这个参数。 binlog文件只存放在CacheServer所在的主机上,不会写到远程日志中心。 如:DCache.BillAppCacheAMLTMKVCacheServer1-1_binlog_2022042921.log |
Record | 是否记录binlog |
KeyRecord | 是否记录key binlog。 在某些不关注value的场景中,可以只写key binlog。正常情况下用不到,保持关闭即可 |
线程逻辑
1、如果既不写普通binlog(Record=N),也不写keybinlog(KeySyncMode=N),线程就直接退出。
2、线程每秒执行1次
3、每小时生成1个binlog文件
4、binlog文件都放在在该服务的日志路径下,keybinlog和binlog文件名不一样,keybinlog在”LogFile”配置的后面多了”key”
BackUpImp
功能:提供DCache数据的全量备份和恢复服务
说明:当前框架中并无客户端调用该服务,需要视情况调用。
对象名称:
DCache.FeeAppVRecvListMKVCacheServer1-1.BackUpObj
相关文件:
MKBackUpImp.h
MKBackUpImp.cpp
接口说明
MKBackUp.tars:
module DCache
{
interface MKBackUp
{
/*
* dump内存数据到指定路径文件
* dumpPath: 存放镜像文件的绝对路径,如果为空则dump到默认路径:/data/dcache/dump_binlog/
* mirrorName: 镜像文件名, 如果为空则使用组名和当前时间生成文件名,例如:TestModuleMKVGroup1_dump_binlog_20190701120101.log.gz
*/
int dump(string dumpPath, string mirrorName, out string errmsg);
/*
* 恢复mirror和binlog,路径下没有mirror,则只恢复binlog,有的话先恢复mirror,再恢复binlog
* mirrorPath: mirror文件绝对路径
* binlogPath: binlog文件绝对路径
* lastTime: 恢复到该时间点,unix时间戳,精度:秒
* normal:是否强制恢复,正常的恢复流程在加载完镜像和binlog后,会再从主机同步一条binlog
* 强制恢复流程,则是加载完镜像和binlog后,就认为恢复完成
*/
int restore(string mirrorPath, vector<string>binlogPath, int lastTime, bool normal, out string errmsg);
};
};
该服务提供了2个方法,在MKBackUp.tars文件中有方法功能的详细说明。
1、dump方法
启动1个DumpThread线程,进行数据的备份(详细逻辑,见《CacheServer-DumpThread》)。
2、restore方法
初始化并启动1个SlaveCreateThread线程,进行数据恢复。(详细逻辑见《CacheServer-SlaveCreateThread》)
DCache在服务层并未集成“自动故障恢复”相关功能,但为我们提供了对应的rpc服务,让使用者决定是否备份、何时备份,以及数据恢复的粒度,在操作上更加灵活。
在我的项目实践中,编写了一个job挂载到Tars上:
- 每1小时执行一次dump,全量备份内存数据(间隔可配置,视情况而定),记录时间戳T
- 增加自定义指令restoreAll,作用是恢复全量数据和增量操作到内存中。在指令处理中,读取最近一次的dump文件和时间戳T,进行restore;完成之后再处理时间戳T之后的binlog文件,恢复dump之后的操作
这样,如果系统宕机,也可以通过在控制台上执行指令“restoreAll”,来快速恢复内存数据。
当然,恢复过程也完全可以做到自动化:定时到注册中心查询DCache模块的服务列表,发现哪个模块异常后,再主动探测几次,确认异常之后进行标记。待该模块恢复之后,自动发起“restoreAll”操作。
总结
DCache也具备全量备份和增量备份的功能,具备故障恢复数据的能力。
但与Redis不同,DCache的全量备份是由开发者编码控制的(调用DCache接口),增量备份是DCache自动完成的;恢复数据时,也需要通过编码调用DCache相应的接口来实现。
DCache之所以这样处理,笔者认为是因为DCache使用的共享内存,即使进程意外挂死,内存数据还在。这时重启CacheServer即可,并不需要重“数据预热”的过程,处理能力恢复的更快!
只有在主机宕机的情况下,才需要调用接口来恢复数据。