OVHcloud Web Hosting Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
CloudDB (PrivateSQL)
Scheduled Maintenance Report for Web Cloud
Completed
Depuis maintenant 2 mois, nous travaillons à faire en sorte que vos instances CloudDB (également connues sous le nom «PrivateSQL») gèrent leur mémoire plus intelligemment. Nos tests sont concluants, il est maintenant temps de passer à la production!

Cette amélioration entraînera le redémarrage de votre instance et entraînera donc une coupure de 2 minutes environ.

Vous trouverez le planning détaillé dans les commentaires.

Des questions? Des retours à nous faire? C’est ici: https://community.ovh.com/t/amelioration-de-la-gestion-de-la-memoire-sur-les-clouddb/28070

---

For the past 2 months, we have been working so that your CloudDB instances (also known as “PrivateSQL”) handle their memory in a smarter way. Our tests are conclusive, now it is time to move on production!

This improvement requires restarting your instance and therefore about 2 minutes downtime.

You’ll find the detailed planning in the following comments.

Any questions? Any feedbacks? You can do it here: https://community.ovh.com/t/amelioration-de-la-gestion-de-la-memoire-sur-les-clouddb/28070 ; This thread is in French, but do not hesitate to write in English, we’ll answer you.

Update(s):

Date: 2020-07-08 22:28:50 UTC
Intervention completed successfully.

I personally think that this is a great step forward. Enjoy =)

Date: 2020-07-08 21:33:24 UTC
sql020: clouddb00[1-9]: done. Continuing…
sql021: clouddb00[1-9]: done. Continuing…
sql059: done. (that's a tiny cluster for now)

Date: 2020-07-08 21:25:47 UTC
sql020: clouddb00[1-4]: done. Continuing…
sql021: clouddb00[1-4]: done. Continuing…
sql059: Starting…

Date: 2020-07-08 21:13:37 UTC
The intervention is starting on sql020 and sql021…

Date: 2020-07-07 22:46:02 UTC
Intervention completed successfully on sql006 and sql007.

As a reminder, the next intervention will be done tomorrow (2020-07-08), from 23:00 CEST:
- sql020
- sql021
- sql059

Date: 2020-07-07 22:15:44 UTC
clouddb0[01-39].sql006: done.
clouddb0[01-24].sql007: done.
Continuing…

Date: 2020-07-07 21:46:45 UTC
clouddb00[1-9].sql006: done.
clouddb00[1-4].sql007: done.
Continuing…

Date: 2020-07-07 21:28:45 UTC
The intervention is starting on sql006 and sql007…

Date: 2020-07-07 17:15:43 UTC
And the following intervention will be on 2020-07-08, from 23:00 CEST:
- sql020
- sql021
- sql059

Date: 2020-07-06 22:08:22 UTC
Intervention completed successfully.
Next intervention tomorrow (2020-07-07), from 23:00 CEST:
- sql006
- sql007

Date: 2020-07-06 21:41:01 UTC
clouddb0[01-24].sql008 are up-to-date. Continuing…

Date: 2020-07-06 21:02:51 UTC
The intervention is starting…

Date: 2020-07-02 19:58:02 UTC
Time to finish that =)

Next intervention:
- Monday 2020-07-06: sql008 (clouddb0[01,05,10-19].sql008 is already up-to-date)

Date: 2020-06-11 21:55:03 UTC
Intervention completed successfully.

Date: 2020-06-11 21:24:52 UTC
The intervention is starting on sql021…

Date: 2020-06-10 21:37:27 UTC
Intervention completed successfully.

Date: 2020-06-10 21:11:22 UTC
The intervention is starting on sql020…

Date: 2020-06-09 21:32:14 UTC
Intervention completed successfully.

Date: 2020-06-09 21:26:42 UTC
clouddb0[01-29].sql007 are up-to-date. Continuing the intervention…

Date: 2020-06-09 21:00:55 UTC
The intervention is starting on sql007…

Date: 2020-06-08 22:31:17 UTC
clouddb072.sql006 is UP and running. Sorry for the delay for this host.
Intervention completed.

Date: 2020-06-08 21:58:40 UTC
All the VM are up-to-date but clouddb072.sql006 (the intervention is continuing on this last one)…

Date: 2020-06-08 21:20:38 UTC
clouddb0[01-19].sql006 are up-to-date. Continuing the intervention…

