🥇Ενημέρωση MySQL (Percona Server) από 5.7 σε 8.0

Η πρόοδος δεν σταματά, επομένως οι λόγοι για την αναβάθμιση στις πιο πρόσφατες εκδόσεις της MySQL γίνονται όλο και πιο επιτακτικοί. Πριν από λίγο καιρό, σε ένα από τα έργα μας, ήρθε η ώρα να ενημερώσουμε τα άνετα συμπλέγματα Percona Server 5.7 στην έκδοση 8. Όλα αυτά συνέβησαν στην πλατφόρμα Ubuntu Linux 16.04. Πώς να εκτελέσετε μια τέτοια λειτουργία με ελάχιστο χρόνο διακοπής λειτουργίας και ποια προβλήματα αντιμετωπίσαμε κατά την ενημέρωση - διαβάστε σε αυτό το άρθρο.

Εκπαίδευση

Οποιαδήποτε ενημέρωση του διακομιστή βάσης δεδομένων σχετίζεται πιθανότατα με αναδιαμόρφωση βάσης δεδομένων: αλλαγές στις απαιτήσεις για όρια στους πόρους του συστήματος και διόρθωση των ρυθμίσεων της βάσης δεδομένων που πρέπει να απαλειφθούν από παρωχημένες οδηγίες.

Πριν από την ενημέρωση, θα αναφερθούμε οπωσδήποτε στην επίσημη τεκμηρίωση:

Και ας καταρτίσουμε ένα σχέδιο δράσης:

Διορθώστε τα αρχεία ρυθμίσεων αφαιρώντας απαρχαιωμένες οδηγίες.
Ελέγξτε τη συμβατότητα με βοηθητικά προγράμματα.
Ενημερώστε τις βοηθητικές βάσεις δεδομένων εγκαθιστώντας το πακέτο percona-server-server.
Ενημερώστε το master με το ίδιο πακέτο.

Ας δούμε κάθε σημείο του σχεδίου και ας δούμε τι μπορεί να πάει στραβά.

ΣΗΜΑΝΤΙΚΟ! Η διαδικασία για την ενημέρωση ενός συμπλέγματος MySQL που βασίζεται στο Galera έχει τις δικές της λεπτές λεπτομέρειες που δεν περιγράφονται στο άρθρο. Δεν πρέπει να χρησιμοποιήσετε αυτήν την οδηγία σε αυτήν την περίπτωση.

Μέρος 1: Έλεγχος παραμέτρων

Η MySQL καταργήθηκε στην έκδοση 8 query_cache. Στην πραγματικότητα ήταν κηρύχθηκε απαρχαιωμένο πίσω στην έκδοση 5.7, αλλά τώρα έχει διαγραφεί πλήρως. Ως εκ τούτου, είναι απαραίτητο να καταργηθούν οι σχετικές οδηγίες. Και για αιτήματα προσωρινής αποθήκευσης, μπορείτε πλέον να χρησιμοποιείτε εξωτερικά εργαλεία - για παράδειγμα, ProxySQL.

Επίσης στο config υπήρχαν ξεπερασμένες οδηγίες σχετικά με innodb_file_format. Εάν στο MySQL 5.7 ήταν δυνατή η επιλογή της μορφής InnoDB, τότε η 8η έκδοση λειτουργεί ήδη μόνο με μορφή Barracuda.

Το αποτέλεσμά μας είναι η κατάργηση των παρακάτω οδηγιών:

query_cache_type, query_cache_limit и query_cache_size;
innodb_file_format и innodb_file_format_max.

Για έλεγχο, θα χρησιμοποιήσουμε την εικόνα Docker του διακομιστή Percona. Θα τοποθετήσουμε τη διαμόρφωση διακομιστή στον κατάλογο mysql_config_test, και δίπλα θα δημιουργήσουμε καταλόγους για δεδομένα και αρχεία καταγραφής. Παράδειγμα δοκιμής διαμόρφωσης διακομιστή Percona:

