Cosa facciamo · Dati e web: Database in cluster con Percona XtraDB Cluster
La vostra applicazione parla con un solo database, ma dietro ci sono tre copie sincrone, ciascuna su hardware separato. Una scrittura confermata esiste su ogni nodo prima che la vostra applicazione senta «OK», quindi perdere un server, applicargli le patch o riavviarlo è lavoro di routine, non un'interruzione.
Cos'è
Percona XtraDB Cluster è compatibile con MySQL ed è costruito sulla replica sincrona Galera. La vostra applicazione WordPress, Magento, PrestaShop, Laravel o PHP personalizzata continua a parlare MySQL puro. Quello che cambia è sotto: non resta nessun database server singolo il cui guasto porti giù l'intero sito.
Affianchiamo al cluster ProxySQL, che invia le scritture a un nodo eletto e distribuisce le letture su tutti. L'applicazione non ha bisogno di modifiche né di conoscere la topologia.
Come lo costruiamo
- Tre nodi, tre failure domain. Ogni nodo gira sul proprio blade o sulla propria macchina virtuale e, dove la piattaforma lo consente, ciascuno si avvia e conserva i dati su un array di storage diverso. Un guasto di un host o di un array costa una replica, mai il quorum.
- ProxySQL come sidecar locale su ogni nodo web. Non c'è un load balancer di database condiviso che diventi il prossimo single point of failure. Il monitor di salute Galera-aware di ProxySQL segue lo stato del cluster e, se il writer cade, ne promuove uno nuovo in pochi secondi.
- Letture causali per i redattori. Abilitiamo i controlli di lettura sincrona, così un redattore che salva su un nodo e ricarica da un altro vede sempre la propria modifica. Niente ticket del tipo «il mio articolo è sparito».
- Spazio per rientrare. La cache dei write set è dimensionata perché un nodo possa restare offline per ore di manutenzione e rientrare in modo incrementale, invece di ricopiare l'intero dataset.
- Backup ogni trenta minuti. Percona XtraBackup esegue backup fisici consistenti a caldo, che vengono compressi e prelevati da un host di backup separato. Il lato produzione non invia mai nulla all'infrastruttura di backup.
- Sorvegliato di continuo. Ogni nodo è in Percona Monitoring and Management.
Su OpenShift valgono le stesse regole (h3)
Quando il database gira su OpenShift o OKD, gira come StatefulSet con anti-affinity rigida tra chassis e un PodDisruptionBudget che mantiene intatto il quorum. Un riavvio a rotazione dei nodi dovuto a un aggiornamento di piattaforma non può quindi mai fermare più di un membro del database alla volta. È lo standard di progettazione a cui costruiamo su ogni piattaforma container, non un extra opzionale.
Da cosa vi protegge
- L'interruzione classica: tutto il sito è giù perché l'unico server MySQL è giù.
- Le tempeste di deadlock dovute alle scritture su tutti i nodi contemporaneamente, che le configurazioni round robin ingenue producono sotto il carico dei plugin WordPress ed e-commerce.
- Redattori che perdono un salvataggio perché la lettura successiva ha colpito un nodo che non l'aveva ancora applicato.
- Finestre di manutenzione per aggiornamenti del kernel, patch del database e interventi hardware.
- Un array di storage o uno chassis che porta giù il database con sé.
- Un rolling update di Kubernetes che rompe silenziosamente il quorum.
In pratica
Una piattaforma di analytics. Per la piattaforma di analytics e transazionale di un cliente abbiamo costruito il livello transazionale su Percona XtraDB Cluster con ProxySQL e un indirizzo floating. Prima della consegna abbiamo rimosso il writer di proposito: ProxySQL ha spostato le scritture su un nodo superstite e l'applicazione ha continuato a lavorare.
Perché EuroVPS
- Progettiamo i failure domain, non solo il cluster: host diversi, array diversi, chassis diversi.
- Nessun proxy di database condiviso nel mezzo. Ogni nodo web instrada le proprie query.
- I backup sono fisici, frequenti e prelevati dal lato backup, mai inviati dalla produzione.
- Testiamo il failover prima della consegna, con l'applicazione del cliente che gira contro il cluster.
- La stessa disciplina su macchine virtuali, bare metal e OpenShift.
Domande frequenti
- Dobbiamo modificare la nostra applicazione? No. ProxySQL espone un normale endpoint MySQL. Le applicazioni che scrivono su tabelle non transazionali o si affidano a locking inusuali vengono prima riviste insieme a voi.
- È compatibile con MySQL o con MariaDB? Percona XtraDB Cluster è un server compatibile con MySQL. Migriamo database MySQL e MariaDB su di esso e controlliamo set di caratteri, plugin di autenticazione e SQL mode durante la migrazione.
- La replica sincrona a tre nodi rallenta le scritture? Ogni commit attende che gli altri nodi lo certifichino, quindi la latenza tra i nodi conta. Per questo tutti i membri stanno sullo stesso fabric a bassa latenza in un unico datacenter, con le copie offsite gestite da repliche asincrone.
- Possiamo farlo girare dentro OpenShift? Sì, come StatefulSet con anti-affinity tra chassis e un PodDisruptionBudget, che è il nostro standard per qualsiasi database basato su quorum su Kubernetes.
- Che cosa succede durante il guasto di un nodo? I nodi superstiti mantengono il quorum e continuano a servire. ProxySQL instrada attorno al nodo mancante e, quando questo torna, si riallinea in modo incrementale.
Volete un database che regga la perdita di un server? Parla con un ingegnere.
Il vostro prossimo partner per l'infrastruttura
Guardiamo la vostra infrastruttura.
Raccontateci cosa fate girare oggi e cosa deve migliorare. Un ingegnere esaminerà la vostra richiesta e vi aiuterà a pianificare il passo successivo.
+357 222 32280
Partiamo dalla vostra infrastruttura.
Un po' di contesto ci aiuta a iniziare la conversazione giusta.