Utilizzo di MariaDB MaxScale come proxy del database

Configurare MaxScale come livello proxy

MariaDB MaxScale è un livello proxy autonomo tra l'applicazione e i server MariaDB. Per garantire un funzionamento affidabile, la configurazione, le funzionalità disponibili e i limiti noti devono sempre corrispondere alla versione effettivamente installata. La serie MaxScale 25.10 è riportata nella documentazione ufficiale con note di rilascio dedicate.

L'applicazione si collega a un listener di MaxScale anziché direttamente a un server di database. Un servizio raggruppa la logica di accesso, un router determina il backend e i filtri possono elaborare ulteriormente le richieste prima dell'inoltro. I dati rimangono sui backend MariaDB; MaxScale non diventa esso stesso un database.

Questa separazione è particolarmente utile quando un’applicazione non deve sapere autonomamente quale server ricopra attualmente quale ruolo. Per le nozioni di base sul modello di dati, sul linguaggio SQL e sul funzionamento del database, si veda l’articolo MariaDB come database open source un complemento adeguato. Il proxy integra l'architettura del server, ma non sostituisce né i diritti di accesso al database né un sistema di replica e di gestione dei guasti.

All'indirizzo Routing delle connessioni Quando si avvia una sessione, MaxScale seleziona una destinazione; questo backend rimane responsabile della sessione. Nel routing delle istruzioni, il router può assegnare le singole istruzioni SQL in modo diverso in base al loro contenuto. La scelta della variante più adatta dipende quindi dalle transazioni, dallo stato della sessione e dalla capacità dell’applicazione di separare in modo netto i percorsi di lettura e di scrittura.

A Proxy del database Non si tratta di una garanzia di prestazioni forfettaria. Può centralizzare il routing, disaccoppiare i cambi di ruolo delle applicazioni o distribuire le richieste di lettura appropriate. Tuttavia, i nodi di rete aggiuntivi, l’analisi SQL e la topologia concreta del backend influenzano il comportamento. La resilienza e la capacità devono quindi essere verificate con la propria versione, configurazione e carico.

Monitorare correttamente la topologia primario-replica

Un'architettura tipica è costituita da un primario in scrittura e da una o più repliche in lettura. MaxScale è l'unico endpoint del database dell'applicazione, ad esempio dietro un nome DNS fisso. L'applicazione, quindi, non si connette direttamente ai singoli host; la selezione di un backend raggiungibile e adeguato avviene all'interno del livello proxy.

Per una topologia primary-replica, il monitor determina mariadbmon lo stato dei backend e ne identifica i ruoli come Primary o Replica. I router possono utilizzare queste informazioni per la selezione delle destinazioni. Il monitor deve quindi essere in grado di rilevare la topologia di replica effettiva; assegnazioni errate, dati non replicati o ruoli poco chiari non costituiscono problemi di routing, ma rischi operativi.

Il riconoscimento di un ruolo va distinto dalla sua modifica. Con una configurazione e autorizzazioni adeguate, mariadbmon è in grado di gestire il failover, lo switchover pianificato e il rejoin. Uno switchover è un cambio di ruolo preparato in modo mirato per motivi di manutenzione o di funzionamento; un failover reagisce a un errore. Entrambe le operazioni richiedono una topologia chiara, monitoraggio, allarmi e un processo documentato di gestione degli incidenti o di ripristino.

Per le attività di puro monitoraggio, l'account di monitoraggio dovrebbe funzionare secondo il principio Privilegio minimo ricevono solo i diritti necessari. La documentazione attuale indica a tal fine REPLICA MONITOR. Sono necessari diritti aggiuntivi a seconda delle funzioni attivate, ad esempio FILE in caso di verifica dello spazio di archiviazione o altri diritti specifici per le scansioni topologiche e le operazioni sui cluster. I diritti completi generici non costituiscono un sostituto in questo caso.

Prima di procedere all’automazione, il team dovrebbe stabilire chi autorizza un cambio di ruolo, come viene verificato lo stato delle repliche e come le applicazioni vengono informate in caso di anomalie. MaxScale è in grado di adattare le destinazioni di routing in base ai ruoli rilevati. Tuttavia, è il modello di alta disponibilità, con i suoi limiti relativi a dati, tempi e responsabilità, a determinare se un cambio di ruolo sia tecnicamente ammissibile.

