解决方式

各主机之间是否配置了互信。
或在命令后添加 password’xxxx’选项。
下面给出一个示例说明：

postgres=# start agent all;
hostname | status | description
----------+--------+-------------------------------------------
antdb01 | f | Authentication failed (username/password)
antdb02 | f | Authentication failed (username/password)
(2 rows)

postgres=#
postgres=# start agent all password'123';
hostname | status | description
----------+--------+-------------
antdb01 | t | success
antdb02 | t | success
(2 rows)

原因说明

AntDB的mgr通过ssh远程管理各节点，因此需配置ssh互信或添加password选项。

解决方式

.bashrc 环境变量中，是否设置了如下环境变量LD_LIBRARY_PATH

export LD_LIBRARY_PATH=$ADB_HOME/lib:$LD_LIBRARY_PATH

原因说明

某些特殊软件或插件，只识别.bashrc而不识别 .bash_profile，添加后退出终端重新登录。

解决方式

由于adb批量导入时，刷新速度太快，该错误信息并非最原始的错误。
添加-v ON_ERROR_STOP=1选项，即可看到最原始的错误信息。

adb -p xxx -d xxx -f xxx.sql -v ON_ERROR_STOP=1

原因说明

产生该错误的原因较多。如 adb导入的表结构未创建、表上某列存在自增序列却没有创建。
请结合上述参数重新执行adb导入后，确认原始错误信息后，对症下药即可。

解决方式

目标列与表结构的列不匹配。

原因说明

查询语句中的目标列与表结构的列不匹配，或多或少，请仔细检查。

错误信息中出现如下提示：you can modfiy guc parameter “waitglobaltransaction” on coordinators to wait the global transaction id committed on agtm

在每个dn主库上，查询接受事务快照进程：postgres: snapshot receiver process，然后ps把这个进程的pid找出来，kill -15

报错的cn上，建个表写写数据验证问题是否已经修复。

原因说明

部分节点的事务状态和gtm的不一致，在节点内，可以通过select adb_xact_status(xid);来查看事务状态，kill上面的进程，目的是让节点重新同步一下gtm的事务状态。

解决方式

该错误出现在CN节点执行SQL操作时；
在报错的CN节点查询adb_snap_state()扩展试图：
select * from adb_snap_state();
--如果提示不存在则在对应的数据库下创建该插件即可：create extension if not exits adb_snap_state;
检查查询结果global_xmin和local oldest_xmin、local global_xmin差值是不是较大，如果差值较大说明该CN事务和GTMC事务同步存在异常，需要采取如下方式触发手工同步：
找到CN进程下的postgres: snapshot receiver process进程号，并尝试kill -15 该进程号（注意：一定要是kill -15不可以-9或者其他），执行完成即可。

原因说明

产生该错误的原因可能是CN节点和GC节点事务号未及时同步导致的，可以手工触发同步；

解决方式

请检查输入的密码是否正确？
此处的密码指该用户his在数据库中对应的密码，非操作系统登录密码。

原因说明

密码不正确，请确认密码的正确性。

在类似pt-osc场景下，需要将两个表名对调，怎么才能确保万无一失？
想要的是同时完成表名对调，如果是先后的对掉，相互RENAME一下，可能会导致有些数据写入失败。
可以同时锁定2个表，不允许写入，然后对调表名。
LOCK TABLES t1 WRITE, t2 WRITE;
ALTER TABLE t1 RENAME TO t3;
ALTER TABLE t2 RENAME TO t1;
ALTER TABLE t3 RENAME TO t2;
UNLOCK TABLES;

在个别时候可能需要查看当前最新的事务ID，以便做一些业务逻辑上的判断（例如利用事务ID变化以及前后时差，统计每次事务的响应时长等用途）。
数据引擎为MDB：
查看INFORMATION_SCHEMA.MDB_TRX、MDB_LOCK两个表，通过这些信息能快速发现哪些事务在阻塞其他事务。
数据引擎为Innodb：
执行SHOW ENGINE INNODB STATUS，查看事务相关信息；
查看INFORMATION_SCHEMA.INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS三个表，通过这些信息能快速发现哪些事务在阻塞其他事务。