GBase 8a做节点替换操作后，包含调度服务gclusterd时，会检查新节点的表数量和其它节点是一样。读取的是information_schema.tables，如果不可读或者不一样，则会报错check table number failed after drop temporary db。
目录导航
报错样例
直接replace.py报错信息gcadmin replace nodes failed
其中报错位置，是在集群状态已经恢复正常了：restore cluster mode start和restore cluster mode end .结合前面的set table dml storage event 日志，确认集群服务安装，数据同步都已经操作完毕，进入恢复和检查阶段才报错。
手工执行报错信息
手工执行gcadmin replacenode 报错信息如下：check table number failed after drop temporary db
因为replace.py内部调用了gcadmin replacenodes，但没有输出错误信息，手工调用则多了如上的错误日志check table number failed after drop temporary db
排查
报错信息：check table number failed after drop temporary db的原因是新恢复的节点包含了gclusterd的调度服务，且查询information_schema.tables表时发现表数据量和其它正常调度节点不一致。
select count(*) from information_schema.tables根据项目经验，发下如下几种情况会出现这个问题
用户创建了gssys引擎的表
gssys表都是本地表，每个节点不保证一样多。比如在某个调度节点自行创建了一个 gbase.audit_log_BAK表。
解决方法：删除多余的gssys表。
用户新数据库无法查询
因为某些参数问题，导致新库无法查询tables表。比如tmpdir设置到一个不存在的或不可写入的目录。则会报错:can't create/write to file
查看目录确实不存在，因为节点替换服务并不负责创建用户自行设置的tmpdir目录。
解决方法：创建tmpdir目录并赋予数据库读写权限。
解决
排除问题后，重新运行节点替换操作即可。
gcadmin replacenodes [bad node ip] db_root_pwd sync_coordi_metadata_timeout [minutes] retry_times [count]一个样例如下