Comprendere il routing SQL e i limiti di coerenza

Il router readwritesplit indirizza le istruzioni SQL di scrittura al server primario e distribuisce le richieste di lettura appropriate alle repliche. In questo modo, un cluster primario-replica può sfruttare la propria capacità di lettura in modo più mirato, senza che l'applicazione debba assegnare autonomamente ogni query a un server specifico. Le informazioni sui ruoli del monitor costituiscono la base per la selezione.

Per impostazione predefinita, questa suddivisione non garantisce che una lettura rilevi lo stato aggiornato immediatamente dopo ogni scrittura. causal_reads è impostato di default su none. Se, ad esempio, un’applicazione scrive lo stato di un ordine e poi lo legge tramite una query indipendente, una replica potrebbe quindi fornire ancora lo stato precedente. Un percorso di lettura primario scelto consapevolmente o un contesto transazionale condiviso sono strategie possibili, ma non le uniche.

Per Leggi-ciò-che-scrivi Con la modalità "readwritesplit" e le "Causal Reads" attivate, è possibile tenere conto delle operazioni di scrittura precedenti nonostante il ritardo di replica. La modalità local garantisce la visibilità per lo stesso collegamento. global mantiene lo stato del GTID salvato dal servizio su tutte le sue connessioni; in questo caso, un ordine globale "happens-before" delle letture è garantito solo se tutte le transazioni rientrano in un unico dominio GTID. universal tiene conto dello stato delle transazioni del cluster osservabile sul Primary. Tuttavia, gli ambiti di applicazione più ampi aumentano il carico di sincronizzazione e, di conseguenza, potenzialmente anche la latenza.

Le letture causali utilizzano le informazioni GTID e, nelle modalità non veloci, attendono il completamento della replica. Se la sincronizzazione dura più a lungo di causal_reads_timeout – 10 secondi per impostazione predefinita –, readwritesplit tenta di eseguire la query sul primario. In una transazione in sola lettura, invece, potrebbe verificarsi un timeout come errore, poiché la query non può essere trasferita sul primario.

Le modalità veloci fast, fast_global e fast_universal non attendono una replica e, se necessario, utilizzano il primario; in quel caso il timeout non si applica. Sono quindi particolarmente adatte a carichi di lavoro prevalentemente in lettura con poche operazioni di scrittura. A partire dalla versione 24.02, MaxScale configura autonomamente il tracciamento necessario per le nuove connessioni al backend; le versioni precedenti richiedono invece last_gtid in session_track_system_variables su tutti i backend.

All’interno di una transazione aperta in lettura-scrittura, readwritesplit indirizza gli accessi in lettura al primario. Ciò impedisce che le istruzioni della stessa transazione vengano eseguite su backend con stati di replica diversi. Questa regola conservativa non esonera dal dovere di impostare i limiti delle transazioni in modo tecnicamente corretto e di trattare il ritardo di replica come un limite intrinseco dell'architettura.

Anche nel caso delle stored procedure, delle chiamate alle UDF e delle istruzioni multiple, la decisione è volutamente più cauta: nei casi documentati, tali query vengono indirizzate al server primario. Il motivo è che il loro effetto o contesto non dovrebbe essere trattato come una semplice query di lettura. L’instradamento SQL non è quindi una semplice ricerca della parola SELECT, ma segue regole per una gestione sicura delle sessioni e della semantica.

Un valore limite stabilito in base a criteri tecnici per Replica-Lag può escludere le repliche di determinate operazioni di lettura, ma non sostituisce alcun requisito di coerenza. Il ritardo accettabile dipende, ad esempio, dal fatto che una voce di catalogo obsoleta sia tollerabile o che lo stato di pagamento appena confermato debba essere necessariamente visibile. Questa decisione rientra nella logica dell’applicazione e nel contratto operativo, non in un’impostazione predefinita generale del proxy.

Configurare Readwritesplit in modo sicuro

