内容纲要
概要描述
HDFS 分为 客户端（client）和 服务端（server），hdfs 在提交执行时加载的是 客户端（client）的本地的 library，所以会出现某些异常情况，比如：
- hdfs getconf -confKey <> 命令获取数据和集群实际配置不一致
- hdfs 提交命令失败，连接的 namenode 和实际的namenode 不一致
详细说明
hdfs 命令在提交执行时，首先判断命令是否正确，然后加载本地的配置项，远程调用安全认证，通过之后执行；
2020-01-13 17:59:21,580 DEBUG util.NativeCodeLoader: Trying to load the custom-built native-hadoop library...
2020-01-13 17:59:21,580 DEBUG util.NativeCodeLoader: Loaded the native-hadoop library从以上的顺序可以看出，当hdfs 在获取配置时，是优先加载本地的客户端配置，所以当客户端和 hdfs server 端不一致，会出现以下异常情况。
案例1：getconf
当使用命令 hdfs getconf 可以查看hdfs的参数值。但是实际使用发现，在 8180 页面修改或者新增的参数值通过这个命令查看后，读取的还是原来的默认参数值：
针对该问题的解决方案有两种：
- 更换最新的 hdfs 的客户端，在TDH 集群中也就是更换 TDH-client
- 在 hdfs 的任意角色的 pod 内执行，pod 内的 hdfs 客户端工具加载的是最近的配置；
案例2：迁移 namenode
当 HADOOP 集群迁移之后，如果客户端没有及时更新，会出现 hdfs 连接迁移之前的 namenode 的情况；
比如迁移之前 namenode 在 tdh-01 和 tdh-02上；迁移之后变成 tdh-02 和 tdh-03；
迁移后 tdh-03 变成了 active 的 namenode，
此时需要连接 namenode 的命令（比如 hdfs dfs -get /tmp/testdata），在连接时会连接原来的 tdh-01和 tdh-02，此时 tdh-01 上已经没有 namenode，而tdh-02 是standby 的无法提供服务，此时执行的 get 命令也就报错连不上 namenode 的 8020 端口失败。
针对该问题的建议的解决方案如下：
- 更换最新的 hdfs 的客户端，在TDH 集群中也就是更换 TDH-client