Informix

Good day

I have Replicates that's inactive and when i try to start them it gives invalid replicate change. It is not on all servers just 2 or 3 servers but on other servers it's active.

I'm I missing something

Hi Jaco,

assuming this is the ball we've dropped elsewhere, sorry for that?!

As for those replicate states, there might be an explanation for this confusion:

First of all there's a distinction internally between 'replicate state' and 'participant state', and it's not clear, on the face of it, which one you're getting from "cdr list replicate";  and not only is it not clear if generally rep_state OR part_state, it even can be either of them.

The (internal) rule:  if rep_state is Active show part_state, else show rep_state   --  making things any more clear? ;-)

The actual truth is in syscdr repdef and partdef views (repstate + partstate fields), related via repid.
So I'd first verify this information is consistent across all you servers' syscdr databases.  Should we be looking at some sort of inconsistency between servers, an affected replicate probably had to be deleted and redefined as the quickest way to resolution.

Assuming consistency, you probably have got an 'Active' replicate with only some of its participants having been activated.  Keep in mind that, when expanding an existing replicate by new participants (cdr change replicate --add), those new participants will be and remain inactive and require to be activated in a separate step.

Should this be your situation, the required next step would be:

cdr start replicate <repl_name> <server_list>

with <server_list> being the blanc separated list of ER server names where the replicate appears inactive.

Let us know if this helped!

BR,

 Andreas

Good day

I have Replicates that's inactive and when i try to start them it gives invalid replicate change. It is not on all servers just 2 or 3 servers but on other servers it's active.

I'm I missing something

Thanks for the reply.

This replicate was deleted and recreated like all the others but still can't change the state. Below the output for cdr list replicate on 2 servers

DEFINED REPLICATES ATTRIBUTES
------------------------------
REPLICATE:        A_per_property_A1
STATE:            Inactive ON:grp_08_headq
CONFLICT:         Timestamp
FREQUENCY:        immediate
QUEUE SIZE:       0
PARTICIPANT:      warms:dwafdba.per_property
OPTIONS:          transaction,ris,ats,fullrow
REPLID:           530997 / 0x81a35
REPLMODE:         PRIMARY  ON:grp_08_headq
APPLY-AS:         INFORMIX ON:grp_08_headq

This is the one that does not change to active

DEFINED REPLICATES ATTRIBUTES
------------------------------
REPLICATE:        A_per_property_A1
STATE:            Inactive ON:grp_26_ecape
CONFLICT:         Timestamp
FREQUENCY:        immediate
QUEUE SIZE:       0
PARTICIPANT:      warms:dwafdba.per_property
OPTIONS:          transaction,ris,ats,fullrow
REPLID:           530997 / 0x81a35
REPLMODE:         PRIMARY  ON:grp_26_ecape
APPLY-AS:         INFORMIX ON:grp_26_ecape

Hi Jaco,

assuming this is the ball we've dropped elsewhere, sorry for that?!

As for those replicate states, there might be an explanation for this confusion:

First of all there's a distinction internally between 'replicate state' and 'participant state', and it's not clear, on the face of it, which one you're getting from "cdr list replicate";  and not only is it not clear if generally rep_state OR part_state, it even can be either of them.

The (internal) rule:  if rep_state is Active show part_state, else show rep_state   --  making things any more clear? ;-)

The actual truth is in syscdr repdef and partdef views (repstate + partstate fields), related via repid.
So I'd first verify this information is consistent across all you servers' syscdr databases.  Should we be looking at some sort of inconsistency between servers, an affected replicate probably had to be deleted and redefined as the quickest way to resolution.

Assuming consistency, you probably have got an 'Active' replicate with only some of its participants having been activated.  Keep in mind that, when expanding an existing replicate by new participants (cdr change replicate --add), those new participants will be and remain inactive and require to be activated in a separate step.

Should this be your situation, the required next step would be:

cdr start replicate <repl_name> <server_list>

with <server_list> being the blanc separated list of ER server names where the replicate appears inactive.

Let us know if this helped!

BR,

 Andreas

Good day

I have Replicates that's inactive and when i try to start them it gives invalid replicate change. It is not on all servers just 2 or 3 servers but on other servers it's active.

I'm I missing something

So what's this going to return?

for s in grp_08_headq grp_26_ecape; do
echo "From $s:"
dbaccess syscdr@$s <<!
select repstate from repdef where repid = 530997;
select servid, partnum, partstate from partdef where repid = 530997;
!
done

Thanks for the reply.

This replicate was deleted and recreated like all the others but still can't change the state. Below the output for cdr list replicate on 2 servers

DEFINED REPLICATES ATTRIBUTES
------------------------------
REPLICATE:        A_per_property_A1
STATE:            Inactive ON:grp_08_headq
CONFLICT:         Timestamp
FREQUENCY:        immediate
QUEUE SIZE:       0
PARTICIPANT:      warms:dwafdba.per_property
OPTIONS:          transaction,ris,ats,fullrow
REPLID:           530997 / 0x81a35
REPLMODE:         PRIMARY  ON:grp_08_headq
APPLY-AS:         INFORMIX ON:grp_08_headq

