Στις αρχιτεκτονικές υψηλής διαθεσιμότητας MySQL, η αναπαραγωγή της κύριας βάσης δεδομένων είναι ένας πολύ κοινός τύπος.
Όταν η κύρια βάση δεδομένων πέσει, μπορείτε να αναβαθμίσετε μια εξαρτημένη βάση δεδομένων ως νέα κύρια βάση δεδομένων για να διασφαλίσετε τη διαθεσιμότητα της υπηρεσίας. Ταυτόχρονα, το QPS ολόκληρου του συμπλέγματος μπορεί να βελτιωθεί επεκτείνοντας τη βιβλιοθήκη slave.
Σύμφωνα με την αρχιτεκτονική αναπαραγωγής master-slave, η MySQL χρησιμοποιεί binlog για να επιτύχει συνέπεια δεδομένων master-slave.
Όπως φαίνεται στο παραπάνω σχήμα, η αναπαραγωγή master-slave MySQL έχει κυρίως τα ακόλουθα βήματα
1. Ο κύριος καταγράφει τις αλλαγές στο δυαδικό αρχείο καταγραφής
2. Το slave io_thread ζητήσει το binlog της κύριας βιβλιοθήκης και να γράψει το αρχείο καταγραφής binlog που προκύπτει στο αρχείο καταγραφής αναμετάδοσης
3. Slave sql_thread επανάληψη συμβάντων στο αρχείο καταγραφής αναμετάδοσης
Εκτός από το ότι είναι ένας σύνδεσμος για την αναπαραγωγή master-slave MySQL, το binlog εξυπηρετεί και άλλους σκοπούς. Σαν τι:
1. Χρησιμοποιήστε το εργαλείο mysqlbinlog για να αναλύσετε το αρχείο binlog για να εκτελέσετε ανάκτηση βάσης δεδομένων σε χρονικό σημείο.
2. Αναδρομή της βάσης δεδομένων με βάση συμβάντα binlog (το MariaDB μπορεί να χρησιμοποιήσει απευθείας το mysqlbinlog για αναδρομή)
3. Το διαδικτυακό εργαλείο αλλαγής πίνακα ανοιχτού κώδικα του Github gh-ost υλοποιείται επίσης μέσω του binlog
4. Μπορείτε επίσης να εγγραφείτε και να καταναλώσετε σταδιακά αναλύοντας binlogs
Το Binlog είναι τόσο χρήσιμο, αλλά είναι αναπόφευκτο να αντιμετωπίσετε κάποια προβλήματα στην καθημερινή διαδικασία λειτουργίας και συντήρησης. Ακολουθούν ορισμένα σφάλματα που σχετίζονται με το binlog.
Μία από τις συχνές ερωτήσεις
φαινόμενο
Εμφανίζεται το Mysqlbinlog5.5 αναλύει το αρχείο binlog Mysql5.7
ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35ERROR: Could not read entry at offset 123: Error in log format or read error.
Ανάλυση αιτίας
Η MySQL 5.6 και άλλες υψηλότερες εκδόσεις αρχείων binlog έχουν προσθέσει νέα συμβάντα binlog, όπως συμβάντα GTID.
Το MySQLBINLOG στο MySQL5.5 δεν αναγνωρίζει τέτοια συμβάντα binlog.
Λύση
Χρησιμοποιήστε την υψηλότερη έκδοση του mysqlbinlog για να επιλύσετε το binlog που δημιουργείται από την χαμηλότερη έκδοση του mysql
Συχνή ερώτηση δεύτερη
φαινόμενο
Εμφανίζεται ένας υγιής διακομιστής mysql που δείχνει την κατάσταση slave
Last_SQL_Error:Αποτυχία ανάγνωσης αρχείου καταγραφής αναμετάδοσης: Δεν ήταν δυνατή η ανάλυση της καταχώρησης συμβάντος αρχείου καταγραφής αναμετάδοσης.
Οι πιθανοί λόγοι είναι: το δυαδικό αρχείο καταγραφής του master είναι κατεστραμμένο (μπορείτε να το ελέγξετε εκτελώντας το 'mysqlbinlog' στο δυαδικό αρχείο καταγραφής),
το αρχείο καταγραφής αναμετάδοσης του slave είναι κατεστραμμένο (μπορείτε να το ελέγξετε εκτελώντας το 'mysqlbinlog' στο αρχείο καταγραφής αναμετάδοσης),
ένα πρόβλημα δικτύου ή ένα σφάλμα στον κώδικα MySQL του master ή του slave.
Εάν θέλετε να ελέγξετε το δυαδικό αρχείο καταγραφής του κύριου ή το αρχείο καταγραφής αναμετάδοσης του slave,
θα μπορείτε να γνωρίζετε τα ονόματά τους εκδίδοντας «ΕΜΦΑΝΙΣΗ ΚΑΤΑΣΤΑΣΗΣ ΣΔΟΥΛΟΥ» σε αυτόν τον σκλάβο.
Ανάλυση αιτίας
Δεν είναι δυνατή η ανάγνωση των καταχωρήσεων στο αρχείο καταγραφής αναμετάδοσης λόγω σφαλμάτων binlog στην κύρια βιβλιοθήκη, σφαλμάτων αρχείου καταγραφής αναμετάδοσης στη βιβλιοθήκη slave ή προβλημάτων και σφαλμάτων δικτύου. Συνήθως προκαλείται από αποτυχία δικτύου ή υπερβολική πίεση στη βιβλιοθήκη slave, με αποτέλεσμα λανθασμένη μορφή καταγραφής αναμετάδοσης.
Λύση
Μετά την εύρεση του τρέχοντος χρονικού σημείου συγχρονισμού και την επαναφορά του συγχρονισμού master-slave, θα δημιουργηθεί ένα νέο αρχείο καταγραφής αναμετάδοσης και θα αποκατασταθεί ο συγχρονισμός master-slave.
Από την έξοδο του "show slave status\G", βρείτε τις ακόλουθες πληροφορίες:
Relay_Master_Log_File: mysql-bin.002540 // Η binlogExec_Master_Log_Pos του master που διαβάστηκε από τη βιβλιοθήκη slave: 950583017 // Το σημείο θέσης θέσης που έχει εκτελεστεί στο slave
Σταματήστε το slave και ρυθμίστε ξανά τον συγχρονισμό ξεκινώντας από το αρχείο binlog που έχει διαβάσει το slave και τη θέση που έχει εκτελεστεί.
Relay_Master_Log_File: mysql-bin.002540 // Η binlogExec_Master_Log_Pos του master που διαβάστηκε από τη βιβλιοθήκη slave: 950583017 // Το σημείο θέσης θέσης που έχει εκτελεστεί στο slave
Συχνή ερώτηση τρίτη
φαινόμενο
Επαναφορά εμφάνισης κατάστασης slave μετά από σφάλμα διακοπής λειτουργίας:
Last_SQL_Error: Σφάλμα κατά την προετοιμασία της θέσης του αρχείου καταγραφής ρελέ: Σφάλμα εισόδου/εξόδου κατά την ανάγνωση της κεφαλίδας από το δυαδικό αρχείο καταγραφής
Last_SQL_Error: Σφάλμα κατά την προετοιμασία της θέσης καταγραφής ρελέ: Το Binlog έχει κακό μαγικό αριθμό. Δεν είναι ένα δυαδικό αρχείο καταγραφής που μπορεί να χρησιμοποιηθεί από αυτήν την έκδοση της MySQL
Ανάλυση αιτίας
Διακοπές λειτουργίας, όπως διακοπή ρεύματος, καύση μητρικής πλακέτας κ.λπ., ή παράνομος τερματισμός λειτουργίας, με αποτέλεσμα την καταστροφή του αρχείου του κάδου αναμετάδοσης
Λύση
Ίδια ερώτηση δεύτερη.
relay_log_recovery = 1 μπορεί επίσης να οριστεί.
Όταν το slave πέσει από τη βιβλιοθήκη, εάν το αρχείο καταγραφής αναμετάδοσης είναι κατεστραμμένο και μέρος του αρχείου καταγραφής αναμετάδοσης δεν υποβληθεί σε επεξεργασία, το αρχείο καταγραφής αναμετάδοσης εγκαταλείπεται αυτόματα και το αρχείο καταγραφής ανακτάται ξανά από το κύριο, ολοκληρώνοντας την ανάκτηση του αρχείου καταγραφής αναμετάδοσης.
Συχνή ερώτηση τέταρτη
φαινόμενο
Εμφανίζεται όταν αλλάζετε το κύριο σε μετά από μια επανεκκίνηση από τον υπολογιστή της βιβλιοθήκης
Σφάλμα (Κωδικός 1201): Δεν ήταν δυνατή η προετοιμασία της κύριας δομής πληροφοριών. περισσότερα μηνύματα σφάλματος μπορούν να βρεθούν στο αρχείο καταγραφής σφαλμάτων MySQL
ή
ΣΦΑΛΜΑ 1872 (HY000): Το Slave απέτυχε να προετοιμάσει τη δομή πληροφοριών καταγραφής αναμετάδοσης από το χώρο αποθήκευσης
Ανάλυση αιτίας
Διακοπές λειτουργίας, όπως διακοπή ρεύματος, καύση μητρικής πλακέτας κ.λπ., ή παράνομος τερματισμός λειτουργίας, προκαλώντας ζημιά σε αρχεία master.info ή realy-log.info
Λύση
σκλάβος> επαναφέρετε τον σκλάβο όλα, αλλάξτε τον κύριο σε
Προληπτικά μέτρα
Ρυθμίσεις προφίλ
relay_log_info_repository=πίνακας
master_info_repository=πίνακας
Η μηχανή αποθήκευσης των MySQL 5.6.5 mysql.slave_master_info και mysql.slave_relay_log_info έχει οριστεί σε MyISAM από προεπιλογή και πρέπει να την αλλάξετε στη μηχανή αποθήκευσης του InnoDB
ΑΛΛΑΓΗ ΠΙΝΑΚΑ mysql.slave_master_info ΚΙΝΗΤΗΡΑ=InnoDB;
ΑΛΛΑΓΗ ΠΙΝΑΚΑ mysql.slave_relay_log_info ΚΙΝΗΤΗΡΑ=InnoDB;
mysql.slave_master_info πίνακας θα ενημερώνεται μετά από sync_master_info συμβάντα.
mysql.slave_relay_log_info πίνακας θα ενημερώνεται με κάθε υποβολή συναλλαγής.
Συχνές ερωτήσεις 5
φαινόμενο
Το κύριο slave binlog_format αρχικά μια δήλωση, μετά την αλλαγή της κύριας βάσης δεδομένων binlog_format σε σειρά, εμφανίζεται η κατάσταση slave από τη βιβλιοθήκη:
Last_Error: Σφάλμα κατά την εκτέλεση συμβάντος σειράς: «Δεν είναι δυνατή η εκτέλεση δήλωσης: αδύνατη η εγγραφή σε δυαδικό αρχείο καταγραφής, καθώς η δήλωση είναι σε μορφή σειράς και BINLOG_FORMAT = STATEMENT».
Ανάλυση αιτίας
Όταν η κύρια βάση δεδομένων binlog_format είναι σειρά και η υποτελής βιβλιοθήκη binlog_format είναι δήλωση, θα εμφανιστεί το παραπάνω σφάλμα.
Αλλά η κύρια βιβλιοθήκη binlog_format είναι η δήλωση, και η βιβλιοθήκη σκλάβων binlog_format σειρά.
Εναλλακτικά, εάν η κύρια βάση δεδομένων binlog_format είναι η σειρά, το σφάλμα δεν θα αναφερθεί εάν η binlog_format της βάσης δεδομένων είναι μικτή.
Εάν το νήμα SQL σας έχει πράγματι ρυθμιστεί με
binlog_format=STATEMENT μόλις λάβει ένα συμβάν ROW θα σταματήσει. Η
Ο λόγος είναι ότι δεν θα ήταν σε θέση να καταγράψει αυτό το συμβάν ROW σε μορφή STATEMENT (μερικές φορές αναφερόμαστε σε αυτό ως ένεση ROW, το οποίο είναι είτε ένα
BINLOG ή ένα συμβάν ROW που εκτελείται από το νήμα SQL του slave)
Λεπτομερής αναφορά λόγου:https://bugs.mysql.com/bug.php?id=69095
Λύση
SLAVE> STOP SLAVE;
SLAVE> ΣΎΝΟΛΟ GLOBAL binlog_format=ΜΙΚΤΌ;
SLAVE> ΈΝΑΡΞΗ SLAVE;
Συχνή ερώτηση αριθμός 6
φαινόμενο
Σφάλμα κατά το συγχρονισμό mysql5.6 με mysql5.5
Last_IO_Error: Έλαβε μοιραίο σφάλμα 1236 από τον κύριο κατά την ανάγνωση δεδομένων από δυαδικό αρχείο καταγραφής: «Το Slave δεν μπορεί να χειριστεί συμβάντα αναπαραγωγής με το άθροισμα ελέγχου που έχει ρυθμιστεί να καταγράφει ο κύριος. Το πρώτο συμβάν «mysql-bin.000001» στο 4, το τελευταίο συμβάν που διαβάζεται από το «mysql-bin.000001» στο 120, το τελευταίο byte που διαβάζεται από το «mysql-bin.000001» στο 120».
Ανάλυση αιτίας
Προκειμένου να λυθεί το πρόβλημα ότι οι δηλώσεις SQL που εκτελούνται στον πρωτεύοντα διακομιστή δεν συνάδουν με τις δηλώσεις SQL που εκτελούνται στον διακομιστή (που ονομάζονται κατεστραμμένα συμβάντα) λόγω σφαλμάτων λογισμικού και υλικού ή μετάδοσης δικτύου, η MySQL 5.6 προσθέτει τη συνάρτηση Replication Event Checksum. Όταν ένα συμβάν εγγράφεται στο δυαδικό αρχείο καταγραφής, το άθροισμα ελέγχου εγγράφεται επίσης στο δυαδικό αρχείο καταγραφής και, στη συνέχεια, αφού το συμβάν μεταδοθεί στο slave μέσω του δικτύου, επαληθεύεται στο slave και εγγράφεται στο αρχείο καταγραφής αναμετάδοσης του slave. Δεδομένου ότι τα συμβάντα και τα αθροίσματα ελέγχου καταγράφονται σε κάθε βήμα, μπορούμε γρήγορα να καταλάβουμε ποιο είναι το πρόβλημα.
Στη mysql5.6.5 και σε νεότερες εκδόσεις binlog_checksum η προεπιλεγμένη τιμή είναι crc32,
Η προεπιλεγμένη τιμή binlog_checksum προηγούμενης έκδοσης ήταν καμία
λύση
Slave> ορίστε καθολικό binlog_checksum=κανένα
Συχνές ερωτήσεις 7
φαινόμενο
Αφού γεμίσει ο δίσκος, καθαρίστε με μη αυτόματο τρόπο το αρχείο binlog και το αρχείο mysql-bin.index
Εμφάνιση Τα δυαδικά αρχεία καταγραφής είναι κενά, αλλά η Εμφάνιση κατάστασης προτύπου είναι κανονική.
mysql> εμφάνιση δυαδικών αρχείων καταγραφής. Κενό σύνολο (0,00 δευτ.) mysql> εμφάνιση κύριας κατάστασης.
+------------------+-----------+--------------+------------------+
| Αρχείο | Θέση | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Ανάλυση αιτίας
Αφού έλεγξα το αρχείο mysql-bin.index, βρήκα την πρώτη κενή γραμμή.
Στον πηγαίο κώδικα της mysql rpl_master.cc:show_binlogs() θα βρείτε τον ακόλουθο κώδικα:
/* The file ends with EOF or empty line */
ενώ ((μήκος=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Οι κενές γραμμές θεωρούνται το τέλος του εγγράφου
(Αναφορά.)https://yq.aliyun.com/articles/213657Άρθρο)
Προληπτικά μέτρα
Μην διαγράφετε χειροκίνητα το binlog, μην επεξεργάζεστε χειροκίνητα το αρχείο mysql-bin.index, εκτός αν ξέρετε τι κάνετε, διαφορετικά μπορεί να βάζετε νάρκες για τον εαυτό σας!
περίληψη
Οι DBA πρέπει να δώσουν προσοχή στις βελτιώσεις στο binlog σε κάθε νέα έκδοση της MySQL (όπως η δυνατότητα gtid που προστέθηκε στην έκδοση 5.6, Enhanced Multi-threaded Slaves στην έκδοση 5.7) και να κατανοήσουν λεπτομερώς τη σημασία κάθε παραμέτρου, ώστε να μπορούν να γνωρίζουν τι σημαίνουν όταν αντιμετωπίζουν σφάλματα και να λύνουν εύκολα προβλήματα.
|
Δημοσιεύτηκε στις 25/9/2018 10:31:40 π.μ.
|
|
|
|
