Aller au contenu

Bases de données Mis à jour le 2026-05-29

Auto-configuration base de données

Comment Stack Harbor PaaS dimensionne les paramètres moteur MySQL, MariaDB, Percona et PostgreSQL selon les limites de ressources du conteneur — et comment surcharger.

Stack Harbor PaaS dimensionne un petit ensemble de paramètres moteur selon les ressources allouées au conteneur, pour que MySQL, MariaDB, Percona et PostgreSQL ne tournent pas sur des valeurs par défaut qui ignorent la RAM et le CPU réellement disponibles.

Cette page couvre les paramètres auto-configurés, quand ils sont recalculés, et comment désactiver l’auto-configuration quand vous voulez les gérer à la main.

MySQL / MariaDB / Percona

La plateforme gère quatre paramètres dans /etc/my.cnf, dimensionnés selon la limite de ressources du conteneur :

  • key_buffer_size
  • table_open_cache
  • myisam_sort_buffer_size
  • innodb_buffer_pool_size

À partir de MySQL 5.7, MySQL 8.0, Percona à la version équivalente et MariaDB 10.x, deux paramètres supplémentaires sont ajoutés :

  • innodb_buffer_pool_instances — note : déprécié dans MariaDB à partir de 10.6.x (la valeur est toujours 1 pool instance à partir de cette version).
  • innodb_buffer_pool_chunk_size

Chaque redimensionnement vertical relance la passe de dimensionnement selon la nouvelle limite. Vous n’avez pas besoin de redémarrer la base après un redimensionnement pour que le nouveau dimensionnement s’applique — la plateforme s’en occupe.

PostgreSQL

Pour les conteneurs PostgreSQL, deux paramètres dans /var/lib/pgsql/data/postgresql.conf sont gérés :

  • shared_buffers — une fraction de la RAM totale. Un quart de la RAM si le conteneur a huit cloudlets ou plus, un septième sinon ; le plancher est 128 Ko.
  • max_stack_depth — ulimit -s moins 1024, en Mo.

Ces valeurs sont recalculées au redimensionnement, comme pour la famille MySQL.

Désactiver l’auto-configuration

Pour gérer ces paramètres à la main, vous avez deux options.

Les conteneurs courants

Positionner la variable d’environnement JELASTIC_AUTOCONFIG à false, disable ou 0. La plateforme cessera de toucher aux paramètres gérés, et vos modifications de /etc/my.cnf (ou postgresql.conf) survivront aux mises à jour futures.

Conteneurs hérités

Les conteneurs plus anciens utilisent une ligne marqueur en tête du fichier de configuration :

#Jelastic autoconfiguration mark.

Retirez cette ligne et vos modifications manuelles en dessous seront préservées. Laissez-la en place et la plateforme écrasera les paramètres gérés à la prochaine passe de mise à jour.

Surcharger sans désactiver l’autoconfig

Pour les conteneurs de la famille MySQL, une alternative plus propre est de déposer les surcharges dans /etc/mysql/conf.d/my_custom.cnf. Les paramètres de ce fichier ont priorité sur /etc/my.cnf, y compris sur les valeurs auto-configurées, et la plateforme ne gère pas my_custom.cnf. Vous gardez les valeurs gérées par la plateforme pour tout le reste.

PostgreSQL n’a pas de mécanisme conf.d intégré au même endroit — gérez postgresql.conf directement après avoir retiré la marque autoconfig, ou utilisez le SQL ALTER SYSTEM qui écrit dans postgresql.auto.conf.

Quand désactiver l’autoconfig

La plupart des charges fonctionnent mieux avec les valeurs auto-configurées qu’avec des valeurs par défaut codées à la main — le dimensionnement de la plateforme suit la limite de ressources du conteneur, donc un redimensionnement vertical met aussi à jour la taille du buffer pool.

Désactivez l’autoconfig quand :

  • Une charge de requêtes a besoin d’un innodb_buffer_pool_size plus grand ou plus petit que la valeur par défaut.
  • Vous êtes en mesure de performance et voulez un contrôle strict du dimensionnement du buffer.
  • Une extension ou un mode de réplication spécifique exige qu’un paramètre géré soit à une valeur autre que celle par défaut.

Dans tous les autres cas, laisser l’autoconfig actif fait que le redimensionnement fonctionne tel quel.

Voir aussi