Un server MySQL cu discul la 95%, 180 GB de binary log acumulate în șase luni. De acolo pornește o călătorie prin binlog: ce conțin, de ce există, cum funcționează cu replicarea și point-in-time recovery, și mai ales cum le gestionezi fără să faci pagube.
Un client cu un MySQL standalone care cădea în fiecare lună, luând cu el întreaga aplicație. Soluția mea: un Galera Cluster cu 3 noduri și replicare sincronă. De la diagnostic la punerea în producție, cu toate fișierele de configurare și parametrii critici.
În MySQL și MariaDB identitatea unui utilizator depinde de host-ul de la care se conectează. Un caz real, modelul de autentificare explicat în profunzime și cele mai frecvente greșeli în gestionarea accesului.
O operațiune care trebuia să dureze cinci minute — extragerea unui CSV din MySQL — se transformă într-o investigație printre instanțe multiple pe același server, socket-uri Unix, porturi diferite și directiva secure-file-priv care blochează totul. De la conectarea la instanța corectă până la exportul din shell.
Filesystem la 92% pe un cluster MySQL Group Replication cu 3 noduri. Cauza? Binary logs acumulate pe volumul principal. De la alertă la migrarea pe un volum dedicat, nod cu nod, fără a pierde quorum-ul.