Feed Aggregator

Description du problème

MySQL a introduit le InnoDB buffer pool configurable dynamiquement dans la version 5.7.5 en septembre 2014 (ici et ici) :

The innodb_buffer_pool_size configuration option can be set dynamically using a SET statement, allowing you to resize the buffer pool without restarting the server. For example:

mysql> SET GLOBAL innodb_buffer_pool_size=402653184;

MariaDB 10.2.2 a repris cette fonctionnalité en septembre 2016 (source) :

InnoDB was merged from MySQL-5.7.14 (XtraDB is disabled in MariaDB-10.2.2 pending a similar merge)

Le problème est, d’une part, que cette fonctionnalité ne fonctionne plus comme avant et ne fonctionne plus comme prévu. D’autre part, ils ont modifié le comportement au printemps 2025 dans le cadre d’une série de versions majeures (LTS), ce qui, à mon avis, est absolument inacceptable (source) :

From MariaDB 10.11.12 / 11.4.6 / 11.8.2, there are significant changes to the InnoDB buffer pool behavior.

De plus, la description à ce sujet est …

Lors de ma dernière intervention chez le client, celui-ci est venu me voir, rayonnant de joie, pour me dire qu’il avait suivi mon conseil et changé toutes les colonnes de clé primaire de BIGINT (8 octets) à INT (4 octets), et que cela avait beaucoup apporté ! Sa base de données MySQL 8.4 avait désormais perdu 750 Go (sur 5,5 To). Super!

Et oui, je sais que cela contredit les recommandations de certains de mes collègues PostgreSQL (ici et ici). Dans le monde MySQL, on accorde plutôt de l’importance à ce genre de choses (source):

Use the most efficient (smallest) data types possible. MySQL has many specialized types that save disk space and memory. For example, use the smaller integer types if possible to get smaller tables

De plus, InnoDB fonctionne un peu différemment (table clusterée et clé primaire dans toutes les clés secondaires) de PostgreSQL (table heap, index avec pointeur de ligne (ctid)).

Mais ce n’est pas vraiment le sujet. Immédiatement après, il a demandé si la mise à NULL des …

Lorsque nous travaillons avec PostgreSQL sous notre myEnv, nous obtenons régulièrement des erreurs de segment de mémoire partagée. Exemple:

psql: error: connection to server on socket "/tmp/.s.PGSQL.5433" failed:
FATAL:  could not open shared memory segment "/PostgreSQL.4220847662":
No such file or directory

ou nous voyons des messages similaires dans le journal d’erreurs PostgreSQL:

ERROR:  could not open shared memory segment "/PostgreSQL.4220847662":
No such file or directory

Comme je suis administrateur MariaDB/MySQL, je ne m’y connais pas très bien en matière de problèmes de mémoire partagée (MariaDB/MySQL ne fonctionne pas avec la mémoire partagée). Heureusement, une recherche sur Internet nous a mis sur une piste (source). On y trouve la mention suivante:

The documentation of systemd states that this only happens for non-system users. Can you check whether your “postgres” user (or whatever you are using) is a system user?

Utilisateur du système Linux …

Récemment, j’ai voulu représenter sur une carte les lieux de résidence des membres de mon association (membres IGOC) pour un petit projet personnel. Je connaissais les adresses des membres de l’association, mais pas les coordonnées de leurs lieux de résidence.

Je me suis donc mis à la recherche des coordonnées et j’ai trouvé ce que je cherchais auprès de l’Office fédéral de topographie (swisstopo).

Les données y sont mises à disposition sous forme de fichier CSV. Détails ici : Coordonnées des localités suisses.

Comment charger ces données dans une base de données ?

Chargement des données avec MariaDB/MySQL

MariaDB et MySQL disposent pour cela de la commande LOAD DATA INFILE:

SQL> DROP TABLE IF EXISTS wgs84;

SQL> -- SET GLOBAL local_infile = ON;   -- Only needed with MySQL

SQL> CREATE TABLE wgs84 (
  ortschaftsname VARCHAR(32)
, plz4 SMALLINT
, zusatzziffer SMALLINT
, zip_id SMALLINT UNSIGNED
, gemeindename VARCHAR(32)
, bfs_nr SMALLINT
, kantonskuerzel CHAR(2)
, …

Services neutres et indépendants des fabricants
pour MariaDB, Galera Cluster et MySQL !

Services pour MariaDB, Galera et MySQL

Nous proposons les services suivants :

• Conseil neutre et indépendant des fabricants pour MariaDB, Galera Cluster, MySQL et Percona Server.
• Abonnements au support Enterprise pour MariaDB, Galera Cluster et MySQL.
• Formations/séminaires MariaDB, Galera et MySQL pour les administrateurs de bases de données (DBA) et les développeurs.
• Grâce à nos services remote-DBA, nous vous aidons à exploiter vos bases de données MariaDB et MySQL critiques pour votre activité.
• Nos produits logiciels : OpsCenter, Performance Monitor, Backup/Recovery Manager et myEnv vous assistent dans l’exploitation de votre infrastructure.

Pour plus d’informations, contactez-nous…

Formations MariaDB, Galera et MySQL prévues

Pour plus d’informations sur notre programme de formation continue, consultez la rubrique Formations/séminaires …

Une page test en allemand…

Vous pouvez nous contacter comme suit:

Introduction

Deux points pour commencer:

1. Un deadlock est un état dans lequel deux transactions différentes ne sont plus en mesure de continuer à travailler, car chaque transaction détient un verrou dont l’autre transaction aurait besoin. Comme les deux transactions attendent que l’autre libère son verrou, aucune des deux transactions ne libérera son verrou. Et cela durerait jusqu’à la saint-glinglin. Pour éviter cela, l’instance MariaDB intervient et tue rapidement la transaction qui a fait le moins de travail. L’application reçoit alors un message d’erreur de type “deadlock”:

   ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
   

2. Dans l’écosystème MariaDB, il est généralement admis qu’un SELECT ne provoque pas de verrouillage (exception : FOR UPDATE ou LOCK IN SHARE MODE) et ne peut donc pas faire partie d’un deadlock.

Le problème

Un client de longue date se présente à l’équipe DBA à distance de …

Que cherches-tu exactement?