Data Services lifecycle management
Scaling of a service plan
You can scale a service from one supported plan to another.
Scaling up
Scaling to a larger plan is always supported:
- within the same plan category: for example, from business-8 to business-16
- from one plan category to another: for example, from startup-8 to business-16
You can trigger the scale operation with the update command:
exo dbaas update -z de-fra-1 test-pg --plan startup-4
Updating Database Service "test-pg"...
Scaling down
Scaling down a service is generally supported on all service types, provided the storage requirements of the lower plan will fit the space currently used within your service.
From one plan category to another, scaling down is generally supported
for non-distributed services like pg or mysql, as it will remove one
replica from the replica set. For example, scaling down from premium-32 to
business-32 will remove one replica only.
Maintenance windows
Maintenance windows are used to perform necessary updates and upgrades regarding security and management layers of your Exoscale DBaaS services. They are not used to perform major service version upgrades, refer to the section upgrades on how to upgrade versions.
Note
Urgent upgrades including vulnerability updates will happen before the maintenance window in order to keep the services safe.
By default, an arbitrary slot will be assigned when creating your service. You can control the weekly maintenance window of each service to ensure maintenance occurs during a window with lower traffic levels.
Changing the maintenance window of a service
To adapt the maintenance window of a service, you need to pass
a new day of week and associated time with the update command
exo dbaas update -z de-fra-1 test-pg --maintenance-dow=tuesday --maintenance-time=10:10:10
Updating Database Service "test-pg"...
┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼
│ DATABASE SERVICE │ │
┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼
│ Zone │ de-fra-1 │
│ Name │ test-pg │
│ Type │ pg │
│ Plan │ hobbyist-1 │
│ Disk Size │ 8.0 GiB │
│ State │ running │
│ Creation Date │ 2021-10-21 08:42:40 +0000 UTC │
│ Update Date │ 2021-11-01 09:25:27 +0000 UTC │
│ Nodes │ 1 │
│ Node CPUs │ 2 │
│ Node Memory │ 2.0 GiB │
│ Termination Protected │ true │
│ Maintenance │ tuesday (10:10:10) │
│ Backup Schedule │ 20:28 │
│ URI │ postgres://avnadmin:xxxxx@test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21699/defaultdb?sslmode=require │
│ IP Filter │ 0.0.0.0/0 │
│ Components │ │
│ │ pg test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21699 route:dynamic usage:primary │
│ │ pgbouncer test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21700 route:dynamic usage:primary │
│ │ │
│ Users │ avnadmin (primary) │
┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼
The maintenance window can also be specified at creation time with the same parameters.
This parameter can also be checked and adjusted within the Portal
under the maintenance tab of a service. The same tab also lists
the upcoming updates to be applied at the next scheduled maintenance
or manually within the page.
How maintenance and upgrades work
Upgrades are performed as rolling upgrades where completely new instances are built alongside the old ones. After the new instances are running and synced with the old instances, a controlled automatic failover is performed to switch the service to use the new upgraded instances. The old servers are retired automatically after the new instances have taken over for providing the service.
The controlled failover is very quick and safe - it takes less than a minute to get clients connected again. Typically, we see a 5-10 second period during which the clients are unable to re-establish the connection. Single node plans will however see a longer downtime.
Best practices for client configuration:
- Do not cache IP addresses of services.
- Make sure your client can automatically reconnect to a service.
- Make sure the DNS name of a service stays the same after the upgrade.
Backups and restore
Exoscale DBaaS are automatically backed up, encrypted and stored securely in Object Storage.
The frequency and retention of backups is defined in the plan. Refer to the plan tables to review the specifications of each plan. You can also check the specific plan backup strategy with the command:
exo dbaas type show pg --backup-config startup-8
┼────────────────────────────┼──────┼
│ Backup interval (hours) │ 24 │
│ Max backups │ 3 │
│ Recovery mode │ pitr │
│ Frequent backup interval │ n/a │
│ Frequent backup max age │ n/a │
│ Infrequent backup interval │ n/a │
│ Infrequent backup max age │ n/a │
┼────────────────────────────┼──────┼
Some services like pg include PITR (point in time
recovery) which enables you to restore data at any
time between 2 backup intervals.
Exoscale DBaaS does not allow you to restore data over an existing running service. Instead, you can create a new service from an existing service specifying the time of recovery you need in order to restore data. This operation is called a fork.
Forks
Here is an example for pg that demonstrates how to create a fork of a service from a previous backup,
and how to perform a point-in-time recovery.
-
Identify the available backups and periods of time available for a fork:
``` exo dbaas show test-pg -z de-fra-1 --backups ┼─────────────────────────────────────┼───────────────────────────────┼──────────┼ │ NAME │ DATE │ SIZE │ ┼─────────────────────────────────────┼───────────────────────────────┼──────────┼ │ 2021-10-30_20-28_0.00000000.pghoard │ 2021-10-30 20:28:01 +0000 UTC │ 36341760 │ │ 2021-10-31_20-28_0.00000000.pghoard │ 2021-10-31 20:28:04 +0000 UTC │ 36382720 │ ┼─────────────────────────────────────┼───────────────────────────────┼──────────┼ ``` -
Create a fork with a point-in-time recovery:
``` exo dbaas create pg startup-4 fork-test-pg --pg-recovery-backup-time 2021-10-30 23:35 --pg-fork-from test-pg -z de-fra-1` ```
The rest of the create options behave like the normal create command. You can specify options and service-specific options at launch time. Refer to the service specific documentation for additional details.
Note
If you need to fork a service specifying another plan size than the original, note that the storage should be sufficient if you launch the new service with a smaller plan than the original service or fork.
Backup schedule
In the example above, we can see that the service is backed up each day at 20:28.
This slot can be adjusted for most services, but the process is service specific. Refer to the service specific documentation to change the backup schedule of a service.
Upgrades
Running upgrades will follow the same process as restoring a service from a fork, except that we will only create the service specifying the fork but not the recovery backup time. The service will be created using the latest major and minor supported release of a service type.
Termination protection
Termination protection will ensure your service is not deleted
accidentally by running the delete command or any other destructive
operation.
exo dbaas update test-pg -z de-fra-1 --termination-protection=true
Updating Database Service "test-pg"...
┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼
│ DATABASE SERVICE │ │
┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼
│ Zone │ de-fra-1 │
│ Name │ test-pg │
│ Type │ pg │
│ Plan │ hobbyist-1 │
│ Disk Size │ 8.0 GiB │
│ State │ running │
│ Creation Date │ 2021-07-05 08:38:39 +0000 UTC │
│ Update Date │ 2021-10-21 08:30:54 +0000 UTC │
│ Nodes │ 1 │
│ Node CPUs │ 2 │
│ Node Memory │ 2.0 GiB │
│ Termination Protected │ true │
│ Maintenance │ sunday (10:40:38) │
│ Backup Schedule │ 12:52 │
│ URI │ postgres://avnadmin:xxxxx@test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21699/defaultdb?sslmode=require │
│ IP Filter │ 0.0.0.0/0 │
│ Components │ │
│ │ pg test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21699 route:dynamic usage:primary │
│ │ pgbouncer test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21700 route:dynamic usage:primary │
│ │ │
│ Users │ avnadmin (primary) │
┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼
It is therefore not possible to delete the service. If you decide to delete the service once termination protection is enabled:
exo dbaas -z de-fra-1 delete test-pg
[+] Are you sure you want to delete Database Service "test-pg"? [yN]: y
✔ Deleting Database Service "test-pg"... 0s
error: Delete "https://api-de-fra-1.exoscale.com/v2/dbaas-service/test-pg": invalid request: The service is protected against termination and shutdown. Remove termination protectio
n first.
Revert the flag and then delete the DB instance.