Una configurazione Read/Write-Split è costituita da definizioni di oggetti separate per backend, monitor, servizio e listener. Il seguente frammento mostra la struttura di un file, non un modello immediatamente utilizzabile in produzione. I valori tra parentesi angolari non sono in alcun modo password, bensì riferimenti ad account e segreti che devono essere forniti tramite la gestione dei segreti dell’ambiente operativo. Il monitor e il servizio necessitano ciascuno di credenziali di accesso specifiche per le rispettive attività.

[db-primary]
type=server
address=db-primary.example.invalid
port=3306

[db-replica-1]
type=server
address=db-replica-1.example.invalid
port=3306

[db-replica-2]
type=server
address=db-replica-2.example.invalid
port=3306

[cluster-monitor]
type=monitor
module=mariadbmon
servers=db-primary,db-replica-1,db-replica-2
user=<monitor-account-from-secret-management>
password=<monitor-secret-reference>

[RW-Service]
type=service
router=readwritesplit
servers=db-primary,db-replica-1,db-replica-2
user=<service-account-from-secret-management>
password=<service-secret-reference>

[RW-Listener]
type=listener
service=RW-Service
protocol=MariaDBClient
port=3306

Gli oggetti server indicano semplicemente i backend MariaDB raggiungibili; il monitor determina, in base alla topologia, quale istanza sia primaria e quale replica. L'account del monitor viene utilizzato per le richieste relative allo stato e ai ruoli. L'account di servizio separato serve a recuperare dai backend le informazioni relative agli utenti e ai diritti necessarie per l'autenticazione e l'autorizzazione dei client. Entrambi gli account necessitano solo dei diritti documentati per il rispettivo compito. Riconoscere i ruoli Il caricamento dei dati e quello delle informazioni sugli utenti sono operazioni distinte.

I segnaposto presenti nell’esempio devono essere risolti durante la distribuzione tramite un canale protetto; non sono da intendersi come valori di configurazione letterali. Le password in chiaro, i percorsi reali dei certificati o i pacchetti di autorizzazioni non verificati non devono essere contenuti in file o repository liberamente accessibili. Per le connessioni tramite protocollo MariaDB, MaxScale gestisce internamente gli account utente e le autorizzazioni rilevanti attingendo dalle tabelle di sistema. Se gli account o le autorizzazioni vengono modificati, le informazioni non aggiornate possono compromettere il login o l’autorizzazione.

Prima della messa in produzione è quindi necessario verificare separatamente la porta del listener, i percorsi di rete, la corrispondenza degli utenti e l'effettiva assegnazione dei router. Anche gli interventi automatici del monitor non rientrano implicitamente in questa configurazione minima: le funzioni di failover, switchover o rejoin richiedono una configurazione aggiuntiva e un modello operativo collaudato. Una configurazione apparentemente semplice non sostituisce né la gestione delle chiavi segrete né la verifica della topologia del backend.

Confronta i modelli di router in base all'applicazione

La scelta del router dipende dal comportamento dell’applicazione, non solo dal numero di repliche disponibili. Le connessioni dirette semplificano la configurazione, ma lasciano all’applicazione il compito di gestire i cambiamenti di destinazione e la conoscenza dei ruoli. Due endpoint separati con readconnroute sono adatte quando l'applicazione gestisce autonomamente e in modo consapevole le connessioni di lettura e scrittura. Routing delle dichiarazioni L'opzione `readwritesplit` è utile quando si desidera indirizzare una sessione, in base alle operazioni SQL, al server primario o alle repliche.

readconnroute valuta un server di destinazione al momento dell'instaurazione della connessione e non analizza ogni istruzione SQL successiva. Se il backend selezionato smette di funzionare, la sessione termina; il router non la ricollega automaticamente a un altro server. Ciò è spesso comprensibile per connessioni di lettura ben distinte e di breve durata, ma può risultare inadatto per flussi applicativi con stato.

È necessario prestare particolare attenzione a un servizio concepito come endpoint di lettura con router_options=slave. L'opzione privilegia i server con ruolo di replica; tuttavia, se tutte le repliche sono inattive e il primario è disponibile, readconnroute può ricorrere al primario. Inoltre, l'opzione non genera alcuna protezione in scrittura. L'applicazione deve inviare esclusivamente SQL di lettura, oppure è necessario un filtro ReadOnly aggiuntivo per impedire gli accessi in scrittura. La destinazione di routing e la preferenza di ruolo non costituiscono quindi né un limite di autorizzazione né un sostituto dei diritti restrittivi sul database.

