目录
-
文件同步
-
何时开启同步线程
-
从Tracker Server获取到同组storage server集合后,就会为除了自己之外的其他同组storage server分别开启同步线程。
如果组内有三个Storage Server,那么每台Storage Server都应该开启两个独立同步线程
同步规则
1. 只在本组内的storage server之间进行同步;
2. 源头数据才需要同步,备份数据不需要再次同步,否则就构成环路了;
3. 同步采取push方式,即源服务器同步给同组其他服务器;
4. 上述第二条规则有个例外,就是新增加一台storage server时,由已有的一台storage server将已有的所有数据(包括源头数据和备份数据)同步给该新增服务器
-
同步流程
-
Binlog 目录结构
-
当Storaged server启动时会创建一个 base_path/data/sync
同步目录,该目录中的文件都是和同组内的其它 Storaged server之间的同步状态文件,如:
192.168.1.2_33450.mark
192.168.1.3_33450.mark
binlog.000
binlog.index
文件说明:
binlog.index 记录当前使用的binlog文件序号,如为10,则表示使用binlog.010
binlog.100 真实地binlog文件
192.168.1.2_33450.mark 同步状态文件,记录本机到192.168.1.2_33450的同步状态
-
-
-
Mark 文件
-
-
在Mark文件中内容:
binlog_index=0
binlog_offset=1334
need_sync_old=1
sync_old_done=1
until_timestamp=1457542256
scan_row_count=23
sync_row_count=11
文件说明:
binlog_index:对应于哪个binlog
binlog_offset:binlog.xxx的偏移量,可以直接这个偏移量获取下一行记录
need_sync_old:本storage是否是对侧storage(10.100.66.82)的源结点,同时是否需要从起点同步所有的记录
sync_old_done:是否同步完成过
until_timestamp:上次同步时间结点
scan_row_count:总记录数
sync_row_count:已同步记录数
-
-
-
Binlog 文件
-
-
Binlog文件内容:在该文件中是以binlog日志组成,比如:
1470292943 c M00/03/61/QkIPAFdQCL-AQb_4AAIAi4iqLzk223.jpg
1470292948 C M00/03/63/QkIPAFdWPUCAfiraAAG93gO_2Ew311.png
1470292954 d M00/03/62/QkIPAFdWOyeAO3eUAABvALuMG64183.jpg
1470292959 C M00/01/23/QUIPAFdVQZ2AL_o-AAAMRBAMk3s679.jpg
1470292964 c M00/03/62/QkIPAFdVOsCAcxeQAAGTdbQsdVs062.jpg
1470292969 c M00/03/62/QkIPAFdVOnKAXu1NAABq9pkfsms63.jpeg
1470293326 D M00/03/62/QkIPAFdVMnGAZYSZAABq9pkfsms33.jpeg
文件说明:
其中的每一条记录都是使用[空格符]分成三个字段,分别为:
- 第一个字段 表示文件 upload 时间戳 如:1470292943
- 第二个字段 表示文件执行操作,值为下面几种(其中源表示客户端直接操作的那个 Storage 即为源,其他的 Storage 都为副本)
C 表示源创建、c 表示副本创建
A 表示源追加、a 表示副本追加
D 表示源删除、d 表示副本删除
T 表示源 Truncate、t 表示副本 Truncate
- 第三个字段 表示文件,如
M00/03/61/QkIPAFdQCL-AQb_4AAIAi4iqLzk223.jpg
-
-
同步过程
-
从fastdfs文件同步原理中我们知道Storaged server之间的同步都是由一个独立线程负责的,这个线程中的所有操作都是以同步方式执行的。比如一组服务器有A、B、C三台机器,那么在每台机器上都有两个线程负责同步,如A机器,线程1负责同步数据到B,线程2负责同步数据到C。每个同步线程负责到一台Storage的同步,以阻塞方式进行。
1)获取组内的其他 Storage 信息,并启动同步线程
在Storage.conf配置文件中,只配置了Tracker的IP地址,并没有配置组内其他的Storage。因此同组的其他Storage必须从Tracker获取。具体过程如下:
1)Storage启动时为每一个配置的Tracker启动一个线程负责与该Tracker的通讯。
2)默认每间隔30秒,与Tracker发送一次心跳包,在心跳包的回复中,将会有该组内的其他Storage信息。
3)Storage获取到同组的其他Storage信息之后,为组内的每个其他Storage开启一个线程负责同步。
2)同步线程执行过程
每个同步线程负责到一台Storage的同步,以阻塞方式进行。
1)打开对应Storage的mark文件,如负责到10.0.1.1的同步则打开10.0.1.1_23000.mark文件,从中读取binlog_index、binlog_offset两个字段值,如取到值为:1、100,那么就打开binlog.001文件,seek到100这个位置。
2)进入一个while循环,尝试着读取一行,若读取不到则睡眠等待。若读取到一行,并且该行的操作方式为源操作,如C、A、D、T(大写的都是),则将该行指定的操作同步给对方(非源操作不需要同步),同步成功后更新binlog_offset标志,该值会定期写入到10.0.1.1_23000.mark文件之中。
-
-
文件同步时间戳
-
举个例子:一组内有Storage-A、Storage-B、Storage-C三台机器。对于A这台机器来说,B与C机器都会同步Binlog(包括文件)给他,A在接受同步时会记录每台机器同步给他的最后时间(也就是Binlog中的第一个字段timpstamp)。比如B最后同步给A的Binlog-timestamp为100,C最后同步给A的Binlog-timestamp为200,那么A机器的最后最早被同步时间就为100。
这个值的意义在于,判断一个文件是否存在某个Storage上。比如这里A机器的最后最早被同步时间为100,那么如果一个文件的创建时间为99,就可以肯定这个文件在A上肯定有。为什呢?一个文件会Upload到组内三台机器的任何一台上:
1)若这个文件是直接Upload到A上,那么A肯定有。
2)若这个文件是Upload到B上,由于B同步给A的最后时间为100,也就是说在100之前的文件都已经同步A了,那么A肯定有。
3)同理C也一样。
Storage会定期将每台机器同步给他的最后时间告诉给Tracker,Tracker在客户端要下载一个文件时,需要判断一个Storage是否有该文件,只要解析文件的创建时间,然后与该值作比较,若该值大于创建创建时间,说明该Storage存在这个文件,可以从其下载。
Tracker也会定期将该值写入到一个文件之中,storage_sync_timestamp.dat
,内容如下:
group1,10.0.0.1,0,1408524351,1408524352
group1,10.0.0.2,1408524353,0,1408524354
group1,10.0.0.3,1408524355,1408524356,0
每一行记录了,对应Storage同步给其他Storage的最后时间,如第一行表示10.0.0.1同步给10.0.0.2的最后时间为1408524351,同步给10.0.0.3的最后时间为1408524352;同理可以知道后面两行的含义了。每行中间都有一个0,这个零表示自己同步给自己,没有记录。按照纵列看,取非零最小值就是最后最早同步时间了,如第三纵列为10.0.0.1被同步的时间,其中1408524353就是其最后最早被同步时间
-
-
问题
-
问题一:同步到中途,把源文件删除,备份服务器怎么办?
源文件删除,同步就读取不到数据,把中断写入日志,直接同步下一条数据。
问题二:同步到中途,服务器宕机,如何解决?
Make,binlog 同步文件,记录同步偏移量,时间戳。 服务器宕机,下次重新启动,重新加载同步文件,发现没有同步完成。
问题三:此时需要下载文件,如何确定从那台storage服务器下载文件呢? 此时服务器同步未完成?
访问不到文件,如何解决?
所有文章都是以专栏系列编写,建议系统性学习,更容易成为架构师!
博主每天早晚坚持写博客给与读者价值提升,为了让更多人受益,请多多关照,如果觉得文章质量有帮助到你,请关注我的博客,收藏此文,持续提升,奥利给!
另外我不打算靠运营方式拿到博客专家的认证,纯纯的科技与狠活来征服读者,就看读者的感恩之心了,祝你好运连连。