Skip to content

Commit d037863

Browse files
tcpdumpfbackethild42
authored andcommitted
EN proof
1 parent bcadf24 commit d037863

File tree

1 file changed

+25
-26
lines changed
  • pages/public_cloud/public_cloud_databases/databases_19_migrate_from_1AZ_to_3AZ

1 file changed

+25
-26
lines changed

pages/public_cloud/public_cloud_databases/databases_19_migrate_from_1AZ_to_3AZ/guide.en-gb.md

Lines changed: 25 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -1,37 +1,37 @@
11
---
2-
title: "How to move a database service from a Single AZ region to a 3AZ region."
3-
excerpt: "Learn to move your OVHcloud Public Cloud Database from a Single AZ to a 3AZ region. Ensure high availability."
2+
title: "How to move a database service from a single AZ region to a 3-AZ region"
3+
excerpt: "Learn how to move your OVHcloud Public Cloud Database from a single AZ to a 3-AZ region and ensure high availability"
44
updated: 2025-07-14
55
---
66

77
## Objective
88

9-
OVHcloud Public Cloud Databases can be deployed with different architectures to meet varied needs for availability and resilience. This guide is specifically designed to walk you through the migration of your existing database service from a Single Availability Zone (1AZ) configuration to a Three Availability Zone (3AZ) architecture. You'll discover the detailed steps to perform this transfer, ensuring high availability and improved fault tolerance for your critical applications.
9+
OVHcloud Public Cloud Databases can be deployed with different architectures to meet varied needs for availability and resilience. This guide is specifically designed to walk you through the migration of your existing database service from a single availability zone (1-AZ) configuration to a 3-AZ architecture (three availability zones). You'll discover the detailed steps to perform this transfer, ensuring high availability and improved fault tolerance for your critical applications.
1010

1111
## Requirements
1212

1313
- A [Public Cloud project](/links/public-cloud/public-cloud) in your OVHcloud account
1414
- Access to the [OVHcloud Control Panel](/links/manager) or to the [OVHcloud API](/links/api)
15-
- Have an existing database service deployed in a Single Availability Zone (1AZ).
16-
- Have a 3AZ region activated within your Public Cloud project.
15+
- An existing database service deployed in a single availability zone (1-AZ)
16+
- A 3-AZ region activated within your Public Cloud project
1717

18-
## Why move to 3AZ ?
18+
## Why move to 3-AZ?
1919

20-
Migrating your database service to a Three Availability Zone (3AZ) deployment significantly enhances its resilience, high availability, and disaster recovery capabilities. In a 3AZ setup, your data is synchronously replicated across three distinct availability zones within the same region. This architecture ensures that in the event of an outage in one zone, your database service can automatically fail over to another operational zone with minimal downtime and no data loss.
20+
Migrating your database service to a 3-AZ deployment significantly enhances its resilience, high availability, and disaster recovery capabilities. In a 3-AZ setup, your data is synchronously replicated across three distinct availability zones within the same region. This architecture ensures that in the event of an outage in one zone, your database service can automatically failover to another operational zone with minimal downtime and no data loss.
2121

2222
For more detailed information on the deployment modes and their technical specifications, please refer to our dedicated guide: [Comparison of Public Cloud Databases Deployment Modes - Understanding 3-AZ / 1-AZ](/pages/public_cloud/public_cloud_databases/databases_18_regions_comparison).
2323

2424
## Instructions
2525

26-
### Move engine instance to 3AZ
26+
### Move an engine instance to 3-AZ
2727