Il modello "readwritesplit", invece, riduce le decisioni relative alla destinazione nel codice dell'applicazione, ma richiede un'analisi accurata della semantica. Le operazioni di lettura idonee possono essere distribuite sulle repliche, mentre le operazioni di scrittura vengono indirizzate al primario. Per i processi con rigorosi requisiti di attualità, rimane fondamentale stabilire se una query possa attendere i dati replicati dopo una scrittura oppure debba utilizzare consapevolmente il primario.

Pianificare le riunioni, il magazzino e la transizione

Una sessione di database non si limita a una singola query. SET, USE, CHANGE USER e le operazioni con prepared statement modificano il proprio contesto. readwritesplit replica i comandi di sessione rilevanti sui possibili server di destinazione, in modo che le istruzioni instradate in un secondo momento possano essere eseguite con lo stato di sessione corretto. Ciò distingue il router dal semplice bilanciamento del carico TCP, ma non elimina ogni limite legato ai casi particolari.

Nel caso delle istruzioni preparate per le tabelle temporanee, questo limite è particolarmente importante. Se un’istruzione di questo tipo viene preparata sul server primario, le repliche non sono necessariamente in grado di eseguirla. L’applicazione dovrebbe quindi testare gli oggetti temporanei, le istruzioni preparate e i flussi delle transazioni utilizzando il modello di routing previsto. Stato della sessione non è una condizione secondaria, ma determina se una distribuzione SQL sia adeguata dal punto di vista funzionale e tecnico.

Per un'applicazione ad alta intensità di lettura, il team può definire un valore limite di lag stabilito a livello tecnico come criterio di esclusione per le repliche. Solo max_replication_lag Tuttavia, ciò non garantisce che una scrittura precedente su una replica sia già visibile. Per le letture successive critiche, a seconda del flusso di elaborazione, si possono prendere in considerazione un percorso primario intenzionale, un contesto di scrittura condiviso o letture causali attivate.

Nel caso delle letture causali, è necessario scegliere consapevolmente l'ambito di applicazione. local mantiene la causalità all’interno di una relazione. global utilizza un valore GTID memorizzato a livello di servizio, ma garantisce l'ordine globale "happens-before" delle letture solo se tutte le transazioni rientrano in un unico dominio GTID. universal tiene conto dello stato delle transazioni del cluster osservabile sul primario. Le modalità non veloci si sincronizzano con i GTID; se una replica non si allinea entro il timeout configurato, la query viene sempre ripetuta sul primario, purché la modalità di transazione lo consenta.

La funzione va classificata in base alla versione. A partire da MaxScale 24.02, MaxScale aggiunge last_gtid per le nuove connessioni al backend; nelle versioni precedenti era necessario session_track_system_variables devono essere impostate di conseguenza sui backend MariaDB. Le modalità veloci evitano i tempi di attesa, ma, nel caso di repliche non ancora allineate, possono indirizzare le operazioni di lettura verso il primario e non sono quindi adatte in generale a carichi con un'elevata intensità di scrittura.

Anche uno switchover pianificato e un failover automatico devono essere trattati separatamente. Nello switchover, il cambio di ruolo viene preparato in modo controllato, mentre nel failover il sistema reagisce a una condizione di errore. mariadbmon è in grado di monitorare i ruoli e gli stati del backend e, se configurato appositamente, può supportare questi processi. Lo stato dei dati replicati, una topologia univoca, il sistema di allarme e un processo di gestione degli incidenti rimangono requisiti indispensabili.

In MaxScale 25.10 è possibile discover-replicas Individuare i server che replicano direttamente sul primario corrente e aggiungerli a Monitor e MaxScale. Questa funzione non è compatibile con la sincronizzazione della configurazione. Prima di utilizzarla, il team deve quindi stabilire se le modifiche alla topologia debbano essere rilevate automaticamente o gestite tramite una configurazione sincronizzata; in questo contesto, non è consentito applicare entrambe le opzioni contemporaneamente.

TLS, protezione dei diritti e dei filtri

