MariaDB
 sql >> Database >  >> RDS >> MariaDB

Novità di MariaDB MaxScale 2.4

MaxScale 2.4 è stato rilasciato il 21 dicembre 2019 e ClusterControl 1.7.6 supporta il monitoraggio e la gestione fino a questa versione. Tuttavia, per la distribuzione, ClusterControl supporta solo fino alla versione 2.3. È necessario aggiornare manualmente l'istanza manualmente e, fortunatamente, i passaggi di aggiornamento sono molto semplici. Basta scaricare l'ultima versione dalla pagina di download di MariaDB MaxScale ed eseguire il comando di installazione del pacchetto.

I seguenti comandi mostrano come eseguire l'aggiornamento da un MaxScale 2.3 esistente a MaxScale 2.4 su una scatola CentOS 7:

$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10

In questo post del blog, evidenzieremo alcuni dei notevoli miglioramenti e nuove funzionalità di questa versione e come appare in azione. Per un elenco completo delle modifiche in MariaDB MaxScale 2.4, controlla il log delle modifiche.

Cronologia comandi modalità interattiva

Questo è fondamentalmente un piccolo miglioramento con un grande impatto sull'amministrazione di MaxScale e sul monitoraggio dell'efficienza delle attività. La modalità interattiva per MaxCtrl ora ha la sua cronologia dei comandi. La cronologia dei comandi consente di ripetere facilmente il comando eseguito premendo il tasto freccia su o giù. Tuttavia, la funzionalità Ctrl+R (richiama l'ultimo comando corrispondente ai caratteri forniti) non è ancora disponibile.

Nelle versioni precedenti, è necessario utilizzare la modalità shell standard per assicurarsi che i comandi vengano acquisiti dal file .bash_history.

Monitoraggio GTID per galeramon

Questo è un buon miglioramento per coloro che sono in esecuzione su Galera Cluster con ridondanza geografica tramite replica asincrona, nota anche come replica da cluster a cluster, o replica MariaDB Galera Cluster su replica MariaDB.

In MaxScale 2.3 e versioni precedenti, ecco come appare se hai abilitato la replica master-slave tra cluster MariaDB:

Per MaxScale 2.4, ora ha questo aspetto (prestare attenzione a Galera1's riga):

Ora è più facile vedere lo stato di replica per tutti i nodi da MaxScale, senza la necessità di controllare ripetutamente i singoli nodi.

SmartRouter

Questa è una delle nuove funzionalità principali di MaxScale 2.4, in cui MaxScale è ora abbastanza intelligente da apprendere quale server backend MariaDB di backend è il migliore per elaborare la query. SmartRouter tiene traccia delle prestazioni, o del tempo di esecuzione, delle query ai cluster. Le misurazioni vengono memorizzate con il canonico di una query come chiave. Il canonico di una query è l'SQL con tutte le costanti definite dall'utente sostituite da punti interrogativi, ad esempio:

UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ?

Questa è una funzione molto utile se si esegue MariaDB su una replica geografica multisito o un mix di motori di archiviazione MariaDB in una catena di replica, ad esempio uno slave dedicato per gestire i carichi di lavoro delle transazioni (OLTP ) con il motore di archiviazione InnoDB e un altro slave dedicato per gestire i carichi di lavoro di analisi (OLAP) con il motore di archiviazione Columnstore.

Supponiamo di avere due siti:Sydney e Singapore, come illustrato nel diagramma seguente:

Il sito principale si trova a Singapore e ha un master MariaDB e uno slave , mentre un altro slave di sola lettura si trova a Sydney. L'applicazione si connette all'istanza MaxScale situata nel rispettivo paese con le seguenti impostazioni di porta:

  • Divisione lettura-scrittura:3306
  • Round robin:3307
  • Router intelligente:3308

Il nostro servizio SmarRouter e le definizioni degli ascoltatori sono:

[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******
[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308

Riavvia MaxScale e inizia a inviare una query di sola lettura a entrambi i nodi MaxScale situati a Singapore e Sydney. Se la query viene elaborata dal router round-robin (porta 3307), vedremmo che la query viene instradata in base all'algoritmo round-robin:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Da quanto sopra, possiamo dire che MaxScale di Sydney ha inoltrato la query di cui sopra al nostro slave di Singapore, che di per sé non è la migliore opzione di routing.

Con SmartRouter in ascolto sulla porta 3308, vedremmo che la query viene instradata allo slave più vicino a Sydney:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname      |
+-----------+-----------------+
|   1000000 | mariadb_sydney1 |
+-----------+-----------------+

E se la stessa query viene eseguita nel nostro sito di Singapore, verrà indirizzata allo slave MariaDB situato a Singapore:

(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

C'è però un problema. Quando SmartRouter vede una query di lettura il cui canonico non è mai stato visto prima, invierà la query a tutti i cluster. La prima risposta da un cluster designerà quel cluster come il migliore per quel canonico. Inoltre, quando viene ricevuta la prima risposta, le altre query vengono annullate. La risposta viene inviata al client una volta che tutti i cluster hanno risposto alla query o all'annullamento.

Ciò significa che, per tenere traccia della query canonica (query normalizzata) e misurarne le prestazioni, probabilmente vedrai la prima query fallita nella sua prima esecuzione, ad esempio:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query

Dal log generale in MariaDB Sydney, possiamo dire che la prima query (ID 74) è stata eseguita correttamente (connessione, query e chiusura), nonostante l'errore "Connessione persa" di MaxScale:

  74 Connect  [email protected] as anonymous on 
  74 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  74 Quit

Mentre la query successiva identica è stata elaborata correttamente e restituita con la risposta corretta:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname             |
+-----------+------------------------+
|   1000000 | mariadb_sydney.cluster |
+-----------+------------------------+

Guardando di nuovo il log generale in MariaDB Sydney (ID 75), si sono verificati gli stessi eventi di elaborazione proprio come la prima query:

  75 Connect  [email protected] as anonymous on 
  75 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  75 Quit

Da questa osservazione, possiamo concludere che occasionalmente MaxScale deve fallire la prima query per misurare le prestazioni e diventare più intelligente per le successive identiche query. La tua applicazione deve essere in grado di gestire correttamente questo "primo errore" prima di tornare al cliente o riprovare la transazione ancora una volta.

Socket UNIX per server

Esistono diversi modi per connettersi a un server MySQL o MariaDB in esecuzione. È possibile utilizzare il TCP/IP di rete standard con indirizzo IP host e porta (connessione remota), named pipe/memoria condivisa su Windows o file socket Unix su sistemi basati su Unix. Il file socket UNIX è un tipo speciale di file che facilita le comunicazioni tra diversi processi, che in questo caso sono il client MySQL e il server. Il file socket è una comunicazione basata su file e non è possibile accedere al socket da un'altra macchina. Fornisce una connessione più veloce rispetto a TCP/IP (nessun sovraccarico di rete) e un approccio di connessione più sicuro perché può essere utilizzato solo quando ci si connette a un servizio o processo sullo stesso computer.

Supponendo che il server MaxScale sia installato anche sul server MariaDB stesso, possiamo invece utilizzare il file socket UNIX socket. Nella sezione Server, rimuovi o commenta la riga "address" e aggiungi il parametro socket con la posizione del file socket:

[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sock

Prima di applicare le modifiche di cui sopra, dobbiamo creare un utente MaxScale axscale da localhost. Sul server principale:

MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';

Dopo un riavvio, MaxScale mostrerà il percorso del socket UNIX invece dell'indirizzo effettivo e l'elenco dei server verrà mostrato in questo modo:

Come puoi vedere, le informazioni sullo stato e sul GTID vengono recuperate correttamente tramite una connessione socket. Si noti che questo DB_2 è ancora in ascolto sulla porta 3306 per le connessioni remote. Mostra solo che MaxScale utilizza un socket per connettersi a questo server per il monitoraggio.

L'uso di socket è sempre meglio perché consente solo connessioni locali ed è più sicuro. Puoi anche chiudere il tuo server MariaDB dalla rete (ad es. --skip-networking) e lasciare che MaxScale gestisca le connessioni "esterne" e le inoltri al server MariaDB tramite un file socket UNIX.

Scarico del server

In MaxScale 2.4, i server back-end possono essere svuotati, il che significa che le connessioni esistenti possono continuare a essere utilizzate, ma non verranno create nuove connessioni al server. Con la funzione di drenaggio, possiamo eseguire un'attività di manutenzione regolare senza influire sull'esperienza dell'utente dal lato dell'applicazione. Tieni presente che lo svuotamento di un server può richiedere più tempo, a seconda delle query in esecuzione che devono essere chiuse in modo corretto.

Per svuotare un server, usa il seguente comando:

L'effetto collaterale potrebbe essere uno dei seguenti stati:

  • Svuotamento:il server è in fase di svuotamento.
  • Svuotato:il server è stato svuotato. Il server è stato svuotato e ora il numero di connessioni al server è sceso a 0.
  • Manutenzione - Il server è in manutenzione.

Dopo che un server è stato svuotato, lo stato del server MariaDB dal punto di vista di MaxScale è "Manutenzione":

Quando un server è in modalità di manutenzione, non verranno create connessioni ad esso e le connessioni esistenti verranno chiuse.

Conclusione

MaxScale 2.4 apporta molti miglioramenti e modifiche rispetto alla versione precedente ed è il miglior proxy di database per gestire i server MariaDB e tutti i suoi componenti.