Πώς διαβάζετε την υγεία ενός Galera cluster σε πέντε μεταβλητές κατάστασης

Ένα Galera cluster (Percona XtraDB Cluster ή MariaDB Galera) μπορεί να φαίνεται απολύτως εντάξει από την εφαρμογή ενώ αθόρυβα τρέχει με δύο πόδια, φρενάρει τον εαυτό του, ή κρατά έναν κόμβο που θα χρειαστεί πλήρες αντίγραφο για να επανενταχθεί. Καθεμία από αυτές τις καταστάσεις φαίνεται σε μια χούφτα μεταβλητές κατάστασης. Έτσι τις διαβάζουμε, και τι σας λέει η καθεμία.

Το πρόβλημα: το «απαντά σε queries» δεν είναι έλεγχος υγείας

Το περισσότερο monitoring για μια βάση σε cluster ελέγχει το ίδιο πράγμα που έλεγχε για έναν μεμονωμένο server: είναι ανοιχτή η θύρα 3306, επιστρέφει το SELECT 1. Ένας κόμβος Galera που έχει πέσει έξω από το primary component εξακολουθεί να δέχεται συνδέσεις. Ένας κόμβος που είναι synced αλλά εφαρμόζει τις εγγραφές πολύ αργά εξακολουθεί να απαντά σε reads. Ένα cluster τριών που έχει γίνει αθόρυβα cluster δύο εξακολουθεί να σερβίρει το site, μέχρι τη στιγμή που φεύγει ο επόμενος κόμβος και το quorum χάνεται.

Το cluster τα ξέρει όλα αυτά για τον εαυτό του. Αρκεί να το ρωτήσετε.

Το ένα query που τρέχετε σε κάθε κόμβο

SHOW GLOBAL STATUS WHERE Variable_name IN (
  'wsrep_cluster_status',
  'wsrep_cluster_size',
  'wsrep_local_state_comment',
  'wsrep_ready',
  'wsrep_cluster_state_uuid',
  'wsrep_flow_control_paused',
  'wsrep_local_recv_queue_avg',
  'wsrep_local_send_queue_avg',
  'wsrep_local_cert_failures',
  'wsrep_local_bf_aborts'
);

Τρέξτε το σε κάθε μέλος, όχι μόνο σε αυτό που τυχαίνει να φτάνει ο load balancer σας. Αρκετές από αυτές τις τιμές είναι τοπικές στον κόμβο, και οι ενδιαφέρουσες αποτυχίες είναι εκείνες όπου οι κόμβοι διαφωνούν.

Συμμετοχή: είναι αυτός ο κόμβος πραγματικά μέλος του cluster;

Το wsrep_cluster_status πρέπει να είναι Primary. Οτιδήποτε άλλο (Non-Primary, Disconnected) σημαίνει ότι ο κόμβος έχασε την επαφή με την πλειοψηφία και θα αρνηθεί να σερβίρει συνεπή δεδομένα. Αν ο έλεγχος υγείας σας δεν κοιτά αυτή την τιμή, ένας απομονωμένος κόμβος μπορεί να συνεχίσει να δέχεται κίνηση.

Το wsrep_cluster_size πρέπει να ισούται με τον αριθμό των κόμβων που χτίσατε. Αυτή είναι η μεταβλητή που πιάνει το «τρέχει με δύο πόδια». Ένα cluster τριών κόμβων που αναφέρει δύο εξακολουθεί να σερβίρει, είναι ακόμη σε quorum, και δεν έχει καμία ανοχή απομένουσα. Βάλτε ειδοποίηση ως προειδοποίηση τη στιγμή που πέφτει κάτω από το μέγεθος σχεδιασμού, όχι όταν φτάσει στο ένα.

Το wsrep_local_state_comment πρέπει να γράφει Synced. Το Donor/Desynced σημαίνει ότι ο κόμβος τροφοδοτεί έναν joiner και μπορεί να είναι επιβραδυμένος. Τα Joining και Joined σημαίνουν ότι ακόμη προλαβαίνει. Ένας κόμβος σε οποιαδήποτε κατάσταση εκτός από Synced πρέπει να βγαίνει από το read pool από τον proxy σας μέχρι να επιστρέψει.