This is the one that does not change to active

DEFINED REPLICATES ATTRIBUTES
------------------------------
REPLICATE:        A_per_property_A1
STATE:            Inactive ON:grp_26_ecape
CONFLICT:         Timestamp
FREQUENCY:        immediate
QUEUE SIZE:       0
PARTICIPANT:      warms:dwafdba.per_property
OPTIONS:          transaction,ris,ats,fullrow
REPLID:           530997 / 0x81a35
REPLMODE:         PRIMARY  ON:grp_26_ecape
APPLY-AS:         INFORMIX ON:grp_26_ecape

Hi Jaco,

assuming this is the ball we've dropped elsewhere, sorry for that?!

As for those replicate states, there might be an explanation for this confusion:

First of all there's a distinction internally between 'replicate state' and 'participant state', and it's not clear, on the face of it, which one you're getting from "cdr list replicate";  and not only is it not clear if generally rep_state OR part_state, it even can be either of them.

The (internal) rule:  if rep_state is Active show part_state, else show rep_state   --  making things any more clear? ;-)

The actual truth is in syscdr repdef and partdef views (repstate + partstate fields), related via repid.
So I'd first verify this information is consistent across all you servers' syscdr databases.  Should we be looking at some sort of inconsistency between servers, an affected replicate probably had to be deleted and redefined as the quickest way to resolution.

Assuming consistency, you probably have got an 'Active' replicate with only some of its participants having been activated.  Keep in mind that, when expanding an existing replicate by new participants (cdr change replicate --add), those new participants will be and remain inactive and require to be activated in a separate step.

Should this be your situation, the required next step would be:

cdr start replicate <repl_name> <server_list>

with <server_list> being the blanc separated list of ER server names where the replicate appears inactive.

Let us know if this helped!

BR,

 Andreas

Good day

I have Replicates that's inactive and when i try to start them it gives invalid replicate change. It is not on all servers just 2 or 3 servers but on other servers it's active.

I'm I missing something

output for grp_08_headq

So what's this going to return?

for s in grp_08_headq grp_26_ecape; do
echo "From $s:"
dbaccess syscdr@$s <<!
select repstate from repdef where repid = 530997;
select servid, partnum, partstate from partdef where repid = 530997;
!
done

Thanks for the reply.

This replicate was deleted and recreated like all the others but still can't change the state. Below the output for cdr list replicate on 2 servers

DEFINED REPLICATES ATTRIBUTES
------------------------------
REPLICATE:        A_per_property_A1
STATE:            Inactive ON:grp_08_headq
CONFLICT:         Timestamp
FREQUENCY:        immediate
QUEUE SIZE:       0
PARTICIPANT:      warms:dwafdba.per_property
OPTIONS:          transaction,ris,ats,fullrow
REPLID:           530997 / 0x81a35
REPLMODE:         PRIMARY  ON:grp_08_headq
APPLY-AS:         INFORMIX ON:grp_08_headq

This is the one that does not change to active

DEFINED REPLICATES ATTRIBUTES
------------------------------
REPLICATE:        A_per_property_A1
STATE:            Inactive ON:grp_26_ecape
CONFLICT:         Timestamp
FREQUENCY:        immediate
QUEUE SIZE:       0
PARTICIPANT:      warms:dwafdba.per_property
OPTIONS:          transaction,ris,ats,fullrow
REPLID:           530997 / 0x81a35
REPLMODE:         PRIMARY  ON:grp_26_ecape
APPLY-AS:         INFORMIX ON:grp_26_ecape

Hi Jaco,

assuming this is the ball we've dropped elsewhere, sorry for that?!

As for those replicate states, there might be an explanation for this confusion:

First of all there's a distinction internally between 'replicate state' and 'participant state', and it's not clear, on the face of it, which one you're getting from "cdr list replicate";  and not only is it not clear if generally rep_state OR part_state, it even can be either of them.

The (internal) rule:  if rep_state is Active show part_state, else show rep_state   --  making things any more clear? ;-)

The actual truth is in syscdr repdef and partdef views (repstate + partstate fields), related via repid.
So I'd first verify this information is consistent across all you servers' syscdr databases.  Should we be looking at some sort of inconsistency between servers, an affected replicate probably had to be deleted and redefined as the quickest way to resolution.

Assuming consistency, you probably have got an 'Active' replicate with only some of its participants having been activated.  Keep in mind that, when expanding an existing replicate by new participants (cdr change replicate --add), those new participants will be and remain inactive and require to be activated in a separate step.

Should this be your situation, the required next step would be:

cdr start replicate <repl_name> <server_list>

with <server_list> being the blanc separated list of ER server names where the replicate appears inactive.

Let us know if this helped!

BR,

 Andreas

Good day

I have Replicates that's inactive and when i try to start them it gives invalid replicate change. It is not on all servers just 2 or 3 servers but on other servers it's active.

I'm I missing something