关于config shard的状态不正常的处理

我写关于12.2 sharding database的文章已经好久了,今天再次把环境启动了起来,启动了主机之后,依次启动了listener和shardcat数据库和shard node数据库实例。检查shard状态的时候,发现报错:

(a)问题一:status显示warnings:

遇到这样的情况,我们可以使用recover shard的命令。注意recover shard -h出来的帮助是错误的。

正确的用法应该是recover shard -shard

我们运行这个命令,发现是gsm没有启动:

启动后,稍等片刻(大约10秒),检查状态就恢复成正常了(在这里,我们还没有真正用到recover shard,在下面一个问题时才正常用到):

所以,重新启动之后,需要启动的有database,listener,和gsm。

(b)问题二:state显示ddl error
然后,在接着的实验中,我drop掉shardcat上的一个duplicate table,发现此时shard状态又不正常了。config shard的state显示ddl error。

首先,在shardcat上操作,drop掉duplicate表

发现此时数据并没有同步,在shard node上,还是可以查询到数据:

此时检查shard状态,变成DDL error:

我们可以在gsm的alertlog中看到一些提示信息:
(注:gsm的日志位置在/u01/ora12c/app/oracle/diag/gsm/sdb1/sharddirector1/trace/alert_shardcat.log)

其实,从这个log中,我们只是看到有ORA-01031 insufficient privileges的报错,但究竟是什么权限不足,我们还是得通过config shard命令来进一步看:

我们看到这个last failed ddl,是alter database link的时候出现权限不足。

所以我们找到了原因,进行修复:

可以看到,在修复问题的基础上,运行recover shard -shard 之后,就恢复了正常。

注意需要注意的是,如果root cause没找到,不知道是database link的权限问题,仅仅运行recover shard是没有效果的。

另外我们也要注意,除了一开始给app_schema的相关权限(一开始赋予的权限,见『创建Oracle sharding database』),我们还要给app_schema于alter database link的权限。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据