You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/solutions/high-availability.md
+12-13Lines changed: 12 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
Whether you are a small startup or a big enterprise, downtime of your services may cause severe consequences, such as loss of customers, impact on your reputation, and penalties for not meeting the Service Level Agreements (SLAs). That’s why ensuring a highly-available deployment is crucial.
4
4
5
-
But what does it mean, high availability (HA)? And how to achieve it? This document answers these questions.
5
+
This topic explains what high availability (HA) is and how you can achieve it using Patroni.
6
6
7
7
After reading this document, you will learn the following:
8
8
@@ -23,21 +23,21 @@ Overall, High availability is about:
23
23
3. Automatic detection of failures.
24
24
4. Automatic action to reduce the impact.
25
25
26
-
### How to achieve it?
26
+
### How to achieve it?
27
27
28
-
A short answer is: add redundancy to your deployment, eliminate a single point of failure (SPOF) and have the mechanism to transfer the services from a failed member to the healthy one.
28
+
A short answer is: add redundancy to your deployment, eliminate a single point of failure (SPOF) and have the mechanism to transfer the services from a failed member to the healthy one.
29
29
30
-
For a long answer, let's break it down into steps.
30
+
For a long answer, let's break it down into steps.
31
31
32
32
#### Step 1. Replication
33
33
34
-
First, you should have more than one copy of your data. This means, you need to have several instances of your database where one is the primary instance that accepts reads and writes. Other instances are replicas – they must have an up-to-date copy of the data from the primary and remain in sync with it. They may also accept reads to offload your primary.
34
+
First, you should have more than one copy of your data. This means, you need to have several instances of your database where one is the primary instance that accepts reads and writes. Other instances are replicas – they must have an up-to-date copy of the data from the primary and remain in sync with it. They may also accept reads to offload your primary.
35
35
36
36
You must deploy these instances on separate hardware (servers or nodes) and use separate storage for storing the data. This way you eliminate a single point of failure for your database.
37
37
38
-
The minimum number of database nodes is two: one primary and one replica.
38
+
The minimum number of database nodes is two: one primary and one replica.
39
39
40
-
The recommended deployment is a three-instance cluster consisting of one primary and two replica nodes. The replicas receive the data via the replication mechanism.
40
+
The recommended deployment is a three-instance cluster consisting of one primary and two replica nodes. The replicas receive the data via the replication mechanism.
@@ -107,13 +107,13 @@ Historically, many organizations have used floating Virtual IP (VIP) addresses t
107
107
108
108
The use of an external load balancer is optional. If your application implements the logic of connection routing and load-balancing, it is a highly-recommended approach.
109
109
110
-
#### Step 4. Backups
110
+
#### Step 4. Backups
111
111
112
112
Even with replication and failover mechanisms in place, it’s crucial to have regular backups of your data. Backups provide a safety net for catastrophic failures that affect both the primary and replica nodes. While replication ensures data is synchronized across multiple nodes, it does not protect against data corruption, accidental deletions, or malicious attacks that can affect all nodes.
Having regular backups ensures that you can restore your data to a previous state, preserving data integrity and availability even in the worst-case scenarios. Store your backups in separate, secure locations and regularly test them to ensure that you can quickly and accurately restore them when needed. This additional layer of protection is essential to maintaining continuous operation and minimizing data loss.
116
+
Having regular backups ensures that you can restore your data to a previous state, preserving data integrity and availability even in the worst-case scenarios. Store your backups in separate, secure locations and regularly test them to ensure that you can quickly and accurately restore them when needed. This additional layer of protection is essential to maintaining continuous operation and minimizing data loss.
117
117
118
118
The backup tool is optional but highly-recommended for data corruption recovery. Additionally, backups protect against human error, when a user can accidentally drop a table or make another mistake.
119
119
@@ -128,11 +128,12 @@ Optionally, you can add a monitoring tool to observe the health of your deployme
128
128
129
129
### What tools to use?
130
130
131
-
The PostgreSQL ecosystem offers many tools for high availability, but choosing the right ones can be challenging. At Percona, we have carefully selected and tested open-source tools to ensure they work well together and help you achieve high availability.
131
+
The PostgreSQL ecosystem offers many tools for high availability, but choosing the right ones can be challenging. At Percona, we have carefully selected and tested open-source tools to ensure they work well together and help you achieve high availability.
132
132
133
133
In our [reference architecture](ha-architecture.md) section we recommend a combination of open-source components and frameworks, focusing on a minimalistic PostgreSQL cluster.
134
134
135
-
Note that all the components are recommended but not mandatory. You can use your own solutions and alternatives if they better meet your business needs. However, deviating from proven methods and architecture may increase the risk.
135
+
!!! note
136
+
All of the components are recommended but **not** mandatory. You can use your own solutions and alternatives if they better meet your business needs. However, deviating from proven methods and architecture may increase risk.
136
137
137
138
### Additional reading
138
139
@@ -141,5 +142,3 @@ Note that all the components are recommended but not mandatory. You can use your
0 commit comments