ClusterXL Failover.

[Matlu]

ClusterXL Failover.

Hello,

Is there any "practical" way to validate the reason "why" our ClusterXL did a failover?

We want to rule out that it was a CPU problem and / or equipment configuration.

The cphaprob state, shows the following.

Is there any other documentation to check in these "situations"?

Greetings.

[the_rock]

Yes, there are ways to tell...

Btw, I would NOT be using routable IPs for sync, as 3.3.3.x is Amazon range...I always tell customers to use 169.254.x.x range

Anyway, having said that, I would run below and look for messages in proper date/time span

from expert -> grep -i DOWN /var/log/messages*

Andy

[Matlu · Accepted solution]

Andy,

I found this, with the command you recommended.

I have the impression, and I am almost sure, that it was a manual "shutdown" of the equipment, either it was disconnected from the mains, or something similar.

By the way, in your command grep -i DOWN /var/log/messages* ... how can you filter the date only for today, 06September?

Cheers, 🙂

[the_rock]

There ya go bro, thats your answer : - )

Not sure if you can filter for specific date, will check.

Andy

[Bob_Zimmerman]

cphaprob show_failover

This shows a log of up to 20 failovers going back to the last time services were restarted. It doesn't always give a lot of detail. It also doesn't contain state changes which did not result in a failover (like standby to down).

[the_rock]

Thanks for that, totally forgot about the command.

Andy

[Matlu]

Hello,

This is a bit of a silly question, but when you apply the command, like:

cphaprob show_failover, the result says something like.

"member2 -> member1"

It's silly the doubt, but by "member2" do you mean, the same computer, where at that moment, I'm running the command?

Greetings.

[the_rock]

It would show you exact same output on both, but no matter the context, it would look at member 2 as current standby and member 1 as active.

Andy