2828
> [!tabs]
2929
> Via the OVHcloud Control Panel
30-
>> To move a database service from a 1AZ to a 3AZ region, log in to the OVHcloud Control Panel and open your Public Cloud project. Click `Databases`{.action} in the left navigation bar, select your engine instance then click the `Backups`{.action} tab.
30+
>> To move a database service from a 1-AZ to a 3-AZ region, log in to the OVHcloud Control Panel and open your Public Cloud project. Click `Databases`{.action} in the left navigation bar, select your engine instance then click the `Backups`{.action} tab.
3131
>>
3232
>> ![databases - select engines instances and go to the backups section](images/databases_select_cluster.png)
3333
>>
34-
>> Choose the backup from which you wish to fork, , click on the `...`{.action} button and click on the `Duplicate(fork)`{.action} button.
34+
>> Choose the backup from which you wish to fork, click on the `...`{.action} button and click on the `Duplicate (fork)`{.action} button.
3535
>>
3636
>> ![databases - click on the duplicate button](images/databases_fork_backup.png)
3737
>>
@@ -43,15 +43,15 @@ For more detailed information on the deployment modes and their technical specif
4343
>>
4444
>> ![databases fork - select your plan](images/databases_fork_plan.png)
4545
>>
46-
>> Select a `3AZ region`{.action}.
46+
>> Select a `3-AZ region`{.action}.
4747
>>
48-
>> ![databases fork - select your 3AZ region](images/databases_fork_region.png)
48+
>> ![databases fork - select your 3-AZ region](images/databases_fork_region.png)
4949
>>
5050
>> Select the `node type`{.action} for the engine instance.
5151
>>
5252
>> ![databases fork - select the node type](images/databases_fork_node_type.png)
5353
>>
54-
>> If you need, you can configure additional storage and connectivity settings, then verify the IP addresses to whitelist (the list is pre-filled by default with the origin service's configuration).
54+
>> If needed, you can configure additional storage and connectivity settings, then verify the IP addresses to whitelist (the list is pre-filled by default with the origin service's configuration).
5555
>>
5656
>> ![databases fork - select optional fields](images/databases_fork_optional.png)
5757
>>
@@ -65,14 +65,14 @@ For more detailed information on the deployment modes and their technical specif
6565
>> > To interact with your Public Cloud Databases services via the OVHcloud API, make sure you've mastered the basics first by consulting our guide: [Public CLoud Databases - Getting started with APIs](/pages/public_cloud/public_cloud_databases/databases_02_order_api).
6666
>> >
6767
>>
68-
>> to find the backup id of an engine instance, use this following API call:
68+
>> To find the backup ID of an engine instance, use this following API call:
6969
>>
7070
>> > [!api]
7171
>> >
7272
>> > @api {v1} /cloud GET /cloud/project/{serviceName}/database/postgresql/{clusterId}/backup
7373
>> >
7474
>>
75-
>> this call retrieves the backup list of the engine instance concerned. They are listed in order from the most recent backup to the oldest.
75+
>> This call retrieves the backup list of the engine instance concerned. They are listed in order from the most recent backup to the oldest.
7676
>>
7777
>> If you want to check the information on a particular backup, you can use this API call:
7878
>>
@@ -81,7 +81,7 @@ For more detailed information on the deployment modes and their technical specif
8181
>> > @api {v1} /cloud GET /cloud/project/{serviceName}/database/postgresql/{clusterId}/backup/{backupId}
8282
>> >
8383
>>
84-
>> To create your engine instance from one backup, use this following API call:
84+
>> To create your engine instance from one backup, use the following API call:
8585
>>
8686
>> > [!api]
8787
>> >
@@ -92,7 +92,7 @@ For more detailed information on the deployment modes and their technical specif
9292
>>
9393
>> > [!warning]
9494
>> >
95-
>> > The old field named `backup` is deprecated and replaced by `forkFrom`.
95+
>> > The field named `backup` is deprecated and replaced by `forkFrom`.
9696
>> >
9797
>>
9898
>> ```console
@@ -124,32 +124,32 @@ For more detailed information on the deployment modes and their technical specif
124124
125125
### Validate the deployment
126126
127-
After your new 3AZ database service has been successfully provisioned, it's crucial to validate its deployment and ensure your applications can connect to it.
127+
After your new 3-AZ database service has been successfully provisioned, it's crucial to validate its deployment and ensure your applications can connect to it.
128128
129-
1. Test the connection to your new service:
129+
1\. Test the connection to your new service:
130130
131-
- Use a database client (e.g., psql for PostgreSQL, mysql for MySQL) or a simple script to verify that you can connect to the new 3AZ service's endpoint using its credentials.
131+
- Use a database client (e.g., psql for PostgreSQL, mysql for MySQL) or a simple script to verify that you can connect to the new 3-AZ service's endpoint using its credentials.
132132
- Confirm that your data has been successfully migrated and is accessible.
133133
134-
2. Configure your application to use the new service:
134+
2\. Configure your application to use the new service:
135135
136-
- Update your application's configuration files or environment variables to point to the new 3AZ database service's connection string (host, port, username, password).
136+
- Update your application's configuration files or environment variables to point to the new 3-AZ database service's connection string (host, port, username, password).
137137
- Restart your application to apply the changes.
138138
- Thoroughly test your application's functionality to ensure it operates correctly with the new database endpoint.
139139
140140
### Clean up
141141
142-
Once you've fully validated that your application is working correctly with the new 3AZ database service, and you're confident all data has been transferred and is accessible, you can proceed with deleting the old 1AZ service.
142+
Once you've fully validated that your application is working correctly with the new 3-AZ database service, and you're confident all data has been transferred and is accessible, you can proceed with deleting the old 1-AZ service.
143143
144144
This step is crucial to avoid unnecessary costs and maintain a clean infrastructure.
145145
146-
Follow this instructions to delete the old 1AZ service:
146+
Follow these instructions to delete the old 1-AZ service:
147147
148148
> [!tabs]
149149
> Via the OVHcloud Control Panel
150150
>> Navigate to your list of engine instances, click on the `...`{.action} button on the engine instance line and click on the `Delete`{.action} button to permanently delete the service.
151151
>>
152-
>> ![databases - delete the 1az engine instance](images/databases_delete_1az.png)
152+
>> ![databases - delete the 1-AZ engine instance](images/databases_delete_1-AZ.png)
153153
>>
154154
> Via the OVHcloud API
155155
>> To delete your engine instance, use the following API call:
@@ -160,7 +160,6 @@ Follow this instructions to delete the old 1AZ service:
160160
>> >
161161
>>
162162
163-
cloud/project/{serviceName}/database/postgresql/{clusterId}
164163
165164
## We want your feedback!
166165

0 commit comments

Comments
 (0)