我是把所有表名导出，放在一个MySQL库中，然后使用 length 和 lengthb，计算表名，如果这两个函数计算出的结果不相同，那么就是有中文表名了。

问题解决了，就是DataStudio上边有一个选择Schema的下拉菜单（未登录前，叫默认架构），正常就是用户的默认Schema，也不知道怎么就变了（可能是用户误 点，或者是鼠标滑轮改变），然后默认Schema就变成其它人的了，然后建表就在其它Schema下了。

今天又有一个人发生了同样的问题。然后执行了show search_path;命令，果然是  search_path 发生了变化不是默认的$user,public了。这就很奇怪，问用户说执行过什么命令，都说是正常的创建SQL，还有什么可能导致search_path发生变化吗？

今天又有一个人发生了同样的问题。然后执行了show search_path;命令，果然是  search_path 发生了变化不是默认的$user,public了。这就很奇怪，问用户说执行过什么命令，都说是正常的创建SQL，还有什么可能导致search_path发生变化吗？

这种我也怀疑过，是一个用户跟我反馈的，我也不知道前面执行过啥，然后我从CN的日志里没有找到切换schema的命令。 只有等下次出错的时候，看一下search_path的值。 后来那个用户重新登录就好了。

这个zhangsan  schema 在SQL语句中没有提到。建表时也未指定使用zhangsan  schema ，就是突然报这个错误，感觉奇怪。

连接的数据库肯定对，那个IP下面就一个业务库。 用户的账号叫lisi,默认使用lisi同名schema，即使报错也应该报lisi的schema没有权限。不知道为何会与zhangsan  schema有联系。 后来就退出重进就好了。

主要参考 华为MPP数据库手册中的这个文章，比较重启的是在/etc/fstab中注释掉挂载信息后，一定要重启，我就没重启再挂怎么也挂不上，提示not blank disk，重启以后就挂上了。OM DB分区目录挂载硬盘故障

昨天又查了iptables的防火墙，在原来的命令加上 -n 参数，就不显示主机名了，而是VIP是址。iptables -t mangle --list -ntarget     prot opt source               destination         DR-I       all  --  anywhere             anywhere            MARK       tcp  --  anywhere             VIP          tcp dpt:25308 MAC ! xx:xx:xxxx:xx:xx MARK set 0x1这样就说明不是iptables中缺少规则的问题，这也能解释了1日至15日运行正常的原因。然后判断还是LVS  的fwmark  功能有问题导致的，具体什么原因不明。

已解决，等有空的时候，我分享一下过程。这个Manager的修复比修复DN还更自动化，不错。基本上挂载上格式化磁盘，重新挂载/srv/BigData/dbdata_om目录，设置好目录的权限就自动同步数据了。