趣解 ceph rgw multisite data sync 机制

    multisite是ceph rgw对象数据异地容灾备份的一个有效方案，笔者但愿深刻理解该技术，并应用于生产环境中，然而rgw的这部分代码晦涩难懂，笔者屡次尝试阅读，仍云里雾里不解其意，最终流着泪咬着牙坚持多看了几遍，总结出了data sync的流程，这里以通俗易懂的形式呈现出来，但愿对你们有所帮助~

数据同步流程图

https://www.cnblogs.com/wangmingshuai/articles/11040979.html

 

首先，认识下 data sync机制 的三个角色Data、DataLogShard、BucketShard

    rgw的multisite同步分为两部分：metadata数据同步 和 data数据同步。metadata数据包括bucket信息、bucket instance信息、user信息等；data数据指的是存储的对象的实际数据，即Data。本文仅涉及data数据的同步。
    rgw使用datalog来记录Data的变化，为防止datalog成为瓶颈，将datalog分红了${rgw_data_log_num_shards}个shard，即DataLogShard。全部的 DataLogShard 的数据变化就反应了Data的变化。
    rgw使用bucket index来提高list对象的效率。为防止bucket index成为瓶颈，将bucket分红了${rgw_override_bucket_index_max_shards}个shard，即BucketShard。每一个BucketShard的bucket index log记录了该BucketShard对象的变化。
    rgw的每一个BucketShard都会经过hash映射到某个DataLogShard上，造成了以下形式的映射关系。理解映射关系是理解data sync的重要前提。
          DataLogShard ...   :   ...
          DataLogShard 12 ：  bucket_a:0、bucket_b:3
          DataLogShard 13 ：  bucket_a:四、bucket_b:七、bucket_c:5 ...
          DataLogShard ...   :   ...
    当某个BucketShard的数据发生变化时，对应的DataLogShard的datalog会记录哪一个BucketShard发送了数据表更。

咳咳，讲完data sync的三个角色，下面切入主题讲讲data sync的故事

    data sync的目标是将 源头rgw Data 都同步到 目标rgw 中。话很少说，系好安全带，老司机直接带你走一遭data sync流程。
    故事是这样的，北京rgw想要开拓上海的市场，因而派DataSync去上海建立rgw并负责把北京rgw的数据资源同步到上海rgw，即data sync（北京rgw -> 上海rgw）。
    老大DataSync到达上海，来掌控整个data sync流程的进度。前面说了，全部的DataLogShard的变化即反应了rgw Data的变化。老大DataSync决定招聘${rgw_data_log_num_shards}个 小弟DataLogShardSync 来负责将北京rgw中的数据同步到上海rgw，每一个小弟负责北京rgw的一个DataLogShard。老大DataSync懂得，数据同步不是一蹴而就的，他只有记录下同步的进度来，才能防止意外的同步失败而致使须要从头开始数据同步。
    因而老大DataSync用名为rgw_data_sync_info的记录来规划了他第一阶段工做为StateInit，并记录了他有${rgw_data_log_num_shards}个小弟DataLogShardSync要进行数据同步。
    struct rgw_data_sync_info { uint16_t state; uint32_t num_shards;}

① 老大DataSync::StateInit：
    老大DataSync须要给他num_shards个小弟DataLogShardSync设定KPI，毫无疑问，小弟DataLogShardSync的目标是遇上北京rgw的数据更新进度，老大DataSync打电话问北京rgw各个DataLogShard数据的最新marker记录成小弟的next_step_marker，并记录各个小弟DataLogShardSync的同步状态为FullSync，整理到rgw_data_sync_marker中 。
    struct rgw_data_sync_marker {uint16_t state; string next_step_marker;}
    老大DataSync将本身的工做进度（rgw_data_sync_info ）和直属小弟的工做进度（rgw_data_sync_marker）都记录了下来到了rgw_data_sync_status中。
    struct rgw_data_sync_status {
        rgw_data_sync_info sync_info;  // 记录data sync的总体同步进度
        map sync_markers;  // 记录每一个DataLogShard的同步进度
    }
    这样，老大DataSync作完了第一阶段StateInit的工做，规划作下一阶段StateBuildingFullSyncMaps的工做。

② 老大DataSync::StateBuildingFullSyncMaps：
    老大DataSync说，北京rgw的datalog会进行截断，若是经过datalog来同步数据到上海rgw，会致使一些数据同步不过来，因此须要进行下FullSync。而进行FullSync就是将小弟DataLogShardSync都管辖着的各个小喽啰BucketShard中的对象逐一list出来，而后从北京rgw传输到上海rgw。由于须要知道小弟DataLogShardSync分别管辖着哪些小喽啰BucketShard。老大打电话问了北京rgw，并将这些信息（每一个DataLogShard下有哪些BucketShard）记录下来。
    这样，老大DataSync作完了第二阶段StateBuildingFullSyncMaps的工做，规划下一阶段StateSync的工做。