Date: 2020-06-08 21:03:28 UTC
The intervention is starting on sql006…

Date: 2020-06-04 21:50:18 UTC
Intervention completed successfully on sql008.

Date: 2020-06-04 21:34:13 UTC
clouddb0[01-23].sql008 are up-to-date. Continuing the intervention…

Date: 2020-06-04 20:59:37 UTC
The intervention is starting on sql008…

Date: 2020-06-02 19:52:37 UTC
Before going further in the massive deployment of the solution, we will first deploy a requirement everywhere: changing the Docker cgroups hierarchy. To do so, we need to restart your instance. A 2 minutes downtime is expected.

Next interventions:
- sql008 (except clouddb0[01,05,10-19].sql008, already up-to-date) on Thursday, 2020-06-04
- sql006 on Monday, 2020-06-08
- sql007 on Tuesday, 2020-06-09
- sql020 on Wednesday, 2020-06-10
- sql021 on Thursday, 2020-06-11

All the interventions start from 23:00 CEST.

Date: 2020-05-14 21:27:32 UTC
Deployment done on clouddb0[01-12,14-19].sql008.
Downtime: from 23:19 to 23:27 CEST.

Date: 2020-05-14 21:02:31 UTC
Deployment done on clouddb005.sql008.
Downtime: from 22:53 to 23:02 CEST.

Date: 2020-05-14 13:33:45 UTC
Deployment done on clouddb013.sql008.
Downtime: from 15:30 to 15:32 CEST.

Date: 2020-05-13 18:35:04 UTC
Deployment done on clouddb001.sql008.
Downtime: from 20:30 to 20:32 CEST.
Next part (clouddb0[05,10-19].sql008) tomorrow.

Date: 2020-05-13 15:07:58 UTC
As detailed on https://community.ovh.com/t/amelioration-de-la-gestion-de-la-memoire-sur-les-clouddb/28070, we have a new improvement.
This one will be deployed on clouddb001.sql008 on 2020-05-13.

Date: 2020-05-06 23:47:00 UTC
Intervention completed.

Date: 2020-05-06 23:29:03 UTC
clouddb001.sql008 restarted. It took a long time. Due to a bug in Docker, its status was inconsistent. It is now fixed. Continuing the intervention on this host…

Date: 2020-05-06 22:25:34 UTC
Intervention completed on cloudddb0[13-19].sql008: downtime from 23:30 to 00:15 CEST (about 2 minutes per instance, in this time slot).
clouddb001.sql008 does not restart as expected. Investigation in progress.

Date: 2020-05-05 22:07:47 UTC
Intervention completed.
Downtime on cloudddb01[1-2].sql008: from 23:52 to 00:07 CEST (about 2 minutes per instance, in this time slot).

Date: 2020-05-04 21:51:20 UTC
Intervention completed.
Downtime on cloudddb010.sql008: from 23:40 to 23:50 CEST (about 2 minutes per instance, in this time slot).

Date: 2020-05-04 18:23:22 UTC
Next interventions:
- 2020-05-04, from 23:00 CEST: clouddb010.sql008
- 2020-05-05, from 23:00 CEST: clouddb01[1-2].sql008
- 2020-05-06, from 23:00 CEST: clouddb0[01,13-19].sql008

Date: 2020-04-28 22:02:25 UTC
Intervention completed successfully.

Date: 2020-04-28 21:53:42 UTC
The intervention is starting on clouddb005.sql008…

Date: 2020-04-23 21:10:16 UTC
Intervention completed. Downtime: from 23:07 to 23:08 CET.

Date: 2020-04-22 19:26:35 UTC
Next interventions:
- 2020-04-23, from 23:00 CET: clouddb005.sql008, part 1/3 (you won’t see any changes there, except the 1 minute downtime)
- 2020-04-27, from 23:00 CET: clouddb005.sql008, part 2/3 (half of the instances will see the changes)
- 2020-04-28, from 23:00 CET: clouddb005.sql008, part 3/3
Posted Apr 22, 2020 - 19:26 UTC
This scheduled maintenance affected: Web Hosting || Datacenter GRA (Cluster002, Cluster003, Cluster006, Cluster007, Cluster011, Cluster012, Cluster013, Cluster014, Cluster015, Cluster017, Cluster020, Cluster021, Cluster023, Cluster024, Cluster025, Cluster026, Cluster027, Cluster028, Cluster029, Cluster030, Cluster031).