Feed Aggregator

Descrizione del problema

MySQL ha introdotto il buffer pool InnoDB configurabile dinamicamente con la versione 5.7.5 nel settembre 2014 (qui e qui):

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 ha adottato questa funzione nel settembre 2016 (fonte):

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

Il problema è, da un lato, che questa funzione ora non funziona più come prima e non funziona più come previsto. D’altra parte, nella primavera del 2025 hanno modificato il comportamento all’interno di una serie di release principali (LTS), cosa che a mio parere è assolutamente inaccettabile (fonte):

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

Inoltre, la descrizione è piuttosto scarsa ( …

Durante l’ultima consulenza presso il cliente, questi mi è venuto incontro raggiante dicendomi che aveva seguito il mio consiglio e aveva modificato tutte le colonne Primary Key da BIGINT (8 byte) a INT (4 byte) e che questo aveva portato grandi vantaggi! Il suo database MySQL 8.4 era ora più piccolo di 750 Gbyte (da 5,5 Tbyte). Fantastico!

E sì, so che questo contraddice le raccomandazioni di alcuni dei miei colleghi PostgreSQL (qui e qui). Nel mondo MySQL si dà più importanza a queste cose (fonte):

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

Inoltre, InnoDB funziona in modo leggermente diverso (tabella clusterizzata dell’indice e chiave primaria in tutte le chiavi secondarie) rispetto a PostgreSQL (tabella heap, indici con puntatore di riga (ctid)).

Ma in realtà non è questo il punto. Subito dopo mi ha chiesto se riempire le colonne di tipo …

Quando lavoriamo con PostgreSQL su myEnv, riceviamo regolarmente errori relativi al segmento di memoria condivisa. Esempio:

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

oppure vediamo messaggi simili nel log degli errori di PostgreSQL:

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

Essendo un amministratore MariaDB/MySQL, non ho molta familiarità con i problemi relativi alla memoria condivisa (MariaDB/MySQL non funziona con la memoria condivisa). Fortunatamente, una ricerca su Internet ci ha portato su una pista (fonte). Qui si legge:

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?

Utente di sistema Linux

Per prima cosa ho dovuto capire cosa fosse un utente di sistema in Linux. …

Recentemente, per un piccolo gioco personale, ho voluto rappresentare su una mappa i luoghi di residenza dei membri della mia associazione (IGOC Mitglieder). Conoscevo gli indirizzi dei membri dell’associazione, ma non le coordinate dei loro luoghi di residenza.

Così mi sono messo alla ricerca delle coordinate e le ho trovate presso l’Ufficio federale di topografia (swisstopo).

I dati sono disponibili in formato CSV. Maggiori dettagli qui: Coordinate delle località svizzere.

Come si caricano questi dati in un database?

Caricamento dei dati con MariaDB/MySQL

MariaDB e MySQL dispongono del comando 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)
, adressenanteil varchar(8)
, e DOUBLE
, n DOUBLE
, sprache VARCHAR(8)
, validity …

Servizi neutrali e indipendenti dal produttore
per MariaDB, Galera Cluster e MySQL!

Servizi per MariaDB, Galera e MySQL

Offriamo i seguenti servizi:

• Consulenza neutrale e indipendente dal produttore per MySQL, Galera Cluster, MariaDB e Percona Server.
• Abbonamenti di assistenza Enterprise per MariaDB, Galera Cluster e MySQL.
• Corsi di formazione/seminari su MariaDB, Galera e MySQL per amministratori di database (DBA) e sviluppatori.
• Con i nostri servizi remote-DBA vi aiutiamo a gestire i vostri database MariaDB e MySQL critici per l’azienda.
• I nostri prodotti software: OpsCenter, Performance Monitor, Backup/Recovery Manager e myEnv vi supportano nella gestione della vostra infrastruttura.

Per ulteriori informazioni, contattateci …

Corsi di formazione MariaDB, Galera e MySQL in programma

Per ulteriori informazioni sul nostro programma di formazione, consultate la pagina Corsi di formazione/seminari MariaDB, Galera e MySQL.

Una pagina di prova in tedesco…

Potete contattarci nei seguenti modi:

Introduzione

Due punti per iniziare:

1. Un deadlock è uno stato in cui due transazioni diverse non sono più in grado di continuare a lavorare perché ciascuna transazione detiene un blocco di cui l’altra transazione avrebbe bisogno. Poiché entrambe le transazioni stanno aspettando che l’altra transazione rilasci il proprio blocco, nessuna delle due rilascerà il proprio blocco. E questo durerebbe fino a dopodomani. Per evitare ciò, l’istanza di MariaDB interviene e uccide la transazione che ha svolto meno lavoro. L’applicazione riceve quindi un messaggio di errore di deadlock del tipo:

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

2. Il mantra generale nell’ecosistema MariaDB è che una SELECT non causa blocchi (eccezione: FOR UPDATE o LOCK IN SHARE MODE) e quindi non può essere parte di un deadlock.

Il problema

Un cliente di lunga data si rivolge al team di DBA remoti di FromDual con la richiesta di spiegare una situazione di deadlock: …

Cosa stai cercando esattamente?