RHEL6.9组建Redis sentinel集群遇到两个问题
今天在组件Redis sentinel 集群时，遇到两个问题，之前已经组建多次，都没碰到类似问题，在解决这两个问题时，耗费些时间。
问题1. ./redis-server: /lib64/libc.so.6: version `GLIBC_2.14' not found 问题
在将A服务器 RHEL6.9 上已经编译好的 Redis-3.0.3 整个目录，scp 到 RHEL6.9 服务器B上，
在 A 上能正常运行的redis-server程序，但在 B 服务器上却执行失败，在 B 服务器redis中的src目录下使用指令 ldd redis-server 可以看到如下的报错，
B 服务器ldd结果：
$ldd redis-server
./redis-server: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./redis-server)
linux-vdso.so.1 => (0x00007ffd3fbc7000)
libm.so.6 => /lib64/libm.so.6 (0x0000003e49a00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003e48a00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e49200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003e48e00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003e48600000)
但是在 A 服务器上进行如上的命令，却正常，并没有not found。
A 服务器ldd结果：
$ldd redis-server
linux-vdso.so.1 (0x00007ffdcdb5b000)
libm.so.6 => /lib64/libm.so.6 (0x0000003940e00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003940600000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003940200000)
libc.so.6 => /lib64/libc.so.6 (0x000000393fe00000)
/lib64/ld-linux-x86-64.so.2 (0x000000393fa00000)
这就奇怪了，但是细心观察，就能发现 /lib64/libc.so.6 () 的值是不一样的，初步怀疑是由于在 A 机器上编译环境和 B 上是不一样的。
利用相关指令查看 libc.so.6 中是否一样：
A 服务器查看 libc.so.6 内容：
$ strings /lib64/libc.so.6 |grep GLIBC_
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_PRIVATE
B 服务器查看 libc.so.6 内容：
$ strings /lib64/libc.so.6 |grep GLIBC_
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_PRIVATE
上述指令对比就能看出，B服务器的 GLIBC 版本较低，虽然都是RHEL6.9操作系统，但内部库还是有些不一样的地方。
对应的解决方法有如下几种：
- 在 B 的环境中，直接进行 redis 源码编译，生成的可执行文件能在 B 中成功运行。
- 可以找到与 B 一样的
strings /lib64/libc.so.6 |grep GLIBC_的操作系统环境，在其上编译之后，直接将可执行文件拷贝到B上运行。 - 升级 B 服务器的 GLIBC。
- 可在redis源码中添加约束，显式指定所依赖的memcpy函数的GLIBC版本，需添加的约束代码如下：
__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");,【注意】只需在调用函数memcpy的源文件中加入此约束,该方法读者可以自行验证，后面参考链接中有相关博客介绍。
我是选择了方法2解决的上述报错问题，找到一个 strings /lib64/libc.so.6 |grep GLIBC_ 和 B 服务器一样的内容，重新拷贝redis相关文件到 B 服务器中，执行redis进程成功。
问题2. ps -ef 进程 uid 不显示用户名而是数字
在上述redis于 B 服务器成功执行后，ps 进程发现第一纵列不是显示用户名，而是用户名的uid一串数字
$ ps -ef|grep redis
31241 129637 125617 0 17:53 pts/3 00:00:00 ./src/redis-server *:6358
31241 129866 1 0 17:55 ? 00:00:00 ./src/redis-sentinel *:16358 [sentinel]
在使用linux有一段时间，没遇到过这种现象，一般显示都直接是用户名，这样ps就知道该进程是哪个用户启动并有权限停止的。linux中是严格区分用户，不同非root用户对不同进程文件目录等有不同操作权限，可以使得多用户使用同一台服务器时的安全。
通过man命令查看ps命令的说明： 8位用户名的账户能够显示完整的用户名，9位用户名的账户就显示了UID。
当用户名的长度(用户名字符串的字符个数）大于8（默认）时，只会显示用户的UID, ps的这个长度可以自定义，如下命令：
ps -o ruser=thereisusername -e -o pid,ppid,c,stime,tty,time,cmd|grep xxx
说明：“thereisusername”是自定义填写的字符串,Linux会自动检查此字符串的长度，用户名长度比该字符串小的都会显示用户名。
在Redis使用和学习中，遇到上述问题，特此总结记录，加深影响，一点一滴积累Redis和Linux相关知识。
参考链接：
https://blog.csdn.net/Jin_Kwok/article/details/80319441?utm_source=blogxgwz7
https://blog.csdn.net/weixin_34294649/article/details/91699158
本人才疏学浅，如有错误不当之处，请批评指正，如有侵权，请立即联系我进行删除。
如果能为您带来一点点帮助，我将十分高兴，也多谢您关注:hongmaolinux 和转发推荐，谢谢！