③ 老大DataSync::StateSync：
    老大在这个阶段的主要工做是，监督小弟工做，老大前面已经规划了小弟的第一阶段工做是FullSync，小弟DataLogShardSync因而开始循序渐进的工做。

④ 小弟DataLogShardSync::FullSync：
    小弟DataLogShardSync做为中层干部，须要管理下属的各个小喽啰BucketShardSync，使用rgw_bucket_shard_sync_info来记录下属的每一个小喽啰的工做状况。
    struct rgw_bucket_shard_sync_info {
        uint16_t state;
        rgw_bucket_shard_full_sync_marker full_marker;
        rgw_bucket_shard_inc_sync_marker inc_marker;
    }
    一样地，小弟DataLogShardSync须要给下属的各个小喽啰BucketShardSync安排工做。小弟将小喽啰BucketShardSync的第一个阶段工做设定为StateInit。嗯，小弟的工做完成了，真简单，轮到小喽啰干活了。

⑤ 小喽啰BucketShardSync::StateInit:
    虽然小弟没有给下属小喽啰设定KPI，但小喽啰BucketShardSync很自觉，本身打电话给北京rgw问到了其对应的BucketShard的最新marker，而后记录到本身的rgw_bucket_shard_sync_info的inc_marker中。意思是，要先full sync（全量同步）到这个marker，而后从这个marker开始inc sync（增量同步）。
    这样，小喽啰的第一阶段工做完成了，准备进入下一阶段StateFullSync。

⑥ 小喽啰BucketShardSync::StateFullSync:
    在这个阶段，小喽啰会批量从北京rgw查询其对应的BucketShard中的对象，同步到上海rgw，并持续更新full_marker，直到本身的rgw_bucket_shard_sync_info的inc_marker。结束后，小喽啰规划进行下一阶段工做为StateIncrementalSync。

嗯哼，full sync（全量同步）结束，进入inc sync（增量同步阶段）。

⑦ 小弟DataLogShardSync::IncrementalSync：
    进行完full sync，终于能够根据datalog的变化来inc sync了。打电话问问北京rgw自从上次同步点，有哪些下属小喽啰BucketShardSync对应的BucketShard发生数据变动。而后，安排这些小喽啰单独进行工做。

⑧ 小喽啰BucketShardSync::StateIncrementalSync:
    小喽啰打电话到北京rgw，问从本身的inc_marker开始，有什么新的数据变动，而后根据数据变动来同步数据。

至此，data sync的故事讲完了...

故事太长都忘了？来个简易版：
老大DataSync::StateInit：
    更新各个DataLogShard的同步目标为北京rgw的各个DataLogShard的最新marker
老大DataSync::StateBuildingFullSyncMaps：
    记录各个DataLogShard下有哪些BucketShard
老大DataSync::StateSync：
    安排小弟干活
小弟DataLogShardSync::FullSync：
    安排小喽啰干活
小喽啰BucketShardSync::StateInit：
    更新本身的同步目标为北京rgw对应BucketShard的最新marker
小喽啰BucketShardSync::StateFullSync ：
    干活干到本身的目标
小弟DataLogShardSync::IncrementalSync：
    根据北京rgw的DataLogShard的更新状况，继续安排小喽啰干活
小喽啰BucketShardSync::StateIncrementalSync：
    根据北京rgw的对应BucketShard的更新状况，继续干活

友情出演：
老大DataSync：
    控制着整个data sync流程的同步进度。标识进度的状态有三个：StateInit、StateBuildingFullSyncMaps、StateSync。
小弟DataLogShardSync：
    控制着一个DataLogShard的同步进度。标识进度的状态有两个：FullSync、IncrementalSync。
小喽啰BucketShardSync：
    控制着一个BucketShard的同步进度。标识进度的状态有三个：StateInit、StateFullSync 、StateIncrementalSync。

番外篇：
    上海rgw的全部工做人员集体出走了，上海rgw新招了一堆新人，若是保持数据同步呢？新人根据rgw_data_sync_info获知rgw data sync的进度为StateSync，而后根据rgw_data_sync_marker获知各个DataLogShard的同步状态为IncrementalSync，而后根据rgw_bucket_shard_sync_info的获知各个BucketShard的同步进度为StateIncrementalSync。因而，轻松交接工做，继续干活同步数据，即
DataSync::StateSync -> DataLogShardSync::IncrementalSync -> BucketShardSync::StateIncrementalSync

同步流程图

https://www.cnblogs.com/wangmingshuai/articles/11040979.html

关注笔者

专一笔者公众号，阅读更多干货文章：）