数据库‖上千节点Hadoop集群升级过程分享

在上一次我进行了超万亿规模的Hadoop NameNode问题的排查，通过为时四天的努力，终于解决了Hadoop2.6.0版本的瓶颈问题，但是生活往往就是墨菲定律，你所极力避免的那些最坏的可能也许终将会发生。

为了防止遇到NameNode的第二次瓶颈，我决定将当前集群由Hadoop2.6.0版本升级到Hadoop3.2.1版本，且启用联邦模式。但是在升级之后，我们还是遇到了很多意向不到的问题，虽然最终经过一系列的排查还是解决了这些问题，但是我认为这次集群的升级经验能够帮助一些同学少走弯路。

下面，enjoy：

一、升级前的准备

在进行Hadoop集群升级，尤其是类似本次案例中这样上千节点的超大集群的升级，首先需要明确两点：

第一，是否确实有必要进行集群的升级，以目前的数据增长量级是否会触及当前版本的瓶颈。

首先需要声明一点，像本次案例中这样的超大规模的Hadoop集群，升级本身的难度就极大，需要消耗非常多的人力物力去修改数据库底层源码，仅仅对于我们产品LSQL的源码修改就花费了我们小组整整两周时间。更无需说我下文中会列明的在升级后会遇到的一系列问题的排查和处理，更是需要投入极大的时间精力。

本次我们选择进行Hadoop集群升级的主要原因是由于原先2.6.0版本过老，可能会存在其他未发现的问题。同时客户每天有近千亿条的数据增长，如不进行升级，很快还是会遇到NameNode的第二次瓶颈。如果客户在当前版本系统能够稳定运行，并且未来的数据体量不会有大幅增长，我们也不会采取升级集群的方案。

第二，是否做足了升级前的准备工作，以及是否有应对升级出现的各类问题的应急方案。

在本次升级前我们就做了大量的前期准备工作。我们进行了多次的升级演练，确保能应对在升级过程中出现的各类突发情况。同时鉴于客户数十万亿的生产系统的特性决定了在升级过程中决不能出现丢失数据或者服务长时间停止的情况。为此，我们制定了一旦升级出现问题就会采取的系统回退方案，遭遇数据丢失的挽回方案，以及在升级后的功能性验证等。

二、 升级后所出现的问题&解决

1.Hadoop跨多个联邦后，速度不快反慢

理论上，Hadoop升级成跨联邦机制，读写请求会分别均衡到三个不同的NameNode上，降低NameNode负载，提升读写性能，然而事实是NameNode负载不但没有降低，相反变得非常非常慢。

对于目前集群的卡顿程度，是肯定无法满足生产系统的运行需求的。而此时升级已经进行了三天了，如果卡顿问题不能得到解决，哪怕我们心有不甘也只能立即启动回退方案。但是毕竟我们都为这次升级准备了许久，而且客户也很期待升级后所带来的性能提升，我轻轻抚了抚头顶那沉睡多年的毛囊，一狠心决定连夜奋战。

首先需要做的就是定位造成卡顿的原因，我先从堆栈入手，发现主要问题还是NameNode卡顿，生产系统已经不能继续调查下去了，如果不想回退系统，就得让系统可用，那就只能从我们最熟悉的地方下手—修改录信LSQL，给所有请求NameNode文件的地方加上缓存，只要请求过的文件，就缓存下来，避免二次请求NameNode。

录信LSQL修改后NameNode状态有非常大的改善，系统基本可用。但具体为何升级到联邦后NameNode的吞吐量不升反降，我们没能给出合理的解释，只能初步断定是由于历史数据还在一个联邦上，导致数据的分布不均衡，希望之后能随着新数据的逐步导入，重新形成一个较为均衡的态势。

2.升级联邦后数据库稳定性降低，极易挂掉

在进行升级之后，我们发现几乎每隔几天我们的数据库系统LSQL就会挂掉一次。

观察录信LSQL的宕机日志，发现有大量的如下输出，证明Hadoop NameNode经常位于standby模式，导致Hadoop服务整体不可用，从而引起录信LSQL数据库宕机。