Database High Availability Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

Availability is a story you have rehearsed

High availability is how the database keeps serving when one piece stops. The topology planner draws the pieces. The quorum calculator asks whether a vote can still be won. A picture is not a cluster. A cluster you have not failed on purpose in a lab is a picture.

Two nodes that both think they are in charge will accept two different writes. That is the failure this page is about preventing. A witness or a third vote is a decision you write down. If you do not have one, say that the topology is not ready for automatic failover.

Replication lag is a number, not a mood. The monitoring guide watches it. This page decides what lag is acceptable before you let a reader use the copy. A copy that is hours behind is not a spare you can promote without saying so.

The backup guide still applies. Replication is not a backup. A bad statement replicates. A restore from a tested backup is the other path, and you keep it.

A lab pair, one stopped node, one written result

Build two lab nodes, or use the vendor's lab recipe you have read. Write which one accepts writes. Insert a row you can recognise. See it on the other node. Stop the writer the way the lab allows. Write what the other node did: it waited, it promoted, or it refused.

That observation is the design. If it promoted and you did not want two writers, the topology changes before any production talk. If it waited, write who is allowed to promote it by hand.

Use the quorum calculator for the number of votes you actually have. A result that says you can lose a node and still decide is the result you wanted. A result that says you cannot is a reason to add a vote or to refuse automatic failover.

Production failover is a later window with the same steps and a named person. You do not discover the promote command during an outage.

A change you can finish

This window ends with a lab result and a decision about automatic failover. Production topology does not change today unless a separate ticket already approved a canary.

Rollback of the lab is starting the stopped node again, or rebuilding the lab from the images you kept.

Draw the nodes and mark the one that writes.
Name the votes. Run the quorum check.
Replicate one lab row you invented.
Stop the writer. Record what the other node does.
Decide whether failover is automatic or manual.
Keep the backup path. Replication is not the backup.
Write the promote steps a second person can follow.

Mistakes that outlive the command

database high availability fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Calling replication a backup.
Two writers with no rule about which one wins.
Automatic failover you have never watched.
A quorum number that does not match the nodes you have.
Promoting a copy without knowing its lag.
Testing failover on production first.
A lab row that was real customer data.
No person named for a manual promote.
Changing backup and topology in one window.
A diagram with no stop-test behind it.

Decisions to write down before the window

One decision for database high availability: The writer is one node, named. Votes match the calculator input. A lab row replicated. The stop test result is written. Automatic failover is yes or no, with a reason. Lag you would accept is a number. The backup guide remains the restore path. A person is named for manual promotion. Production was not the test. Rollback of the lab is written. The monitoring guide will watch lag. And one topology is this window.

The hour you stop

Write the database name, the host, and the clock time before you change anything for database high availability. If this database is serving people and you do not have a copy, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab or a restored copy. The rows you read are rows you are allowed to hold. You do not point a client at a database, a cluster, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a connection string, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.

One change. A config line, an index, a grant, and a restore do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file or the backup you already tested.

A second person reads the scope aloud: which host, which database, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

The lab listens on localhost. 127.0.0.1 is the address you bind until a firewall story exists. example.com is not your host. A generated file that listens on every address is a file you edit before it runs.

Do not run a statement you cannot undo. A delete or a drop without a backup and a where-clause you have read is the mistake this page is here to prevent. Read the statement. Count the rows it will touch. Then decide.

Keep the previous config and the previous dump. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the reload with a second session open when the change can lock you out.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a database nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next database waits until someone else can repeat the proof from the notes. database high availability is done for this window when the proof is written, not when the client printed a prompt.

This page is a planning guide. It is not a vendor manual, not an official standard, and not legal advice. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this database alone until that guide has its own window.

Availability checks before you trust a failover

Confirm this before you call the change done: The picture names a single writer. The quorum result is in the ticket. A lab row appeared on the copy. You stopped the writer and recorded the result. Automatic failover matches that result. Lag is a number. A backup restore time exists from the backup guide, or is an open gap. No customer row was used. A second person can say who promotes. Production topology is unchanged. The lab can be rebuilt. The next node is not added today. The hostname in the prompt matches the hostname in the ticket for database high availability. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for database high availability happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.