# OPTIM-01 — Tuning MariaDB

**Date** : 2026-06-24
**Serveur** : 51.158.96.239 — MariaDB 10.11.14, 3.8 Go RAM, 3 vCPU (partagé avec Apache+PHP)
**Méthode** : fichier dédié `/etc/mysql/mariadb.conf.d/99-tlo-optim.cnf` (rollback = supprimer le fichier + restart)

## Baseline (avant)
| Variable | Avant | Constat |
|----------|-------|---------|
| `innodb_buffer_pool_size` | 128 Mo | Trop petit ; toute la DB (~700 Mo) tient en RAM si on monte |
| `tmp_table_size` / `max_heap_table_size` | ~16 Mo | **31% des tables temp sur disque** (26997/87297) |
| `innodb_flush_log_at_trx_commit` | 1 | Durabilité max, écritures plus lentes |
| `slow_query_log` | OFF | Pas de visibilité sur les requêtes lentes |
| `thread_cache_size` | défaut | — |

## Changements appliqués
```ini
[mysqld]
innodb_buffer_pool_size        = 1G       # 128M -> 1G : cache ~toute la DB en RAM
innodb_flush_log_at_trx_commit = 2        # WP/CMS : perte max ~1s sur crash OS, gros gain ecritures
innodb_flush_method            = O_DIRECT # deja actif, garde explicite
tmp_table_size                 = 64M      # moins de tables temp sur disque
max_heap_table_size            = 64M
# thread_cache_size : NON modifie (deja a 151 sur le serveur)
slow_query_log                 = 1        # diagnostic
slow_query_log_file            = /var/log/mysql/mariadb-slow.log
long_query_time                = 1
log_slow_verbosity             = query_plan
```

### Justification mémoire
buffer pool 1 Go + buffers par connexion (max ~53 connexions vues) + tmp tables (alloués à la demande).
RAM libre avant : ~2.2 Go → reste ~1.3 Go pour Apache/PHP/OS après le bump. Marge sûre.

### Compromis assumé
`innodb_flush_log_at_trx_commit=2` : en cas de crash **système** (pas juste MySQL), on peut perdre
jusqu'à ~1 s de transactions. Acceptable pour un site éditorial (pas de transactions financières).

## Versioning
- Snapshot avant : `snapshots/mariadb/50-server.cnf.before` + `variables.before.txt`
- Fichier ajouté : `snapshots/mariadb/99-tlo-optim.cnf`
- Snapshot après : `variables.after.txt`

## Procédure & rollback
1. Écrire `99-tlo-optim.cnf`, `systemctl restart mariadb` (blip ~5-10 s).
2. Si `mariadb` ne redémarre pas → `rm 99-tlo-optim.cnf` + restart (retour baseline).
3. Vérifs : variables appliquées, site HTTP 200, slow log actif.

## Résultat (vérifié 2026-06-24)
- `innodb_buffer_pool_size` = 1073741824 (1 Go) ✅
- `tmp_table_size` = `max_heap_table_size` = 67108864 (64 Mo) ✅
- `innodb_flush_log_at_trx_commit` = 2 ✅
- `slow_query_log` = ON, `long_query_time` = 1, `log_slow_verbosity` = query_plan ✅
- Slow log créé : `/var/log/mysql/mariadb-slow.log` (mysql:mysql)
- Site `/` + `/artiste/…` → HTTP 200 ; maintenance root (unix_socket) OK ; RAM libre ~2.5 Go

> **Suivi** : laisser tourner quelques jours puis analyser `mariadb-slow.log`
> (`mariadb-dumpslow -s t /var/log/mysql/mariadb-slow.log`) pour cibler les requêtes/index.

## Statut : ✅ APPLIQUÉ