平安产险Druid0.12.3至0.18.1升级实践

平安产险Druid0.12.3至0.18.1升级实践

版本：0.12.3升级至0.18.1（以下简称新旧版本）

应用场景：多维分析，主离线，极少实时。

集群规模：25台主机

数据规模：约50W个segment

主体思路

在保证兼容性、可回滚、用户接受的前提下，停止服务，分层升级Druid各模块。功能测试、性能测试。本次升级采用完全停止服务的方式。（文末提供不停机升级的思路）

兼容性测试

1. 测试新版本能否加载旧版本的数据并正常使用；
2. 测试新旧版本来回切换能否保证底层数据格式兼容、元数据库兼容。（考虑升级失败可回滚）；
3. 新版本与上层应用的兼容性测试，主要是API；
4. 实时任务兼容测试；
5. 测试旧版本能否加载并使用新版本摄入的数据。把大体量的升级过程拆分，升级服务集群前先升级摄入组件。

数据摄入

我们的数据摄入与数据服务是分离的，即使用Hadoop Indexer的模式，Indexer由调度系统定时启动。我们在升级服务集群前已先热升级了摄入组件，升级服务集群时要不影响数据摄入主要关注元数据库状态。具体有两个方案：一，暂停数据摄入，升级后再恢复；二，找个摄入任务少的时段升级，如果升级正常则新摄入的数据能正常加载，升级异常回滚元数据库会丢失少量新摄入数据，摄入任务重跑即可。我们采用了第二种，因为我们已经测试过就算升级失败，两版本来回切换不会造成元数据库异常，数据仍能正常加载。即我们做到了，升级的同时不影响数据摄入。

Historical数据加载

Druid的数据需要从深度存储HDFS拉取到本地再进行加载。我们升级的集群包含近70TB segment cache，若完全从HDFS重新拉取，将非常耗时。故本次升级采用Historical节点原机升级的方式，直接使用旧版本拉取的本地数据进行加载，大大省去了从HDFS拉取的过程。

关于回滚

Druid依赖HDFS与元数据库，只要保证HDFS与元数据库可回滚则可保证整个Druid集群可回滚。其中HDFS只要不在新版本中手动永久删除数据，则HDFS上旧的数据不会变更、丢失。元数据库可以进行备份，异常则还原即可。

升级计划

1. 提前发布维护通知；
2. 实时任务备份；
3. 实时任务下线；
4. 关闭所有Druid节点；
5. 元数据库备份；
6. 部署新版本；
7. 等待数据加载，预计4小时，最坏情况从HDFS拉需要1天；
8. 重上线实时任务；
9. 上层应用验证（我们在测试环境使用新版本2个月没问题才进行的本次升级）；
10. 升级完成，发布通知。

回滚方案

1. 关闭新版本节点；
2. 重启旧版本节点（万一由于元数据库异常无法重启则还原元数据库。当然这一点已经测试，版本来回切换不会影响元数据库，两个版本的建表语句也检查过）；
3. 等待数据加载，预计4小时，最坏情况从HDFS拉需要1天；
4. 重上线实时任务；
5. 升级失败，通知各方。

实际升级过程

1. 提前通知各方；通知运维关闭告警；
2. 实时任务备份、下线；
3. 开始升级。关闭旧Coordinator，使用独立的ZK启动Master、Query（HDFS、元数据库用同一个），拿1个数据量最小（节点重启加载快）的historical tier先升级，做验证。整体功能没问题；
4. 关闭Master节点（避免部分节点先加载完成进入balance状态），停机升级所有Historical节点，50W个segment开始重新加载；
5. segment加载完成后重启Master节点，开始全面测试。测试过程发现SQL功能无法使用，处理后恢复服务；
6. 实时任务重上线；
7. 上层应用测试；
8. 压测；
9. 升级完成，通知各方。

升级过程遇到的问题与解决

此处感谢腾讯游戏的@明亮

1. 新UI页面的部分子页面打开缓慢。与社群交流，有人反馈遇到类似问题：当集群数据量较大（约50W个segment）时会出现，属“正常情况”。测试后也验证不影响摄入及查询，留后续优化；
2. Query节点重启后，DruidSchema无法刷新，JSON查询能用而SQL查询无法使用。在日志中发现以下信息，猜测可能是集群数据量太大，broker从historical拉取数据时超时了（当时超时设置的是10s，是根据我们的应用场景设置的，控制业务查询）。调整参数[druid.server.http.defaultQueryTimeout]10000为60000，重启后SQL功能恢复。尽管集群已能正常使用，后续需到源码中再次验证该猜测。

   2020-07-04T02:33:00.000 WARN [DruidSchema-Cache-0] org.apache.druid.sql.calcite.schema.DruidSchema - Metadata refresh failed trying again soon.
   org.apache.druid.utilmon RE: ] url[此处屏蔽host/druid/v2/] timed out.
   ... ...
   

    

后续规划

1. 前两周重点关注新版本运行情况，保证稳定性；
2. 回看升级过程遇到的问题 ；
3. 两周观察期后，分批尝试使用新特性，优化底层存储与资源分配等。

不停机升级思路（未实践，仅供参考）

需要与原版本相同资源的一套机器环境。ZK新旧版本独立；HDFS共用（无更新操作，共用不影响）；元数据库共用，新版本使用一个只读的用户访问，避免新版本更新元数据库。然后启动新版本集群，两版本集群并行。对新版本进行全面验证，验证通过则切换入口，旧版本下线，提高元数据库权限（验证失败则新版本集群下线）。升级完成。