FS#44194 — CloudDB (PrivateSQL)
Attached to Project— Web Hosting / CloudDB
Amélioration | |
GRA / All clusters | |
CLOSED | |
![]() |
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.
Date: Thursday, 09 July 2020, 00:29AMCette 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.
Reason for closing: Done
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
Intervention completed. Downtime: from 23:07 to 23:08 CET.
The intervention is starting on clouddb005.sql008…
Intervention completed successfully.
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
Intervention completed.
Downtime on cloudddb010.sql008: from 23:40 to 23:50 CEST (about 2 minutes per instance, in this time slot).
Intervention completed.
Downtime on cloudddb01[1-2].sql008: from 23:52 to 00:07 CEST (about 2 minutes per instance, in this time slot).
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.
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…
Intervention completed.
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.
Deployment done on clouddb001.sql008.
Downtime: from 20:30 to 20:32 CEST.
Next part (clouddb0[05,10-19].sql008) tomorrow.
Deployment done on clouddb013.sql008.
Downtime: from 15:30 to 15:32 CEST.
Deployment done on clouddb005.sql008.
Downtime: from 22:53 to 23:02 CEST.
Deployment done on clouddb0[01-12,14-19].sql008.
Downtime: from 23:19 to 23:27 CEST.
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.
The intervention is starting on sql008…
clouddb0[01-23].sql008 are up-to-date. Continuing the intervention…
Intervention completed successfully on sql008.
The intervention is starting on sql006…
clouddb0[01-19].sql006 are up-to-date. Continuing the intervention…
All the VM are up-to-date but clouddb072.sql006 (the intervention is continuing on this last one)…
clouddb072.sql006 is UP and running. Sorry for the delay for this host.
Intervention completed.
The intervention is starting on sql007…
clouddb0[01-29].sql007 are up-to-date. Continuing the intervention…
Intervention completed successfully.
The intervention is starting on sql020…
Intervention completed successfully.
The intervention is starting on sql021…
Intervention completed successfully.
Time to finish that =)
Next intervention:
- Monday 2020-07-06: sql008 (clouddb0[01,05,10-19].sql008 is already up-to-date)
The intervention is starting…
clouddb0[01-24].sql008 are up-to-date. Continuing…
Intervention completed successfully.
Next intervention tomorrow (2020-07-07), from 23:00 CEST:
- sql006
- sql007
And the following intervention will be on 2020-07-08, from 23:00 CEST:
- sql020
- sql021
- sql059
The intervention is starting on sql006 and sql007…
clouddb00[1-9].sql006: done.
clouddb00[1-4].sql007: done.
Continuing…
clouddb0[01-39].sql006: done.
clouddb0[01-24].sql007: done.
Continuing…
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
The intervention is starting on sql020 and sql021…
sql020: clouddb00[1-4]: done. Continuing…
sql021: clouddb00[1-4]: done. Continuing…
sql059: Starting…
sql020: clouddb00[1-9]: done. Continuing…
sql021: clouddb00[1-9]: done. Continuing…
sql059: done. (that's a tiny cluster for now)
Intervention completed successfully.
I personally think that this is a great step forward. Enjoy =)