mkdir -p {mysql_config_test,mysql_data,mysql_logs}
cp -r /etc/mysql/conf.d/* mysql_config_test/
docker run  --name some-percona -v $(pwd)/mysql_config_test:/etc/my.cnf.d/  -v $(pwd)/mysql_data/:/var/lib/mysql/ -v $(pwd)/mysql_logs/:/var/log/mysql/ -e MYSQL_ROOT_PASSWORD=${MYSQL_PASSWORD} -d percona:8-centos

Κατώτατη γραμμή: είτε στα αρχεία καταγραφής του Docker είτε στον κατάλογο με τα αρχεία καταγραφής - ανάλογα με τις ρυθμίσεις σας - θα εμφανιστεί ένα αρχείο στο οποίο θα περιγράφονται οι προβληματικές οδηγίες.

Να τι είχαμε:

2020-04-03T12:44:19.670831Z 0 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2020-04-03T12:44:19.671678Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
2020-04-03T12:44:19.671682Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead.

Επομένως, χρειαζόμασταν ακόμη να καταλάβουμε τις κωδικοποιήσεις και να αντικαταστήσουμε την απαρχαιωμένη οδηγία expire-logs-days.

Μέρος 2: Έλεγχος εγκαταστάσεων εργασίας

Η τεκμηρίωση ενημέρωσης περιέχει 2 βοηθητικά προγράμματα για τον έλεγχο της συμβατότητας της βάσης δεδομένων. Η χρήση τους βοηθά τον διαχειριστή να ελέγξει τη συμβατότητα της υπάρχουσας δομής δεδομένων.

Ας ξεκινήσουμε με το κλασικό βοηθητικό πρόγραμμα mysqlcheck. Απλά τρέξτε:

mysqlcheck -u root -p --all-databases --check-upgrade

Εάν δεν εντοπιστούν προβλήματα, το βοηθητικό πρόγραμμα θα βγει με τον κωδικό 0:

Επιπλέον, ένα βοηθητικό πρόγραμμα είναι διαθέσιμο σε σύγχρονες εκδόσεις της MySQL mysql-shell (στην περίπτωση της Percona αυτό είναι το πακέτο percona-mysql-shell). Είναι μια αντικατάσταση του κλασικού προγράμματος-πελάτη mysql και συνδυάζει τις λειτουργίες ενός πελάτη, ενός επεξεργαστή κώδικα SQL και εργαλεία διαχείρισης MySQL. Για να ελέγξετε τον διακομιστή πριν από την ενημέρωση, μπορείτε να εκτελέσετε τις ακόλουθες εντολές μέσω αυτού:

mysqlsh -- util check-for-server-upgrade { --user=root --host=1.1.1.1 --port=3306 } --config-path=/etc/mysql/my.cnf

Εδώ είναι τα σχόλια που λάβαμε:

Γενικά, τίποτα κρίσιμο - μόνο προειδοποιήσεις για κωδικοποιήσεις (Δες παρακάτω). Συνολικό αποτέλεσμα εκτέλεσης:

Αποφασίσαμε ότι η ενημέρωση πρέπει να γίνει χωρίς προβλήματα.

Μια σημείωση σχετικά με τις παραπάνω προειδοποιήσεις που υποδεικνύουν προβλήματα με τις κωδικοποιήσεις. Το γεγονός είναι ότι το UTF-8 στη MySQL μέχρι πρόσφατα δεν ήταν "αληθινό" UTF-8, αφού αποθήκευσε μόνο 3 byte αντί για 4. Στο MySQL 8 αυτό είναι τελικά αποφάσισε να το διορθώσει: ψευδώνυμο utf8 σύντομα θα οδηγήσει σε κωδικοποίηση utf8mb4, και οι παλιές στήλες στους πίνακες θα γίνουν utf8mb3. Περαιτέρω κωδικοποίηση utf8mb3 θα αφαιρεθεί, αλλά όχι σε αυτήν την έκδοση. Ως εκ τούτου, αποφασίσαμε να διορθώσουμε τις κωδικοποιήσεις που βρίσκονται ήδη στην τρέχουσα εγκατάσταση DBMS, αφού την ενημερώσαμε.

Μέρος 3: Ενημερώσεις διακομιστή

Τι θα μπορούσε να πάει στραβά όταν υπάρχει ένα τόσο έξυπνο σχέδιο;.. Κατανοώντας πολύ καλά ότι οι αποχρώσεις συμβαίνουν πάντα, πραγματοποιήσαμε το πρώτο πείραμα σε ένα σύμπλεγμα προγραμματιστών MySQL.

Οπως ήδη αναφέρθηκε, επίσημη τεκμηρίωση καλύπτει το θέμα της ενημέρωσης των διακομιστών MySQL με αντίγραφα. Η ουσία είναι ότι θα πρέπει πρώτα να ενημερώσετε όλα τα αντίγραφα (σκλάβους), καθώς η MySQL 8 μπορεί να αναπαραχθεί από μια κύρια έκδοση 5.7. Κάποια δυσκολία έγκειται στο γεγονός ότι χρησιμοποιούμε τη λειτουργία κύριος κύριος, όταν το τηλεχειριστήριο είναι σε λειτουργία μόνο για ανάγνωση. Δηλαδή, στην πραγματικότητα, η κίνηση μάχης πηγαίνει σε ένα κέντρο δεδομένων και το δεύτερο είναι εφεδρικό.

Η τοπολογία μοιάζει με αυτό:

Η ενημέρωση πρέπει να ξεκινά με αντίγραφα mysql replica dc 2, mysql master dc 2 и mysql replica dc 1, και τελειώνουμε με τον διακομιστή mysql master dc 1. Για να είμαστε πιο αξιόπιστοι, σταματήσαμε τις εικονικές μηχανές, τραβήξαμε στιγμιότυπά τους και αμέσως πριν την ενημέρωση σταμάτησε η αναπαραγωγή με την εντολή STOP SLAVE. Η υπόλοιπη ενημέρωση μοιάζει με αυτό:

Επανεκκινούμε κάθε αντίγραφο προσθέτοντας 3 επιλογές στις ρυθμίσεις παραμέτρων: skip-networking, skip-slave-start, skip-log-bin. Το γεγονός είναι ότι η ενημέρωση της βάσης δεδομένων δημιουργεί δυαδικά αρχεία καταγραφής με ενημερώσεις σε πίνακες συστήματος. Αυτές οι οδηγίες εγγυώνται ότι δεν θα υπάρξουν αλλαγές στα δεδομένα εφαρμογών στη βάση δεδομένων και ότι οι πληροφορίες σχετικά με την ενημέρωση πινάκων συστήματος δεν θα περιλαμβάνονται στα δυαδικά αρχεία καταγραφής. Αυτό θα αποφύγει προβλήματα κατά την επανάληψη της αναπαραγωγής.
Εγκατάσταση του πακέτου percona-server-server. Είναι σημαντικό να σημειωθεί ότι στην έκδοση 8 της MySQL όχι πρέπει να εκτελέσετε την εντολή mysqlupgrade μετά την ενημέρωση διακομιστή.
Μετά από μια επιτυχημένη εκκίνηση, κάνουμε επανεκκίνηση του διακομιστή ξανά - χωρίς τις παραμέτρους που προστέθηκαν στην πρώτη παράγραφο.
Βεβαιωνόμαστε ότι η αναπαραγωγή λειτουργεί με επιτυχία: ελέγξτε SHOW SLAVE STATUS και δείτε ότι οι πίνακες με τους μετρητές στη βάση δεδομένων της εφαρμογής είναι ενημερωμένοι.

Όλα φαίνονται πολύ απλά: η ενημέρωση προγραμματιστή ήταν επιτυχής. Εντάξει, μπορείτε να προγραμματίσετε με ασφάλεια μια νυχτερινή ενημέρωση για παραγωγή.

Δεν υπήρχε θλίψη - ενημερώσαμε την παραγωγή

Ωστόσο, η μεταφορά της επιτυχημένης εμπειρίας dev στην παραγωγή δεν ήταν χωρίς εκπλήξεις.

Ευτυχώς, η ίδια η διαδικασία ενημέρωσης ξεκινά με αντίγραφα, οπότε όταν αντιμετωπίσαμε δυσκολίες, σταματήσαμε την εργασία και επαναφέραμε το αντίγραφο από το στιγμιότυπο. Η διερεύνηση των προβλημάτων αναβλήθηκε για το επόμενο πρωί. Τα αρχεία καταγραφής περιείχαν τις ακόλουθες εγγραφές:

2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] table: t1 has 19 columns but InnoDB dictionary has 20 columns
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Error in fixing SE data for db1.t1
2020-01-14T21:43:24.208365Z 0 [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Aborting

Η έρευνα στα αρχεία διαφόρων λιστών αλληλογραφίας στο Google οδήγησε στην κατανόηση ότι αυτό το πρόβλημα παρουσιάζεται λόγω Σφάλμα MySQL. Αν και αυτό είναι πιο πιθανό ένα σφάλμα βοηθητικού προγράμματος mysqlcheck и mysqlsh.

Αποδεικνύεται ότι η MySQL άλλαξε τον τρόπο με τον οποίο αναπαριστούν δεδομένα για δεκαδικά πεδία (int, tinyint, κ.λπ.), οπότε ο mysql-server χρησιμοποιεί διαφορετικό τρόπο για να τα αποθηκεύσει. Εάν η βάση δεδομένων σας αρχικά ήταν στην έκδοση 5.5 ή 5.1 και, στη συνέχεια, ενημερώσατε στην 5.7, τότε ίσως χρειαστεί να κάνετε OPTIMIZE για μερικά τραπέζια. Στη συνέχεια, η MySQL θα ενημερώσει τα αρχεία δεδομένων, μεταφέροντάς τα στην τρέχουσα μορφή αποθήκευσης.

Μπορείτε επίσης να το ελέγξετε με το βοηθητικό πρόγραμμα mysqlfrm:

mysqlfrm --diagnostic -vv /var/lib/mysql/db/table.frm
...
 'field_length': 8,
  'field_type': 246, # формат поля
  'field_type_name': 'decimal',
  'flags': 3,
  'flags_extra': 67,
  'interval_nr': 0,
 'name': 'you_deciaml_column',
...

αν field_type Εάν το έχετε ίσο με 0, τότε ο παλιός τύπος χρησιμοποιείται στον πίνακα - πρέπει να πραγματοποιήσετε OPTIMIZE. Ωστόσο, εάν η τιμή είναι 246, έχετε ήδη έναν νέο τύπο. Περισσότερες πληροφορίες για τους τύπους μπορείτε να βρείτε στο κώδικας.

Επιπλέον, στο αυτό το σφάλμα Εξετάζουμε τον δεύτερο πιθανό λόγο, που μας παρέκαμψε: την απουσία πινάκων InnoDB στον πίνακα συστήματος INNODB_SYS_TABLESPACES, εάν αυτοί, πίνακες, δημιουργήθηκαν στην έκδοση 5.1. Για να αποφύγετε προβλήματα κατά την ενημέρωση, μπορείτε να χρησιμοποιήσετε συνημμένο σενάριο SQL.

Γιατί δεν είχαμε τέτοια προβλήματα στο dev; Η βάση δεδομένων αντιγράφεται περιοδικά εκεί από την παραγωγή - επομένως, τα τραπέζια αναδημιουργούνται.

Δυστυχώς, σε μια πραγματικά μεγάλη βάση δεδομένων που λειτουργεί, δεν θα μπορείτε απλώς να πάρετε και να εκτελέσετε μια καθολική OPTIMIZE. Το percona-toolkit θα βοηθήσει εδώ: το βοηθητικό πρόγραμμα pt-online-schema-change είναι εξαιρετικό για την ηλεκτρονική λειτουργία OPTIMIZE.

Το ενημερωμένο σχέδιο έμοιαζε ως εξής:

Βελτιστοποιήστε όλους τους πίνακες.
Ενημερώστε τις βάσεις δεδομένων.

Για να το ελέγξουμε και ταυτόχρονα να μάθουμε τον χρόνο ενημέρωσης, απενεργοποιήσαμε ένα από τα αντίγραφα και εκτελέσαμε την ακόλουθη εντολή για όλους τους πίνακες:

pt-online-schema-change --critical-load Threads_running=150 --alter "ENGINE=InnoDB" --execute --chunk-size 100 --quiet --alter-foreign-keys-method auto h=127.0.0.1,u=root,p=${MYSQL_PASSWORD},D=db1,t=t1

Οι πίνακες ενημερώνονται χωρίς μεγάλα κλείδωμα λόγω του γεγονότος ότι το βοηθητικό πρόγραμμα δημιουργεί έναν νέο προσωρινό πίνακα στον οποίο αντιγράφει δεδομένα από τον κύριο πίνακα. Τη στιγμή που και τα δύο τραπέζια είναι πανομοιότυπα, ο αρχικός πίνακας κλειδώνεται και αντικαθίσταται με τον νέο. Στην περίπτωσή μας, μια δοκιμαστική εκτέλεση έδειξε ότι θα χρειαζόταν περίπου μία ημέρα για την ενημέρωση όλων των πινάκων, αλλά η αντιγραφή δεδομένων προκάλεσε υπερβολικό φορτίο στους δίσκους.

Για να αποφευχθεί αυτό, στην παραγωγή προσθέσαμε το όρισμα στην εντολή --sleep με τιμή 10 - αυτή η παράμετρος προσαρμόζει τη διάρκεια αναμονής μετά τη μεταφορά μιας παρτίδας δεδομένων σε νέο πίνακα. Με αυτόν τον τρόπο μπορείτε να μειώσετε το φορτίο εάν η πραγματική εφαρμογή που εκτελείται απαιτεί χρόνο απόκρισης.

Μετά την εκτέλεση της βελτιστοποίησης, η ενημέρωση ήταν επιτυχής.

... αλλά όχι εντελώς!

Μέσα σε μισή ώρα μετά την ενημέρωση, ο πελάτης αντιμετώπισε πρόβλημα. Η βάση δεδομένων λειτουργούσε πολύ περίεργα: περιοδικά ξεκινούσαν επαναφέρει τη σύνδεση. Έτσι φαινόταν στην παρακολούθηση:

Το στιγμιότυπο οθόνης δείχνει ένα γράφημα πριονωτή λόγω του γεγονότος ότι ορισμένα από τα νήματα του διακομιστή MySQL κατέρρευσαν περιοδικά με ένα σφάλμα. Εμφανίστηκαν σφάλματα στην εφαρμογή:

[PDOException] SQLSTATE[HY000] [2002] Connection refused

Μια γρήγορη επιθεώρηση των αρχείων καταγραφής αποκάλυψε ότι ο δαίμονας mysqld δεν μπορούσε να αποκτήσει τους απαιτούμενους πόρους από το λειτουργικό σύστημα. Κατά την ταξινόμηση σφαλμάτων, ανακαλύψαμε στο σύστημα αρχεία πολιτικής "ορφανών" apparmor:

# dpkg -S /etc/apparmor.d/cache/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/local/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/local/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/usr.sbin.mysqld
mysql-server-5.7: /etc/apparmor.d/usr.sbin.mysqld
# dpkg -l mysql-server-5.7
rc  mysql-server-5.7 5.7.23-0ubuntu0.16.04.1      amd64

Αυτά τα αρχεία δημιουργήθηκαν κατά την αναβάθμιση σε MySQL 5.7 πριν από μερικά χρόνια και ανήκουν σε ένα πακέτο που έχει αφαιρεθεί. Η διαγραφή των αρχείων και η επανεκκίνηση της υπηρεσίας apparmor έλυσαν το πρόβλημα:

systemctl stop apparmor
rm /etc/apparmor.d/cache/usr.sbin.mysqld
rm /etc/apparmor.d/local/usr.sbin.mysqld
rm /etc/apparmor.d/usr.sbin.mysqld
systemctl start apparmor

Εν κατακλείδι

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

Και με αυτήν την όχι πολύ επαγγελματική δημιουργικότητα στα γραφικά, θα ήθελα να πω ένα τεράστιο ευχαριστώ στην Percona για τα εξαιρετικά προϊόντα της!

PS

Διαβάστε επίσης στο blog μας:

Πηγή: www.habr.com

Ενημέρωση MySQL (Percona Server) από 5.7 σε 8.0