Το wsrep_cluster_state_uuid πρέπει να είναι ίδιο σε κάθε κόμβο. Δύο διαφορετικές τιμές σημαίνουν ότι έχετε δύο clusters που καθένα νομίζει ότι είναι το cluster. Αυτό συμβαίνει μόνο αφού κάποιος κάνει bootstrap τον λάθος κόμβο, οπότε αξίζει έλεγχο μετά από κάθε χειροκίνητη ανάκαμψη.

Το wsrep_ready απλώς επιβεβαιώνει ότι ο κόμβος θα δεχτεί queries. Αν γράφει OFF, οι άλλες τιμές θα σας πουν γιατί.

Επιδόσεις: κρατιέται το cluster πίσω μόνο του;

Το replication του Galera βασίζεται σε certification: κάθε κόμβος πρέπει να συμφωνήσει ότι ένα write set δεν συγκρούεται πριν γίνει commit. Αυτό κάνει το cluster τόσο γρήγορο όσο ο πιο αργός applier του, και το Galera το επιβάλλει με flow control.

Το wsrep_flow_control_paused είναι το ποσοστό του χρόνου, από το τελευταίο FLUSH STATUS, που το replication έμεινε σε παύση επειδή κάποιος κόμβος δεν προλάβαινε. Διαβάστε το ως ποσοστό. Κοντά στο μηδέν είναι υγιές. Οτιδήποτε επίμονα πάνω από λίγα τοις εκατό σημαίνει ότι οι εγγραφές περιμένουν έναν αργό κόμβο, και το latency εγγραφής της εφαρμογής σας το πληρώνει. Κάντε flush, περιμένετε ένα γνωστό διάστημα, διαβάστε ξανά, ώστε ο αριθμός να περιγράφει το παρόν και όχι τον περασμένο μήνα.

Το wsrep_local_recv_queue_avg σάς λέει ποιος κόμβος είναι αργός. Ένας κόμβος του οποίου ο μέσος όρος της ουράς λήψης κάθεται αρκετά πάνω από το μηδέν είναι αυτός που πυροδοτεί το flow control. Συνήθως η αιτία είναι τοπική: πιο αργό storage, ένας θορυβώδης γείτονας, μια μακριά αναφορά, ή πολύ λίγα applier threads (wsrep_applier_threads, ή wsrep_slave_threads σε παλαιότερες εκδόσεις).

Το wsrep_local_send_queue_avg που ανεβαίνει δείχνει προς την άλλη κατεύθυνση: αυτός ο κόμβος δυσκολεύεται να στείλει τα δικά του write sets, που συνήθως σημαίνει latency ή απώλειες δικτύου μεταξύ μελών. Είναι ο λόγος που τα μέλη του cluster ανήκουν στο ίδιο fabric χαμηλού latency, με τα αντίγραφα εκτός site να γίνονται με ασύγχρονα replicas.

Συγκρούσεις: γράφετε σε περισσότερους από έναν κόμβους;

Το wsrep_local_cert_failures και το wsrep_local_bf_aborts μετρούν συναλλαγές που έγιναν rollback επειδή ένας άλλος κόμβος έκανε πρώτος commit μια αντικρουόμενη αλλαγή. Η εφαρμογή τα βλέπει ως σφάλματα deadlock. Μια σταθερή ροή σε ένα cluster όπου κάθε κόμβος δέχεται εγγραφές είναι η υπογραφή της διαμάχης πολλαπλών writers, και τα plugins WordPress και e-commerce που ενημερώνουν τις ίδιες γραμμές option ή counter σε κάθε αίτημα την παράγουν σε όγκο.

Η λύση είναι αρχιτεκτονική, όχι ρύθμιση: στείλτε όλες τις εγγραφές σε έναν κόμβο και μοιράστε τα reads. Με ProxySQL είναι μία γραμμή:

INSERT INTO mysql_galera_hostgroups
  (writer_hostgroup, backup_writer_hostgroup, reader_hostgroup,
   offline_hostgroup, active, max_writers, writer_is_also_reader,
   max_transactions_behind)
VALUES (10, 20, 30, 40, 1, 1, 1, 100);
LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;

Το max_writers = 1 εκλέγει έναν writer, οι άλλοι γίνονται readers και backup writers, και το max_transactions_behind επιτρέπει στο ProxySQL να βγάζει αυτόματα από το read pool έναν κόμβο που μένει πίσω. Μόλις οι εγγραφές πάνε σε έναν κόμβο, αυτοί οι δύο μετρητές πρέπει να μένουν σχεδόν ακίνητοι.