In MaxScale, il TLS deve essere configurato su due percorsi distinti: dall’applicazione al listener e dal proxy ai backend MariaDB. Entrambe le connessioni richiedono impostazioni specifiche per la crittografia e la verifica dei certificati; un percorso client protetto non crittografa automaticamente il traffico a valle. La configurazione deve quindi riflettere le esigenze di protezione e la catena di fiducia per entrambe le sezioni.

TLS abilitato ssl=true la crittografia nella rispettiva configurazione del listener o del server. Se un client richiede un certificato del server, il listener necessita del certificato e della chiave privata. Un account con REQUIRE SSL Non è possibile effettuare l'accesso tramite un listener senza TLS. I file dei certificati e le chiavi devono essere conservati in un ambiente operativo protetto, non in configurazioni di esempio o nei repository liberamente consultabili.

Anche il Concetto di diritto Rimane fondamentale a livello di backend: MaxScale gestisce le connessioni, ma non sostituisce gli account di database specifici. Agli account di servizio vengono assegnate solo le autorizzazioni necessarie per lo svolgimento delle loro funzioni. Per l’accesso e l’autorizzazione, MaxScale si basa sugli account utente e sui diritti presenti nelle tabelle di sistema di MariaDB; le modifiche apportate a tali account devono quindi essere rese disponibili tempestivamente nella gestione interna degli utenti.

Il filtro del firewall può verificare il codice SQL prima dell'inoltro sulla base di regole apprese o definite. Dispone delle modalità di inattività, apprendimento, monitoraggio e applicazione; nella modalità di applicazione, a seconda delle impostazioni, i modelli di istruzione non consentiti ricevono una risposta di errore oppure la connessione viene interrotta. La fase di apprendimento deve coprire flussi applicativi rappresentativi e consentiti, affinché il filtro non blocchi query regolari.

Il filtro costituisce un ulteriore livello di controllo per i modelli SQL previsti, non un’autorizzazione sostitutiva. Restano comunque necessari diritti di accesso restrittivi al database, credenziali protette e codice applicativo verificato, poiché il filtro valuta solo le richieste che gli pervengono in base alle proprie regole. Le affermazioni relative ad altri filtri dovrebbero essere verificate separatamente sulla base della rispettiva documentazione.

Verificare sistematicamente la configurazione e gli errori

In caso di errori di connessione o di routing, è utile seguire una sequenza di verifica prestabilita anziché apportare modifiche a caso. Controlla innanzitutto lo stato del monitor: tutti i backend sono raggiungibili e i ruoli Primary e Replica vengono riconosciuti come previsto? Solo allora è possibile valutare in modo sensato le decisioni del router. Un nodo riconosciuto in modo errato o non raggiungibile non è un problema esclusivamente legato al listener.

Seguono poi il listener e il TLS: porta, protocollo, certificato, chiave e i requisiti degli account utilizzati devono corrispondere. Verifica infine che il sistema di gestione degli account utente riconosca gli account e i diritti attuali nel backend. Soprattutto dopo modifiche agli utenti o alle autorizzazioni, dati degli account non aggiornati possono impedire l’accesso, anche se l’account è configurato correttamente su MariaDB.

Successivamente, assegna il servizio, il router e i server previsti. Nel caso del read/write splitting, occorre inoltre considerare il replica-lag, causal_reads e i limiti di transazione dell'applicazione nella lista di controllo. Se le letture causali non sono attivate, una lettura effettuata al di fuori del contesto di scrittura richiesto su una replica può fornire uno stato precedente; un limite di ritardo da solo non garantisce la visibilità di una scrittura precedente.

Inserisci inoltre un unico Fonte di configurazione fissa. MaxScale può salvare le modifiche durante l'esecuzione; al riavvio, la configurazione salvata può sovrascrivere i file statici. Se un team modifica in parte i file e in parte maxctrl Se viene utilizzata, è necessario documentare in modo vincolante la procedura di modifica, la revisione e il salvataggio di tale configurazione di runtime.

