| DataNode升级后降级失败 |
DataNode升级后，DataNode layoutVersion不兼容，HDFS 3.x DataNode降级到HDFS 2.x DataNode无法启动。 |
1,4,5,6 |
HDFS-8791 |
| 升级后手动 Failover Namenode 失败 |
Namenode Failover 时，Standby Namenode 转变成 Active 过程中初始化 Quota 的时间超过了zkfc超时时间，所以Standby Namenode 挂掉。初始化 Quota 线程数默认值为4 ，增加dfs.namenode.quota.init-threads 后解决。 |
5 |
HDFS-8865 |
| DataNode坏盘问题导致无法服务 |
DN里突然出现的坏盘会导致DN处理Rolling Upgrade信息操作出错，DN无法服务 |
6 |
HDFS-8893 |
| NameNode升级DatanodeProtocol.proto不兼容 |
Hadoop3中改变了HeartbeatResponseProto里部分字段的顺序导致新老版本DN（DataNode缩写）和NN（NameNode缩写）之间无法进行heartbeat操作。 |
1,4,6 |
HDFS-9788 |
| NameNode性能问题 |
Hadoop3里对group组检查的逻辑里做了对象分配的优化，将之前的Set结构存储改成了List的结构。当某个用户属于非常多group的时候，NN需要做繁重的遍历操作去确认其是否是目标访问路径下的group。如下火焰图所示，我们能够看到RPC很多时间花在了isMemberOfGroup的操作检查上。 revert了社区HDFS-10711关于这块的改动 |
6 |
HDFS-10711 |
| 无效的QOP值导致DN SASL认证问题，数据无法读写 |
在新版本逻辑中DN会利用client里传来的QOP值做自身SASL QOP的覆盖，它在这里少了关键的QOP校验操作。当有别的老版本的client端发送了一个无效的QOP值后，就会导致DN SASL认证问题。社区有一个类似的issue JIRA（HDFS-16644 ）但没有最终解决，后来在内部版本里添加了开关直接禁用了此逻辑。 |
6 |
HDFS-13541 HDFS-16644 |
| fsimage结构变化导致NN降级失败 |
Hadoop3 EC功能的引入导致了fsimage的不兼容问题，社区3.3版本已经包含有相关的2个fix（HDFS-14396 和HDFS-13596） |
2，3，4，5，6 |
HDFS-14396 HDFS-13596 |
| StringTable的改动导致的兼容性问题 |
在3.3版本中revet了HDFS-14831里涉及的相关commit解决了这个问题。 |
1，2，3，5，6 |
HDFS-14831 |
| 集群StaleDataNode数量积压导致的性能问题 |
HDFS 2.6.0版本FoldedTreeSet红黑树数据结构导致NameNode运行一段时间后RPC性能下降，集群出现大量StaleDataNode，导致任务读取block块失败。Hadoop 3.4.0 HDFS-13671修复了这个问题，将FoldedTreeSet回退为原来的LightWeightResizableGSet 链表数据结构。我们也将HDFS-13671 patch引入我们升级的HDP HDFS 3.1.1版本。 |
3 |
HDFS-13671 |
| DataNode Du性能问题 |
从内存中计算DataNode使用空间，不再使用Du操作， 完美的解决了DataNode Du性能问题 |
3，4 |
HDFS-14313 |
| Hadoop2 DataNode block token验证失败问题 |
升级过程中 NameNode 和 DataNode 由于数据结构的变化，生成了不同的 password，导致无法认证，读写数据会失败。该 ISSUE 记录了这个问题，需要先升级到 2.x 的最新版本进行过度，之后才能滚动升级到 3.x 版本。 |
2,4,5,6 |
HDFS-14509 |
| JournalNode 升级出现 Unknown protocol |
HDFS 3.x新增了InterQJournalProtocol，新增加的InterQJournalProtocol用于JournalNode之间同步旧的edits数据。 对此问题进行了优化，日志级别从ERROR改成DEBUG。此问题不影响升级，当三个HDFS 2.x JN全部升级为HDFS 3.x JN时，JN之间能正常同步数据。 |
3 |
HDFS-14942 |
| ViewFileSystem的FileSystem instance泄漏问题 |
Hadoop3的ViewFileSystem里引入了内部cache（HADOOP-15565 ）来存放它所创建的FileSystem实例。这个功能改变了之前通过调用FileSystem.get(uri, conf)来实际创建FileSystem instance的逻辑，新的API会每次创建新的实例而老的API会复用已创建的实例。这会导致之前没有close FileSystem实例的应用在切换使用Hadoop3的API后会出现instance泄漏问题，最终导致OOM错误。 解决的办法是client端可以通过设置 fs.viewfs.enable.inner.cache=false 来关闭这个功能。 |
6 |
HADOOP-15565 |
| Hadoop2和Hadoop3之间的StorageType不兼容 |
在集群部分path上设置了StorageType ，但是在NN升级到Hadoop3之后，Hadoop2的client在执行contentSummary call去统计汇总信息时会出现缺少必要字段的错误。 需要client将相关storage type字段从required类型改成optional类型，但这需要client升级到Hadoop3版本来解决这个问题。社区的fix是一个client side的改动，client side的升级需要有一定的时间周期来做，不是当下最优的解决办法。最终通过在NN server端跳过了storage type quota的设置检查来避免了这个问题。 |
6 |
HDFS-15660 |
| HADOOP3Kerberos 认证失败 |
升级观察过程中发现旧版本HDFS 在 Kerberos 认证后去连接 3.1.3 建立连接失败。因为在3.1.3 版本中增加了 hadoop.security.auth_to_local.mechanism 默认值为hadoop ， 不接受带有 '@' 或者 o'/' 的用户名 ，而旧版本Client 在kinit 之后会携带 'test@HADOOP.COM' 这样的用户名去建立连接，所以连接失败。在修改 hadoop.security.auth_to_local.mechanism = MIT 后解决，详见： HADOOP-15996[7] 。反思：考虑集群本身没有开启 Kerberos 认证，在升级测试过程并未把 Kerberos 相关内容划到测试范围内，导致一个故障。以后在测试时要 Involve 更多的依赖方，做更全面的Testing。 |
5 |
HADOOP-15996 |
| 异步删除block造成NN性能下降 |
Hadoop 3.3版本引入了异步删除block的功能（HDFS-16043 ），这个功能在极端场景下会造成NN性能下降的问题。比如当集群在一段时间内有大量块删除的情况，随之会引发DeletedBlock queue的大量堆积，然后NN会lock非常长的时间来做块的异步删除。 将NN delete block的lock时间从hard-coded的500ms改成了可配置化，以此降低此行为带来的潜在性能影响 |
6 |
HDFS-16043 |
| Hadoop3版本加载Openssl 3.x失败问题 |
Hadoop slave机器上所使用的openssl版本是3.0版本，但是Hadoop3版本无法加载这个系列版本，导致HDFS会fallback到默认的JceAesCtrCryptoCodec方法来做数据读写的加解密操作。默认的JceAesCtrCryptoCodec方法在性能上比依赖于openssl提供的加解密算法OpensslAesCtrCryptoCodec方法差很多，最坏情况导致HDFS读写性能可以有1~4倍左右的差距。 |
6 |
HADOOP-18583 |