Οποιοδήποτε μεγάλο έργο ξεκίνησε με μερικούς διακομιστές. Στην αρχή υπήρχε ένας διακομιστής DB, στη συνέχεια προστέθηκαν σκλάβοι σε αυτόν για να κλιμακώσουν την ανάγνωση. Και μετά - σταματήστε! Υπάρχει ένας κύριος, αλλά υπάρχουν πολλοί σκλάβοι. αν φύγει ένας από τους σκλάβους, τότε όλα θα πάνε καλά, αλλά αν φύγει ο κύριος, θα είναι κακό: διακοπές λειτουργίας, οι διαχειριστές προσπαθούν να ανεβάσουν τον διακομιστή. Τι να κάνω? Κρατήστε έναν κύριο. Ο συνάδελφός μου Pavel έγραψε ήδη για αυτό , δεν θα το επαναλάβω. Αντίθετα, θα σας πω γιατί χρειάζεστε οπωσδήποτε το Orchestrator για MySQL!
Ας ξεκινήσουμε με την κύρια ερώτηση: "Πώς θα αλλάξουμε τον κωδικό σε ένα νέο μηχάνημα όταν φύγει ο κύριος;"
- Μου αρέσει περισσότερο το σχήμα με το VIP (Virtual IP), θα μιλήσουμε για αυτό παρακάτω. Είναι το πιο απλό και προφανές, αν και έχει έναν προφανή περιορισμό: ο κύριος που θα κρατήσουμε πρέπει να είναι στο τμήμα L2 με το νέο μηχάνημα, δηλαδή μπορούμε να ξεχάσουμε το δεύτερο DC. Και, με φιλικό τρόπο, αν ακολουθήσετε τον κανόνα ότι ένα μεγάλο L2 είναι κακό, επειδή το L2 είναι μόνο ανά rack, και το L3 είναι ανάμεσα στα rack, και ένα τέτοιο σχήμα έχει ακόμη περισσότερους περιορισμούς.
- Μπορείτε να γράψετε ένα όνομα DNS στον κώδικα και να το επιλύσετε μέσω του /etc/hosts. Στην πραγματικότητα, δεν θα υπάρξει λύση. Το πλεονέκτημα του σχήματος: δεν υπάρχει περιοριστικό χαρακτηριστικό της πρώτης μεθόδου, δηλαδή, είναι δυνατό να οργανωθεί ένα cross-DC. Αλλά τότε τίθεται το προφανές ερώτημα: πόσο γρήγορα μπορούμε να παραδώσουμε την αλλαγή στο /etc/hosts μέσω Puppet-Ansible;
- Μπορείτε να αλλάξετε λίγο τη δεύτερη μέθοδο: εγκατάσταση προσωρινής αποθήκευσης DNS σε όλους τους διακομιστές ιστού, μέσω των οποίων ο κώδικας θα μεταβεί στην κύρια βάση δεδομένων. Μπορείτε να ορίσετε το TTL 60 για αυτήν την καταχώρηση στο DNS. Φαίνεται ότι αν εφαρμοστεί σωστά, η μέθοδος είναι καλή.
- Ένα σχήμα με ανακάλυψη υπηρεσίας, που συνεπάγεται τη χρήση του Consul και κ.λπ.
- Μια ενδιαφέρουσα επιλογή με . Πρέπει να δρομολογήσετε όλη την επισκεψιμότητα στη MySQL μέσω του ProxySQL· ο ίδιος ο ProxySQL μπορεί να καθορίσει ποιος είναι ο κύριος. Παρεμπιπτόντως, μπορείτε να διαβάσετε για μία από τις επιλογές χρήσης αυτού του προϊόντος στο δικό μου .
Ο συγγραφέας του Orchestrator, που εργαζόταν στο Github, υλοποίησε πρώτα το πρώτο σχήμα με VIP και στη συνέχεια το μετέτρεψε σε σχήμα με πρόξενο.
Τυπική διάταξη υποδομής:
Θα περιγράψω αμέσως τις προφανείς καταστάσεις που πρέπει να ληφθούν υπόψη:
- Η διεύθυνση VIP δεν πρέπει να καταχωρηθεί στη διαμόρφωση σε κανέναν από τους διακομιστές. Ας φανταστούμε μια κατάσταση: ο κύριος έκανε επανεκκίνηση και ενώ φορτωνόταν, ο Orchestrator μπήκε σε λειτουργία failover και έκανε έναν από τους σκλάβους κύριο. τότε ο παλιός κύριος σηκώθηκε, και τώρα το VIP είναι σε δύο αυτοκίνητα. Αυτό είναι κακό.
- Για τον ενορχηστρωτή, θα χρειαστεί να γράψετε ένα σενάριο για να καλέσετε τον παλιό κύριο και τον νέο κύριο. Στο παλιό master πρέπει να εκτελέσετε το ifdown και στο νέο master – ifup vip. Θα ήταν ωραίο να συμπεριλάβετε επίσης σε αυτό το σενάριο ότι σε περίπτωση failover, η θύρα στον παλιό διακόπτη master απλά απενεργοποιείται για να αποφευχθεί τυχόν splitbrain.
- Αφού ο ενορχηστρωτής καλέσει το σενάριό σας για να αφαιρέσει πρώτα το VIP ή/και να σβήσει τη θύρα στο διακόπτη και μετά να καλέσει το σενάριο αύξησης VIP στον νέο κύριο, μην ξεχάσετε να χρησιμοποιήσετε την εντολή arping για να πείτε σε όλους ότι το νέο VIP είναι τώρα εδώ.
- Όλοι οι slave θα πρέπει να έχουν read_only=1, και μόλις προωθήσετε τον slave στον master, θα πρέπει να έχει read_only=0.
- Μην ξεχνάτε ότι οποιοσδήποτε σκλάβος έχουμε επιλέξει για αυτό μπορεί να γίνει κύριος (Ο ενορχηστρωτής έχει έναν ολόκληρο μηχανισμό προτίμησης για το ποιον σκλάβο πρέπει να θεωρεί υποψήφιο για νέο κύριο στην πρώτη θέση, ποιος στη δεύτερη θέση και ποιος σκλάβος πρέπει να μην επιλεγεί καθόλου σε καμία περίπτωση κύριος). Εάν ο σκλάβος γίνει κύριος, τότε το φορτίο του δούλου θα παραμείνει πάνω του και το φορτίο του κυρίου θα προστεθεί, αυτό πρέπει να ληφθεί υπόψη.
Γιατί χρειάζεστε ενορχηστρωτή αν δεν έχετε;
- Το Orchestrator έχει μια πολύ φιλική προς το χρήστη γραφική διεπαφή που εμφανίζει ολόκληρη την τοπολογία (δείτε στιγμιότυπο οθόνης παρακάτω).
- Ο ενορχηστρωτής μπορεί να παρακολουθεί ποιοι σκλάβοι υστερούν και πού γενικά έχει καταρρεύσει η αναπαραγωγή (έχουμε συνδεδεμένα σενάρια στο Orchestrator για την αποστολή SMS).
- Ο ενορχηστρωτής σας λέει ποιοι σκλάβοι έχουν σφάλμα GTID.
Διεπαφή ενορχηστρωτή:
Τι είναι το GTID errant;
Υπάρχουν δύο βασικές προϋποθέσεις για να εργαστεί ο ενορχηστρωτής:
- Είναι απαραίτητο το ψευδο GTID να είναι ενεργοποιημένο σε όλα τα μηχανήματα στο σύμπλεγμα MySQL· έχουμε ενεργοποιημένο το GTID.
- Είναι απαραίτητο να υπάρχει ένας τύπος binlogs παντού, μπορείτε να χρησιμοποιήσετε δήλωση. Είχαμε μια διαμόρφωση στην οποία ο κύριος και οι περισσότεροι σκλάβοι είχαν Row και δύο παρέμειναν ιστορικά στη Μικτή λειτουργία. Ως αποτέλεσμα, ο Orchestrator απλά δεν ήθελε να συνδέσει αυτούς τους σκλάβους με τον νέο κύριο.
Θυμηθείτε ότι το πιο σημαντικό πράγμα σε έναν σκλάβο παραγωγής είναι η συνέπεια του με τον κύριο! Εάν έχετε ενεργοποιημένο το Global Transaction ID (GTID) τόσο στο master όσο και στο slave, τότε μπορείτε να χρησιμοποιήσετε τη συνάρτηση gtid_subset για να μάθετε εάν τα ίδια αιτήματα για αλλαγές δεδομένων έχουν όντως εκτελεστεί σε αυτά τα μηχανήματα. Μπορείτε να διαβάσετε περισσότερα για αυτό .
Έτσι, ο Orchestrator σάς δείχνει μέσω του σφάλματος GTID ότι υπάρχουν συναλλαγές στο slave που δεν είναι στον master. Γιατί συμβαίνει αυτό?
- Το Read_only=1 δεν είναι ενεργοποιημένο στο slave, κάποιος συνδέθηκε και ολοκλήρωσε ένα αίτημα για αλλαγή δεδομένων.
- Το Super_read_only=1 δεν είναι ενεργοποιημένο στο slave, τότε ο διαχειριστής, έχοντας μπερδέψει τον διακομιστή, μπήκε και εκτέλεσε το αίτημα εκεί.
- Εάν λάβατε υπόψη και τα δύο προηγούμενα σημεία, τότε υπάρχει ένα ακόμη τέχνασμα: στη MySQL, ένα αίτημα για flush binlog πηγαίνει επίσης στο binlog, επομένως κατά την πρώτη έκπλυση, θα εμφανιστεί ένα σφάλμα GTID στον κύριο και σε όλους τους slaves. Πώς να το αποφύγετε αυτό; Το Perona-5.7.25-28 εισήγαγε τη ρύθμιση binlog_skip_flush_commands=1, η οποία απαγορεύει την εγγραφή flush σε binlog. Υπάρχει ένα καθιερωμένο στον ιστότοπο mysql.com .
Επιτρέψτε μου να συνοψίσω όλα τα παραπάνω. Εάν δεν θέλετε ακόμα να χρησιμοποιήσετε το Orchestrator σε λειτουργία failover, τότε βάλτε το σε λειτουργία παρατήρησης. Τότε θα έχετε πάντα μπροστά στα μάτια σας έναν χάρτη της αλληλεπίδρασης των μηχανών MySQL και οπτικές πληροφορίες σχετικά με το είδος της αναπαραγωγής σε κάθε μηχανή, εάν οι σκλάβοι υστερούν και το πιο σημαντικό, πόσο συνεπείς είναι με τον κύριο!
Το προφανές ερώτημα είναι: «Πώς πρέπει να λειτουργεί ο ενορχηστρωτής;» Πρέπει να επιλέξει ένα νέο κύριο από τα τρέχοντα slaves και, στη συνέχεια, να επανασυνδέσει όλους τους slaves σε αυτό (για αυτό χρειάζεται το GTID. Εάν χρησιμοποιείτε τον παλιό μηχανισμό με binlog_name και binlog_pos, τότε αλλάζετε έναν slave από τον τρέχοντα master σε έναν νέο είναι απλά αδύνατο!). Πριν είχαμε τον ενορχηστρωτή, κάποτε έπρεπε να τα κάνω όλα αυτά χειροκίνητα. Ο παλιός κύριος κρεμόταν λόγω ενός ελεγκτή με λάθη Adaptec· είχε περίπου 10 σκλάβους. Χρειαζόμουν να μεταφέρω το VIP από τον κύριο σε έναν από τους σκλάβους και να επανασυνδέσω όλους τους άλλους σκλάβους σε αυτό. Πόσες κονσόλες έπρεπε να ανοίξω, πόσες ταυτόχρονες εντολές έβαλα... Έπρεπε να περιμένω μέχρι τις 3 π.μ., να αφαιρέσω το φορτίο από όλα τα slaves εκτός από δύο, να φτιάξω το πρώτο μηχάνημα από δύο master, να συνδέσω αμέσως το δεύτερο μηχάνημα σε αυτό, οπότε συνδέστε όλους τους άλλους σκλάβους στο νέο κύριο και επιστρέψτε το φορτίο. Συνολικά, τρομερό...
Πώς λειτουργεί το Orchestrator όταν μπαίνει σε λειτουργία failover; Αυτό φαίνεται πιο εύκολα από ένα παράδειγμα μιας κατάστασης όπου θέλουμε να κάνουμε έναν πλοίαρχο μια πιο ισχυρή, πιο σύγχρονη μηχανή από ό,τι έχουμε τώρα.
Το σχήμα δείχνει τη μέση της διαδικασίας. Τι έχει ήδη γίνει μέχρι αυτό το σημείο; Είπαμε ότι θέλαμε να κάνουμε κάποιον σκλάβο τον νέο κύριο, ο ενορχηστρωτής άρχισε απλώς να επανασυνδέει όλους τους άλλους σκλάβους σε αυτό, με τον νέο κύριο να ενεργεί ως μηχανή διέλευσης. Με αυτό το σχήμα, δεν συμβαίνουν σφάλματα, όλοι οι σκλάβοι δουλεύουν, ο ενορχηστρωτής αφαιρεί το VIP από τον παλιό κύριο, το μεταφέρει στο νέο, κάνει read_only=0 και ξεχνά τον παλιό κύριο. Ολα! Ο χρόνος διακοπής της υπηρεσίας μας είναι ο χρόνος μεταφοράς VIP, ο οποίος είναι 2-3 δευτερόλεπτα.
Αυτό είναι όλο για σήμερα, σας ευχαριστώ όλους. Σύντομα θα υπάρξει δεύτερο άρθρο για τον ενορχηστρωτή. Στη διάσημη σοβιετική ταινία "Garage", ένας χαρακτήρας είπε: "Δεν θα πήγαινα σε αναγνώριση μαζί του!" Λοιπόν, ενορχηστρωτή, θα πήγαινα μαζί σου για αναγνώριση!
Πηγή: www.habr.com