Le finestre di manutenzione per le modifiche allo schema devono essere gestite come un ambito operativo a sé stante: è necessario verificare in anticipo le dipendenze, il comportamento dei blocchi e la replica, senza attribuire la responsabilità al proxy. Per la pianificazione di modifiche controllate a tabelle MariaDB di grandi dimensioni, l’articolo su Modifiche allo schema senza tempi di inattività contesto aggiuntivo. MaxScale può quindi gestire nuovamente le connessioni e il routing in base ai ruoli del backend, ma non esegue alcuna strategia DDL del database.

Avviso: è consigliabile testare prima le modifiche relative a ruoli, certificati, diritti utente e routing in un ambiente simile. Per l’intervento in produzione è necessario prevedere una procedura di ripristino, il monitoraggio degli errori dell’applicazione e chiare responsabilità. In questo modo è possibile distinguere se un malfunzionamento deriva dalla configurazione del proxy, dal backend o dal comportamento del client.

Utilizzare MaxScale in modo appropriato oppure evitarlo

Nel caso di un singolo server MariaDB senza esigenze di routing, commutazione o filtri SQL, le connessioni dirette rappresentano solitamente la modalità operativa più semplice. L’applicazione dovrà però gestire autonomamente un eventuale cambio di destinazione in un secondo momento. MaxScale è utile quando l’endpoint aggiuntivo svolge un compito specifico, come gestire il cambio di ruolo, filtrare gli accessi o distribuire in modo controllato le operazioni di lettura sulle repliche.

Se l'applicazione è in grado di scegliere autonomamente i percorsi di lettura e scrittura, gli endpoint separati con readconnroute spesso comprensibile. Questo router seleziona un backend al momento della connessione, ma non analizza ogni istruzione SQL e non trasferisce una sessione interrotta su un altro server. In caso di router_options=slave Si preferiscono le repliche; se tutte le repliche sono inattive e il primario è ancora disponibile, il router può utilizzare il primario. Inoltre, questa opzione non rende l'endpoint di sola lettura. A tal fine sono necessari un filtro ReadOnly adeguato, diritti restrittivi sul backend o un codice SQL dell'applicazione sottoposto a controllo rigoroso.

Per i carichi di lavoro di tipo Primary-Replica, il cui ORM e modello transazionale siano compatibili, si utilizza readwritesplit L'applicazione esegue la selezione della destinazione SQL per ogni istruzione. Nell'impostazione predefinita causal_reads=none il ritardo di replica rimane tuttavia visibile. Dopo operazioni di scrittura critiche, l'applicazione può utilizzare un percorso di lettura primario o un contesto transazionale condiviso adeguato; in alternativa, è possibile configurare in modo mirato le letture causali per l'ambito di visibilità richiesto.

I "Causal Reads" distinguono tra la visibilità all'interno della stessa sessione, un valore GTID globale gestito dal servizio e lo stato del cluster osservabile sul nodo primario. local vale per la stessa connessione. Nel caso di global L'ordine globale "happens-before" delle operazioni di lettura è garantito solo se tutte le transazioni appartengono a un unico dominio GTID; tale modalità non deve quindi essere interpretata in modo generalizzato come una garanzia illimitata di coerenza a livello di servizio. universal Verifica lo stato osservabile sul primario prima delle operazioni di lettura. Le modalità di sincronizzazione possono generare tempi di attesa aggiuntivi; le varianti veloci non attendono, ma possono spostare maggiormente il carico verso il primario durante le operazioni di scrittura.

I casi limite richiedono test mirati con il driver e il modello di dati reali prima dell'implementazione. Le tabelle temporanee e le istruzioni preparate su di esse potrebbero non essere disponibili sulle repliche se la preparazione avviene sul primario. Anche le stored procedure, le chiamate alle UDF, le istruzioni multiple e lo stato della sessione influenzano la decisione del router di instradare in modo conservativo verso il primario.

La funzione "Transaction Replay" non garantisce transazioni prive di perdite. Se una connessione si interrompe durante COMMIT , non è necessario stabilire se il commit sia già stato eseguito con successo. Alcune configurazioni di replay rischiose possono eseguire due volte le operazioni di scrittura; i risultati che dipendono dal server, come NOW() oppure @@server_id possono inoltre causare discrepanze nei checksum. Valuta quindi l'utilizzo in base ai requisiti di coerenza, alle sequenze di errori e alla ripetibilità delle operazioni di scrittura, non sulla base di promesse generiche in termini di prestazioni.