Data Services lifecycle management
Scaling of a service plan
It is possible to scale a service from one supported plan to another.
Scaling up
Scaling to a larger plan is always supported:
- within the same plan category: eg. from business-8 to business-16
- from one plan category to another: eg. from startup-8 to business-16
The scale operation can be triggered via 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 types provided the storage requirements of the lower plan will fit the space used currently within your service.
Scaling down from one plan category to another will be generally supported
for non-distributed services like pg or mysql as it will remove one
replica from the replica set. Eg. scaling down from premium-32 to
business-32 will remove one replica only.
Maintenance windows
Maintenance Windows are used to perform the non-urgent but 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 do this.
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 maintenance slot of each service which happen on a weekly basis in order to select a low traffic time period.
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.
How maintenance and upgrades work
Upgrades are performed as rolling upgrades where completely new instances are built alongside the old ones. Once the new instances are up and running and in sync 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 providing the service.
The controlled failover is a very quick and safe operation and 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.
Best practices for client configuration:
- do not cache IP addresses of services.
- make sure your client can automatically reconnect to a service.
- 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 tables to review the specifications of each plan or check the specific plan backup strategy with the command below:
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
moment between 2 backup intervals.
Exoscale DBaaS does not allow to restore data over an existing running service. Instead, in order to restore data, the process is to create a new service from an existing service specifying the time of recovery wanted. This operation is called creating a fork.
Forks
Example forpg 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 details).
Note
it can be useful to fork a service specifying another plan size than the original for test purposes or other use. However do note that the storage should be sufficient if you launch the new service with a smaller plan than the original 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. 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. Doing so the service will be created using the latest major and minor supported release of a service type.
Termination protection
Termination protection will prevent your service to be 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 instance anymore:
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.