Αν μετά οι συντάκτες παραπονεθούν ότι μια αποθήκευση «εξαφανίστηκε» στην ανανέωση, το read πήγε σε έναν κόμβο που δεν είχε εφαρμόσει ακόμη την εγγραφή. Η ρύθμιση του wsrep_sync_wait για αυτές τις συνεδρίες κάνει το read να περιμένει τον κόμβο να προλάβει, με μικρό κόστος σε latency.

Επανένταξη: θα επιστρέψει ένας κόμβος γρήγορα ή αργά;

Ένας κόμβος που φεύγει και επιστρέφει είτε λαμβάνει τα write sets που έχασε από την cache ενός donor (IST, σταδιακό και γρήγορο) είτε ένα πλήρες αντίγραφο του dataset (SST, αργό και βαρύ για τον donor). Ποιο από τα δύο θα πάρετε εξαρτάται από το αν η cache write sets του donor, το gcache.size στα wsrep_provider_options, κρατά ακόμη όλα όσα έχασε ο joiner.

Μπορείτε να τη διαστασιολογήσετε από τους ίδιους τους μετρητές του cluster. Διαβάστε wsrep_replicated_bytes και wsrep_received_bytes με διαφορά μιας ώρας. Το άθροισμα των διαφορών είναι περίπου ο όγκος write sets ανά ώρα. Πολλαπλασιάστε με το μεγαλύτερο παράθυρο συντήρησης που περιμένετε, προσθέστε περιθώριο, και αυτή είναι η gcache που χρειάζεστε. Ένας κόμβος μπορεί τότε να γίνει patch, να επανεκκινήσει, ή να κρατηθεί ώρες για εργασίες hardware και πάλι να επανενταχθεί σταδιακά.

Quorum: η αριθμητική πίσω από το «τρία»

Το quorum είναι αυστηρή πλειοψηφία. Τρία μέλη ανέχονται την απώλεια ενός. Τέσσερα μέλη ανέχονται επίσης μόνο ένα, γιατί δύο στα τέσσερα δεν είναι πλειοψηφία, οπότε ο τέταρτος κόμβος αγοράζει χωρητικότητα αλλά όχι ανθεκτικότητα. Δύο μέλη δεν ανέχονται τίποτα: αν χάσουν το ένα το άλλο, σταματούν και τα δύο. Αν πραγματικά έχετε μόνο δύο κόμβους δεδομένων, προσθέστε τον Galera arbitrator (garbd) σε έναν τρίτο, ανεξάρτητο host ώστε να υπάρχει ακόμη πλειοψηφία.

Η ίδια αριθμητική ισχύει για το πού ζουν τα μέλη. Τρεις κόμβοι σε έναν host, ή τρεις κόμβοι με τα δεδομένα τους σε μία συστοιχία storage, είναι ένα failure domain με τρία ονόματα. Στο Kubernetes, συνδυάστε αυστηρό pod anti-affinity με ένα PodDisruptionBudget minAvailable: 2, ώστε μια κυλιόμενη ενημέρωση κόμβων να μην μπορεί ποτέ να πάρει δύο μέλη μαζί.

Τι να ελέγξετε στο δικό σας cluster αυτή την εβδομάδα

• Κάθε κόμβος αναφέρει Primary, Synced, το ίδιο state UUID, και το μέγεθος cluster που σχεδιάσατε.
• Ο έλεγχος υγείας και ο proxy σας χρησιμοποιούν και οι δύο αυτές τις τιμές, όχι απλώς ένα TCP connect.
• Το wsrep_flow_control_paused, μετρημένο σε φρέσκο διάστημα, είναι κοντά στο μηδέν.
• Οι αποτυχίες certification δεν ανεβαίνουν. Αν ανεβαίνουν, οι εγγραφές πέφτουν σε περισσότερους από έναν κόμβους.
• Η gcache σας καλύπτει το μεγαλύτερο προγραμματισμένο παράθυρο συντήρησης.
• Κανένα ζεύγος μελών δεν μοιράζεται host, συστοιχία, ή (στο Kubernetes) διατάραξη χωρίς budget.

Ένα Galera cluster που διαβάζεται έτσι σπάνια εκπλήσσει κανέναν. Αν το δικό σας το κάνει, ευχαρίστως να ρίξουμε μια ματιά.

cta: Μιλήστε με έναν μηχανικό

Related

• /what-we-do/data-web/clustered-databases/
• /what-we-do/data-web/database-replication/
• /what-we-do/data-web/high-availability-platforms/