Thanks Brian.
The report shows the host files and rhost files are the same. I started with this document (https://supportforums.cisco.com/docs/DOC-13672.pdf) and ran all the tests and it looks like I'm in good shape to begin fixing, i.e host files as I mentioned, DNS resolution, comparing actual state values, etc. However, as I read on, it didn't show a scenario like mine, i.e. pub at 3 and sub at 2. The steps on page 16 are similar to what you have stated though.
I will try them out and see how it goes.
Still interested in why this happened though.... :(
---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph
519‐824‐4120 Ext 56354
lelio at uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1
----- Original Message -----
From: "Brian Meade (brmeade)" <brmeade at cisco.com>
To: "Lelio Fulgenzi" <lelio at uoguelph.ca>
Cc: "cisco-voip" <cisco-voip at puck.nether.net>
Sent: Tuesday, February 11, 2014 11:57:08 AM
Subject: RE: [cisco-voip] conflicting directions: DRS manual vs DRS GUI
Lelio,
Generate a new DB Status Report under Unified Reporting and make sure all of the hosts files are good. If that’s okay, I’d just run a “utils dbreplication stop” on both nodes then run a “utils dbreplication dropadmindb” on both nodes, and finally just run a “utils dbreplication reset all” from the publisher. Since it’s only a 2-node cluster, it should be pretty quick to get it back to a 2.
Thanks,
Brian
From: Lelio Fulgenzi [mailto:lelio at uoguelph.ca]
Sent: Tuesday, February 11, 2014 11:50 AM
To: Brian Meade (brmeade)
Cc: cisco-voip
Subject: Re: [cisco-voip] conflicting directions: DRS manual vs DRS GUI
Thanks Brian.
I can't see CSCsu59755, but CSCsr91903 looks interesting. It's quite a bit different than the documentation, saying to actually reboot the pub before restoring the sub, and to restore the sub via CLI tools.
I followed the TAC's recommendation, restoring the pub first, then the sub, then followed the documentation and rebooted the sub first, then the pub.
Now I gots a replication status of "3" on the pub and "2" on the sub.
Will have to google-foo this and see what I can find, or work with the TAC.
Not excited about this...
Lelio
---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph
519 ‐ 824 ‐ 4120 Ext 56354
lelio at uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1
----- Original Message -----
From: "Brian Meade (brmeade)" < brmeade at cisco.com >
To: "Lelio Fulgenzi" < lelio at uoguelph.ca >, "cisco-voip" < cisco-voip at puck.nether.net >
Sent: Tuesday, February 11, 2014 11:13:04 AM
Subject: RE: [cisco-voip] conflicting directions: DRS manual vs DRS GUI
Lelio,
That warning message on the DRS webpage was added back in 6.x. as part of CSCsu59755. It looks like there were a lot of replication problems when restoring all the nodes at once so their fix was just to add that message of restoring the publisher first. It looks like the bug mentions it should be fixed as part of CSCsr91903 but the warning message was never removed (it’s unclear if it’s still needed). I’d say it would probably be best practice to restore the publisher first in this scenario as it will probably eliminate a lot of potential issues.
Brian
From: cisco-voip [ mailto:cisco-voip-bounces at puck.nether.net ] On Behalf Of Lelio Fulgenzi
Sent: Tuesday, February 11, 2014 10:20 AM
To: cisco-voip
Subject: Re: [cisco-voip] conflicting directions: DRS manual vs DRS GUI
According to the TAC (629123121), the publisher must always be restored first. They at first mentioned it was because of the hardware differences, but later, after consulting with their lead, they mentioned, it's always the case.
I've asked them to investigate why the document has never been updated and/or to update the document accordingly.
Not sure if this is one of those times where the TAC's best practices conflicts with what the document says, or even if there is any chance of having the document updated, but it's very confusing.
Onward we shall go....
Lelio
---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph
519 ‐ 824 ‐ 4120 Ext 56354
lelio at uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1
From: "Lelio Fulgenzi" < lelio at uoguelph.ca >
To: "cisco-voip" < cisco-voip at puck.nether.net >
Sent: Monday, February 10, 2014 4:40:44 PM
Subject: conflicting directions: DRS manual vs DRS GUI
I'm at the point in our migration to v9 test where I am about to restore my cluster after applying the refresh COP file.
The documentation states, in more than one spot, that I can restore the cluster at once, without having to do the publisher first:
* You can restore the whole cluster as a single operation after you rebuild the publisher server and the subscriber servers, or to revert to a known good configuration. You do not need to restore the first node and the subsequent nodes in two separate operations. [Page 14]
* When you get prompted to choose the nodes to restore, choose all the nodes in the cluster. [Page 15, Step 11]
However, when I run the utility, there is a warning at the top, which states:
* If you are attempting to restore on a freshly installed publisher, only select the first node (Publisher) for restore. The subsequent nodes can be selected only after the completion of publisher restore. For further details please refer to the Disaster Recovery System Administration Guide.
The latest documentation is for v7.1(2), but I'm currently running v7.1(5b)SU3, so I'm wondering if the warning in the code supersedes the document.
Anyone care to comment?
Lelio
---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph
519 ‐ 824 ‐ 4120 Ext 56354
lelio at uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140211/9bea15d1/attachment.html>