Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
TetraWiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
PCS Cluster failover-process
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Special pages
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
''Auto-generated from the uploaded PDF [[:File:PCS_Cluster_failover-process.pdf|PCS_Cluster_failover-process.pdf]]. This is an extracted-text rendering for searchability; see the original PDF for exact formatting, diagrams, tables, and images.'' <pre> <nowiki> SOP: PCS Cluster Working Process & Failover Management Cluster Details ο· Cluster Name: nagios_cluster ο· Cluster Stack: Corosync / Pacemaker ο· Preferred Node: app2-2.spectra.co ο· Failover Node: app2-1.spectra.co ο· DRBD Resource: r0 ο· MySQL: Master-Master Replication ο· DRBD Mount Point Resource: fs_drbd 1. Normal Cluster Behavior ο· By default, all resources (VIP, DRBD master, services) are hosted on app2- 2.spectra.co. ο· If app2-2.spectra.co becomes unreachable or is manually set to standby, cluster resources failover to app2-1.spectra.co. 2. Failover Behavior ο· When app2-2.spectra.co is offline/unreachable, resources move to app2- 1.spectra.co. ο· Once app2-2.spectra.co comes back online, PCS automatically migrates resources back to the preferred node (as per location constraints). ο· This migration may take a few minutes depending on service/resource status. 3. Manual Standby & Recovery Steps Put Node in Standby pcs node standby app2-2.spectra.co Un-standby Node (Bring Back to Cluster) pcs node unstandby app2-2.spectra.co 4. Cleanup Failed Resource Actions After any failover or recovery, always clean failed resource states: pcs resource cleanup 5. Verification Steps After Failover or Recovery A. Check DRBD Sync Status drbdadm status r0 ο· Ensure both nodes are in sync. ο· Preferred node should show as Primary. B. Check MySQL Replication (Master-Master) mysql -e "SHOW SLAVE STATUS\G" ο· Look for Seconds_Behind_Master, Slave_IO_Running, Slave_SQL_Running values. ο· Both should show replication in healthy state. C. Check Cluster Status pcs status ο· Verify all resources are running on the correct node ( app2-2.spectra.co). ο· Example: * Promoted: [ app2-2.spectra.co ] * Started: [ app2-2.spectra.co ] 6. Logs & History Check logs for any anomalies: journalctl -xe | grep pacemaker cat /var/log/pacemaker.log 7. Important Notes ο· Always verify DRBD and MySQL replication after failover or maintenance. ο· Ensure fencing (fence_ipmilan) is working correctly for both nodes. ο· If frequent failures occur, check the monitor action results and logs for root cause. </nowiki> </pre>
Summary:
Please note that all contributions to TetraWiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
TetraWiki:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)