ER out of sync
A two-node Enterprise Replication setup (IDS 11.5, primary/receive-only) replicated fine, but 'cdr view profile' and 'cdr check repl' run on the standby only reported local data or failed with "Connection to server g_server1 failed". The poster wanted to run a consistency check from the standby to decide whether failover was safe. A suggestion to test a plain dbaccess connection to the other instance pinpointed the cause: the commands were run without the -c option and under the wrong user, so connectivity/permissions failed. Fixing that resolved it. A follow-up question about the performance cost of running cdr check repl regularly on large tables via cron was left unanswered.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
We have a simple 2 node ER deployment (IDS 11.5). One node is active and the other is standby. Data is correctly replicated from active to standby node. But we noticed that commands like cdr view profile cdr check repl are properly executed only on active server displaying data from both nodes, while on standby they display correct data only for that node, or reporting messages like this: -------------- Connection to server g_server1 failed Can not connect to g_server1 ------------ Where g_server1 is the group of active server. Documentation says that all cdr commands can be used on each node. Is it possible to solve this situation?
On 12/11/2010 18:02, Cveja wrote:
> We have a simple 2 node ER deployment (IDS 11.5). One node is active
> and
> the other is standby. Data is correctly replicated from active to
> standby node.
>
> But we noticed that commands like
>
> cdr view profile
> cdr check repl
>
> are properly executed only on active server displaying data from both
> nodes, while on standby they display correct data only for that node,
> or
> reporting messages like this:
> --------------
> Connection to server g_server1 failed
> Can not connect to g_server1
> ------------
> Where g_server1 is the group of active server.
>
> Documentation says that all cdr commands can be used on each node.
>
> Is it possible to solve this situation?
>
>
>
>
>
Hmmm ... are ALL your replicates Primary / Receive only?
Can you on the standby server do dbaccess / connect / "Standy instance"
using any of the DBSERVERNAME / DBSERVERALIAS / group name (obviously
TCP connections only)
You state "ER out of sync" - is there actually data queuing up on the
active? What does cdr list server show?
On 12 нов, 19:51, "Jonny...@Usenet-News.net" <Jonny...@Usenet-
News.net> wrote:
> Hmmm ... are ALL your replicates Primary / Receive only?
Yes.
> Can you on the standby server do dbaccess / connect / "Standy instance"
> using any of the DBSERVERNAME / DBSERVERALIAS / group name (obviously
> TCP connections only)
We didn't try that. I can't check whether it works at the moment, but
I
certainly will on Monday.
> You state "ER out of sync" - is there actually data queuing up on the
> active?
No, replication is OK, but we are testing failover scenario.
Actually, we need a way to know in the case of failover, using standby
node, whether the tables in replication are out of sync with the
active
server. We need to know whether it is safe to promote standby server
to
active. We thought we could use consistency check (cdr check repl)
from
standby node. And that's when this problem showed up.
-->> server. We need to know whether it is safe to promote standby
server
-->> to
-->> active. We thought we could use consistency check (cdr check
repl)
Do not get me wrong here ER is great however when i read above
is it not easyer to use HDR instead of ER in your situation???
(unless of course you have byte and text data in oldfashion
blobspaces..)
Superboer
On 13 nov, 01:06, Cveja <niko...@gmail.com> wrote:
> On 12 нов, 19:51, "Jonny...@Usenet-News.net" <Jonny...@Usenet-
>
> News.net> wrote:
> > Hmmm ... are ALL your replicates Primary / Receive only?
>
> Yes.
>
> > Can you on the standby server do dbaccess / connect / "Standy instance"
> > using any of the DBSERVERNAME / DBSERVERALIAS / group name (obviously
> > TCP connections only)
>
> We didn't try that. I can't check whether it works at the moment, but
> I
> certainly will on Monday.
>
> > You state "ER out of sync" - is there actually data queuing up on the
> > active?
>
> No, replication is OK, but we are testing failover scenario.
> Actually, we need a way to know in the case of failover, using standby
> node, whether the tables in replication are out of sync with the
> active
> server. We need to know whether it is safe to promote standby server
> to
> active. We thought we could use consistency check (cdr check repl)
> from
> standby node. And that's when this problem showed up.
On Nov 15, 8:26 am, Superboer <superbo...@t-online.de> wrote: > Do not get me wrong here ER is great however when i read above > is it not easyer to use HDR instead of ER in your situation??? > > (unless of course you have byte and text data in oldfashion > blobspaces..) I'm afraid it's not possible to change the replication deployment at this point.
On Nov 12, 7:51 pm, "Jonny...@Usenet-News.net" wrote:
> Can you on the standby server do dbaccess / connect
> / "Standy instance" using any of the
> DBSERVERNAME / DBSERVERALIAS / group name
> (obviously TCP connections only)
It was possible to connect using dbaccess, and
that was the clue that lead us to the solution.
Thanks.
I must admit it was kind of a beginner's mistake.
We didn't use -c option for connection to the other node
explicitly, and the wrong user was invoking the commands.
On a related topic, regarding usage of cdr check repl, when the
tables
have large number of rows, the processing obviously takes significant
amount
of time. We tested table with 180k records and cdr check took 4
minutes
to finish.
Does this command make significant impact on IDS when executed on
large
tables? We're planning to make a script that invokes cdr check repl
which
cron job would call in defined intervals, so our concern is how the
IDS will
handle that.