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.
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.
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-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).