Ρύθμιση αναπαραγωγής MySQL χωρίς διακοπή του οδηγού.
1. Ρύθμιση κύριου διακομιστή:
Εξετάζουμε πού πρέπει να βρίσκεται η διαμόρφωση.
# ps aux | grep my.cnf
mysql 51189 0.0 0.0 17064 1912 - Is 6:35 PM 0:00.05 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file= /var/db/mysql/my.cnf--user=mysql --datadir=/var/db/mysql
Εάν το αρχείο λείπει, μπορείτε να το αντιγράψετε από το παράδειγμα.
# cp /usr/local/share/mysql/my-small.cnf /var/db/mysql/my.cnf
Ή δημιουργήστε ένα κενό.
# αγγίξτε /var/db/mysql/my.cnf
Στη διαμόρφωση που δημιουργήθηκε στην ενότητα γράφουμε.
#Μοναδικό αναγνωριστικό διακομιστή. Το κύριο πρέπει να βρίσκεται κάτω από το αντίγραφο και να μην είναι διπλό
διακομιστής - id = 1
#log μορφή
binlog - μορφή = μικτή
#Διαδρομή όπου θα βρίσκεται το binlog (Από προεπιλογή, το μέγεθος ενός αρχείου καταγραφής είναι 1g)
#Χρόνος αποθήκευσης Binlog
expire_logs_days = 30
replicate-do-db=βάση δεδομένων_1
replicate-do-db=βάση δεδομένων_2
replicate-do-db=βάση δεδομένων_3
replicate-do-db=βάση δεδομένων_4
#Αρχείο καταγραφής σφαλμάτων
Σε αυτό ολοκληρώνουμε με την επεξεργασία και επανεκκινούμε τη MySQL με μια νέα διαμόρφωση.
# /usr/local/etc/rc.d/mysql-server επανεκκίνηση
Τώρα πρέπει να προσθέσετε έναν χρήστη στον κύριο για τον διακομιστή Slave.
Για την αναπαραγωγή, αρκούν τα δικαιώματα SLAVE ΑΝΑΠΑΡΑΓΩΓΗΣ. Συνδεθείτε ως root στον διακομιστή MySQL.
# mysql -uroot -p
Δημιουργία χρήστη:
mysql> χρησιμοποιήστε mysql.
mysql>ΔΗΜΙΟΥΡΓΙΑ ΧΡΗΣΤΗ 'replica'@'ip_address_slave_server';
mysql>GRANT REPLICATION SLAVE ON*.* ΣΤΟ 'replica'@'ip_address_slave_server'ΑΝΑΓΝΩΡΙΖΕΤΑΙ ΑΠΟ 'password_for_user_replica';
Τώρα μπορείτε είτε να κάνετε επανεκκίνηση του διακομιστή είτε να πείτε
mysql>FLUSH PRIVILEGES;
2. Δημιουργήστε μια ένδειξη των απαιτούμενων βάσεων δεδομένων:
Όλες οι βάσεις.
# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -A > /usr/home/Timur/dump.sql
ορισμένες βάσεις.
# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -B DATABASE DATABASE1 DATABASE2 DATABASE3 > /usr/home/Timur/dump .sql
3. Εξετάζουμε ποιο binlog να χρησιμοποιήσουμε και τη θέση του:
# head -n80 /usr/home/Timur/dump.sql | grep "MASTER_LOG_POS"
- CHANGE MASTER ΣΕ MASTER_LOG_FILE=' mysql-bin.000049',MASTER_LOG_POS= 107 ;
Παρακαλώ σημειώστε το!!!
4. Κάντε κλικ στο dump και μεταφέρετέ το στον διακομιστή Slave:
# gzip /usr/home/Timur/dump.sql
Μεταφέρουμε.
# scp /usr/home/Timur/dump.sql.gz _address_slave_server:/usr/home/Timur
5. Ρύθμιση του διακομιστή Slave (my.cnf).
διακομιστής-id=2
binlog - μορφή = μικτή
log-bin=/var/log/mysql/mysql-bin
expire_logs_days = 30
#Binglog Slave
relay-log = /var/log/mysql/mysql-relay.log
relay-log-index = /var/log/mysql/mysql-relay-bin.index
#Δίνει εντολή στον διακομιστή κατάντη να καταγράφει τις ενημερώσεις που πραγματοποιούνται στον διακομιστή κατάντη σε ένα δυαδικό αρχείο καταγραφής. Αυτή η επιλογή είναι απενεργοποιημένη από προεπιλογή. Θα πρέπει να είναι ενεργοποιημένο εάν θέλετε να αλυσιδώσετε τους slave διακομιστές της αλυσίδας.
log-slave-updates=1
#Ρυθμίστε τις βάσεις δεδομένων σε μόνο για ανάγνωση. Αυτή η επιλογή δεν ισχύει για υπερχρήστες!!!
μόνο για ανάγνωση = 1
#Παράλειψη διπλότυπων καταχωρήσεων. Αφού το Seconds_Behind_Master γίνει 0, σχολιάστε και επανεκκινήστε το SLAVE
slave-skip-errors=όλα
# Καθορίστε ποιες βάσεις δεδομένων πρέπει να αντιγράψουμε
replicate-do-db=βάση δεδομένων_1
replicate-do-db=βάση δεδομένων_2
replicate-do-db=βάση δεδομένων_3
replicate-do-db=βάση δεδομένων_4
#Αρχείο καταγραφής σφαλμάτων
log-error=/var/log/mysql/mysqld-error.log
#Για να μην ξεκινά το Slave όταν ξεκινά ο διακομιστής. Μπορείτε να το ξεκινήσετε χειροκίνητα START SLAVE.
skip-slave-start = Ενεργό
Κάντε επανεκκίνηση του διακομιστή (MySQL).
6. Ανεβάστε το dump στο Slave και ξεκινήστε την αναπαραγωγή:
Ας αποσυμπιέσουμε.
# gunzip /usr/local/Timur/dump.sql.gz
Φόρτωση της χωματερής.
# mysql -uroot -p< /usr/local/Timur/dump.sql
Λέμε στον Slave από πού να αντλήσει τα δεδομένα και να ξεκινήσει. Το MASTER_LOG_FILE και το MASTER_LOG_POS παίρνουν ό,τι γράψαμε κατά την απόρριψη βάσεων στο Master 😉
mysql>ΑΛΛΑΓΗ MASTER ΣΕ MASTER_HOST=
‘<
Παρακολουθούμε ως ομάδα ΕΜΦΑΝΙΣΗ ΚΑΤΑΣΤΑΣΗΣ ΣΚΛΑΒΟΥ\G Ξεκινήσαμε όλοι;
mysql> ΕΜΦΑΝΙΣΗ ΚΑΤΑΣΤΑΣΗΣ ΔΟΥΛΟΥ\G
****************************** 1η σειρά ****************** **********
Slave_IO_State: Αναμονή για αποστολή συμβάντος από τον κύριο
Master_Host: Αυτή είναι η διεύθυνση του κύριου διακομιστή
Master_User: αντίγραφο
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000049
Read_Master_Log_Pos: 1919771
Relay_Log_File: mysql-relay.000050
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000049
Slave_IO_Running: Ναι
Slave_SQL_Running: Ναι
Replicate_Do_DB: database_1, database_2, database_3, database_4, database_1, database_2, database_3, database_4
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1919771
Relay_Log_Space: 3125
Μέχρι_Κατάσταση: Κανένα
Μέχρι_αρχείο_καταγραφής:
Μέχρι_Log_Pos: 0
Master_SSL_Allowed: Όχι
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: Όχι
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 5
1 σειρά στο σετ (0,00 δευτ.)
Όλα ξεκίνησαν.
Πρέπει να αναπτυχθεί Exec_Master_Log_Pos: 1919771
Εάν παρουσιαστεί κάποιο σφάλμα, μπορείτε να το παραλείψετε εκτελώντας:
mysql> STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;START SLAVE;
Πρόσφατα μου ζήτησαν να μιλήσω για αναπαραγωγή στη MySQL. Αποφάσισα ότι αυτό το θέμα μπορεί να είναι χρήσιμο σε πολλούς, οπότε σε αυτό το άρθρο θα μιλήσω για το πώς τι είναι η αναπαραγωγή στη MySQL, πότε χρειάζεται και πώς να τη ρυθμίσετε.
Το κύριο καθήκον της αναπαραγωγής είναι συνδυάζουν την ισχύ πολλών διακομιστών. Ας υποθέσουμε ότι ο ιστότοπός σας διαθέτει έναν αποκλειστικό διακομιστή, αλλά με την πάροδο του χρόνου γίνεται πολύ επισκέψιμος και δεν αντέχει πλέον το φόρτο. Ως αποτέλεσμα, αρχίζουν τα φρένα και τα κανονικά σφάλματα διακομιστή. Ο ευκολότερος τρόπος είναι να αγοράσετε έναν πιο ισχυρό διακομιστή, και αυτό κάνουν οι περισσότεροι. Αλλά αργά ή γρήγορα, έρχεται η στιγμή που το κόστος αύξησης της τιμής ενός διακομιστή δεν αντιστοιχεί στην αύξηση της απόδοσής του, επομένως είναι πιο κερδοφόρο να αγοράσετε 2 διαφορετικούς διακομιστές για λιγότερα χρήματα.
Ως αποτέλεσμα, η βάση σας θα βρίσκεται σε δύο διακομιστές ταυτόχρονα. Όταν ένας κύριος διακομιστής (γνωστός και ως ο κύριος) δεν μπορεί πλέον να αντεπεξέλθει, τότε υπάρχει αλλαγή στον εφεδρικό.
Ολα Τα αιτήματα ενημέρωσης βάσης δεδομένων πηγαίνουν πάντα στον κύριο διακομιστή. Μετά την ενημέρωση του κύριου διακομιστή, τοποθετεί πληροφορίες σχετικά με αυτό σε ξεχωριστό αρχείο, από όπου λαμβάνονται όλες οι πληροφορίες από τους slave διακομιστές. Αλλά οι λειτουργίες ανάκτησης, οι οποίες είναι συνήθως οι περισσότερες, και είναι οι πιο αργές, μπορούν ήδη να μεταφερθούν σε slave διακομιστές, αφού τα δεδομένα είναι τα ίδια εκεί και εκεί.
Τώρα ας το καταλάβουμε πώς να ρυθμίσετε την αναπαραγωγή στο mysql:
- Εγκαταστήστε τα περισσότερα τις τελευταίες εκδόσεις της MySQLσε όλους τους διακομιστές.
- Δημιουργήστε έναν χρήστη στον κύριο διακομιστή με το προνόμιο ΑΝΤΙΚΑΤΑΣΤΑΣΗ ΣΚΛΑΒ. Ως διεύθυνση από την οποία μπορεί να συνδεθεί, καθορίστε " όλα".
- Διακοπή όλων των διακομιστών.
- Στις ρυθμίσεις MySQL(στο αρχείο my.cnf) Στο κεφάλαιο
προσθέστε τις ακόλουθες γραμμές: log-bin
server-id=1 Σημειώστε ότι αναγνωριστικό διακομιστήσε όλους τους διακομιστές θα πρέπει να είναι διαφορετικό. Στην πραγματικότητα, αυτό είναι που διακρίνει έναν διακομιστή από τον άλλο. - Σε slave διακομιστές, προσθέστε τις ρυθμίσεις MySQLτις ακόλουθες γραμμές: master-host=master_host_name
master-user=login_created_user
master-password=password of_created_user
master-port=port_to_connect_to_master_server
server-id=id_of_this_slave_server - Μεταφέρετε όλες τις βάσειςαπό τον κύριο διακομιστή στους σκλάβους.
- Τρέξιμοκύριος διακομιστής και μετά όλοι οι σκλάβοι.
Η αναφορά μου προορίζεται για εκείνους τους ανθρώπους που γνωρίζουν τη λέξη "replication", γνωρίζουν ακόμη και ότι η MySQL την έχει, και ίσως την έστησαν μια φορά, πέρασαν 15 λεπτά και το ξέχασαν. Δεν ξέρουν τίποτα περισσότερο για αυτήν.
Η έκθεση δεν θα:
Όλα αυτά είναι στο Διαδίκτυο, δεν έχει νόημα να αναλύσουμε τη σύνταξη.
Θα εξετάσουμε λίγο τη θεωρία, θα προσπαθήσουμε να εξηγήσουμε πώς λειτουργούν όλα μέσα και μετά από αυτό θα μπορείτε να βουτήξετε μόνοι σας στην τεκμηρίωση με τριπλάσια δύναμη.
Τι είναι καταρχήν η αναπαραγωγή; Αυτό είναι ένα αντίγραφο των αλλαγών. Έχουμε ένα αντίγραφο της βάσης δεδομένων, θέλουμε ένα άλλο αντίγραφο για κάποιο λόγο.
Η αναπαραγωγή έρχεται σε πολλές μορφές. Διαφορετικοί άξονες σύγκρισης:
- βαθμός συγχρονισμού των αλλαγών (συγχρονισμός, ασυγχρονισμός, ημισυγχρονισμός).
- αριθμός διακομιστών εγγραφής (M/S, M/M).
- αλλαγή μορφής (βασισμένη σε δήλωση (SBR), βάσει σειρών (RBR), μικτή)
- θεωρητικά, αλλάξτε το μοντέλο μεταφοράς (ώθηση, έλξη).
Ένα αστείο γεγονός είναι ότι αν το σκεφτείτε λίγο, η αναπαραγωγή θεωρητικά μας βοηθά να κλιμακώνουμε μόνο για ανάγνωση για θεμελιώδεις λόγους. Εδώ είναι ένα κάπως μη προφανές συμπέρασμα. Αυτό οφείλεται στο γεγονός ότι εάν χρειαστεί να κάνουμε έναν ορισμένο αριθμό αλλαγών στο ίδιο αντίγραφο των δεδομένων και αυτό το συγκεκριμένο αντίγραφο των δεδομένων εξυπηρετείται από τον ίδιο διακομιστή, τότε αυτός ο διακομιστής μπορεί να αντέξει έναν ορισμένο αριθμό ενημερώσεων ανά δευτερόλεπτο, και όχι άλλες μεταφορτώσεις. Ο διακομιστής μπορεί να ενημερώσει 1000 εγγραφές ανά δευτερόλεπτο, αλλά το 2000 δεν είναι. Τι θα αλλάξει από το γεγονός ότι βάλατε ένα αντίγραφο σε αυτόν τον διακομιστή, ανεξάρτητα από το αν είναι σε λειτουργία master-slave ή master-master; Θα μπορέσετε να ρίξετε τις δεύτερες χιλιάδες ενημερώσεις σε αυτήν την παρατήρηση; Η σωστή απάντηση είναι όχι.
Φυσικά, θα μπορείτε να ρίξετε πρόσθετες ενημερώσεις στο αντίγραφο στη λειτουργία master-master, ένα άλλο πράγμα είναι ότι όταν δεν φτάσουν στο πρώτο master και προσπαθήσουν να κάνουν τις δεύτερες χιλιάδες ενημερώσεις σε αυτό, τότε η χωρητικότητα δεν θα είναι αρκετό. Είναι απαραίτητο να κατανοήσουμε και να μην μπερδέψουμε δύο σχεδόν προφανή σημεία ότι η αναπαραγωγή, σαν να λέγαμε, αφορά ένα πράγμα, αλλά ότι τα δεδομένα πρέπει να διαχωριστούν, και αν χρειάζεται να κλιμακώσετε όχι την ανάγνωση, αλλά τη γραφή, τότε θα πρέπει να κάντε κάτι άλλο και η αναπαραγωγή δεν θα σώσει πραγματικά.
Εκείνοι. Η αναπαραγωγή αφορά περισσότερο την ανάγνωση.
Σχετικά με το συγχρονισμό.
Ο συγχρονισμός αποτελεί εγγύηση διαθεσιμότητας και διαθεσιμότητας. Διαθεσιμότητα με την έννοια ότι το commit μας έχει περάσει, η συναλλαγή έχει δεσμευτεί, όλα είναι καλά, αυτά τα δεδομένα είναι ορατά σε έναν ή περισσότερους κόμβους στο σύμπλεγμα, μπορούν να συμμετέχουν στα ακόλουθα αιτήματα. Η διαθεσιμότητα είναι ότι τα δεδομένα, καταρχήν, βρίσκονται σε περισσότερους από έναν διακομιστές, αλλά ίσως η συναλλαγή δεν έχει χαθεί και δεν είναι διαθέσιμη.
Δεν υπάρχει "η δέσμευση ολοκληρώθηκε με επιτυχία, τι σημαίνει αυτό;" ρεφρέν εδώ. Μια σύγχρονη δέσμευση σημαίνει ότι οι τοπικές και απομακρυσμένες δεσμεύσεις μας (τουλάχιστον σε ένα αντίγραφο) έχουν λήξει, δηλ. δεσμευτήκαμε κάτι στο μηχάνημα, εάν έχουμε μια λειτουργία σύγχρονης αναπαραγωγής, τότε αυτές οι αλλαγές πραγματοποιούνται με επιτυχία, είναι ορατές για επόμενα αιτήματα στον τοπικό υπολογιστή, σε ένα απομακρυσμένο μηχάνημα (τουλάχιστον σε ένα) είναι επίσης ορατές. Αυτό σημαίνει ότι εάν συμβεί ένα τυπικό απρόβλεπτο, π.χ. Ο λοστός πέταξε σε έναν από τους διακομιστές και τρύπησε τα πάντα - από τον επεξεργαστή μέχρι την ίδια τη βίδα, στη συνέχεια, παρά το γεγονός αυτό, τα δεδομένα όχι μόνο αντιγράφονται σε έναν απομακρυσμένο διακομιστή, αλλά, επιπλέον, μπορούν αμέσως, χωρίς πρόσθετες καθυστερήσεις, συμμετέχουν σε επόμενες συναλλαγές.
Όλα αυτά είναι γενική ορολογία και δεν έχουν καμία σχέση με τη MySQL. Σε οποιοδήποτε κατανεμημένο σύστημα, θα τακτοποιηθεί έτσι.
Ασύγχρονη δέσμευση - χωρίς πρόσθετες εγγυήσεις, αν είστε τυχεροί.
Μια ημι-σύγχρονη δέσμευση είναι μια ωραία ενδιάμεση λύση, όταν η τοπική μας δέσμευση έχει περάσει, τίποτα δεν είναι γνωστό για την απομακρυσμένη δέσμευση - ίσως ο slave πρόλαβε, ή ίσως όχι, αλλά τουλάχιστον λάβαμε επιβεβαίωση ότι αυτά τα δεδομένα είναι κάπου τότε πέταξαν μακριά και έγιναν δεκτοί εκεί και, πιθανότατα, υπέγραψαν.
Σχετικά με τον διακομιστή για εγγραφή. Ποιοι είναι οι τύποι αντιγραφής.
Κλασικό Master-slave, όλες οι αλλαγές χύνονται σε έναν διακομιστή, μετά τον οποίο αντιγράφονται σε μια μάζα αντιγράφων.
Master-master true - όταν οι αλλαγές ξεχύνονται σε ένα σωρό κυρίους ταυτόχρονα και με κάποιο τρόπο από το ένα στο άλλο, από το άλλο σε ένα τρίτο και μεταξύ όλων, κάτι που προκαλεί τόσο χαρές όσο και ορισμένα αυτόματα προβλήματα . Είναι σαφές ότι όταν έχετε ένα "χρυσό αντίγραφο" και πολλά αντίγραφα από αυτό, τα οποία θα έπρεπε (ιδανικά, αμέσως) να επαναλάβουν αυτό το "χρυσό αντίγραφο", τότε όλα είναι σχετικά απλά όσον αφορά το πώς να οδηγήσετε δεδομένα εμπρός και πίσω και τι κάνετε σε κάθε συγκεκριμένο αντίγραφο. Ένας ενδιαφέρον «πονοκέφαλος» ξεκινά με master-master, και, τονίζω, όχι συγκεκριμένα στην περίπτωση της MySQL, αλλά καθαρά θεωρητικός. Τι θα γινόταν αν σε δύο κόμβους ταυτόχρονα προσπαθούσαν να εκτελέσουν την ίδια συναλλαγή, η οποία αλλάζει τα ίδια δεδομένα και, επιπλέον, τα αλλάζει, για απλότητα του παραδείγματος, με διαφορετικούς τρόπους. Είναι σαφές ότι δεν μπορούμε να εφαρμόσουμε αυτές τις δύο αλλαγές ταυτόχρονα. Τη στιγμή που αρχίζουμε να αλλάζουμε κάτι σε έναν κόμβο, δεν υπάρχει ακόμα τίποτα στον δεύτερο κόμβο. Σύγκρουση. Μία από τις συναλλαγές θα πρέπει να επαναφερθεί. Επιπλέον, ξεχωριστοί «χοροί» ξεκινούν με τη συμφιλίωση ρολογιών κ.λπ.
Ένα ενδιαφέρον σημείο - ακόμη και η επιλογή όταν τελικά έχετε όλες τις αλλαγές από όλα τα κύρια θα πρέπει σταδιακά να εξαπλωθεί παντού, και πάλι δεν θα βοηθήσει το ίδιο εύρος ζώνης εγγραφής. Είναι κρίμα, αλλά μέχρι εκεί.
Μια ωραία επιλογή ονομάζεται "Master-slave + αιτήματα δρομολόγησης". Είναι ευχάριστο στο ότι είναι εύκολο να προγραμματιστεί μέσα, έχετε ένα κύριο αντίγραφο, το αναπαράγετε σε μια δέσμη μηχανών. Αυτό είναι πολύ πιο εύκολο από ό,τι σε ένα περιβάλλον master-master όπου όλοι είναι ίσοι, κ.λπ., αλλά από την άποψη της εφαρμογής, εξακολουθεί να φαίνεται ότι έχετε πολλούς πόντους εγγραφής. Έρχεστε σε οποιονδήποτε κόμβο, ξέρει πού να σας δρομολογήσει και δρομολογεί με επιτυχία. Λοιπόν, οι αναγνώσεις είναι κλιμακούμενες - αυτή είναι η ευτυχία της αναπαραγωγής. Μπορείτε να διαβάσετε από όλα τα σημεία όλα και πάντα.
Τώρα πιο κοντά σε βάσεις δεδομένων, "μαγικές" μορφές που βασίζονται σε δηλώσεις, σειρές κ.λπ. Σχετικά με τη μορφή των αλλαγών.
Τί μπορεί να γίνει? Μπορείτε να στείλετε τα ίδια τα αιτήματα ή μπορείτε να στείλετε μόνο αλλαγμένες σειρές. Τονίζω ότι, ενώ δεν έχουμε ακόμη βουτήξει στα άγρια της MySQL, κάθε DBMS που έχει ερωτήματα που δημιουργούν μεγάλο (ή όχι πολύ) αριθμό αλλαγών μπορεί να το κάνει αυτό. ενημέρωση πολλών δεδομένων. Τίθεται το ερώτημα - τι ακριβώς θα αντιγράψουμε; Μπορείτε να οδηγείτε τα ίδια τα αιτήματα εμπρός και πίσω μεταξύ των κόμβων ή μπορείτε να οδηγείτε μόνο τα αλλαγμένα δεδομένα. Είναι ενδιαφέρον ότι έτσι και εκεί είναι πολύ κακό! Μπορείτε ακόμα να δοκιμάσετε να αναμίξετε.
Ένα ακόμη σημείο σχετικά με το τι είναι οι επαναλήψεις. Σχετικά με το μοντέλο διανομής. Πιθανώς, κάπου το μοντέλο που βασίζεται σε Push δεν έχει ακόμη εξαφανιστεί εντελώς, όταν ο κόμβος που έκανε τις αλλαγές είναι υποχρεωμένος να τις στείλει σε όλους τους άλλους κόμβους. Από την άποψη της κατάστασης προγραμματισμού και παρακολούθησης, αυτό εξακολουθεί να είναι μια ταλαιπωρία. Επομένως, κανόνες που βασίζονται σε έλξη. Η λήψη ενημερώσεων από έναν συγκεκριμένο κόμβο είναι πολύ πιο εύκολο να προγραμματιστεί από την παρακολούθηση ενός χαοτικού συμπλέγματος των αντιγράφων σας σε έναν κόμβο.
Έχουν εισαχθεί ορισμένοι γενικοί όροι. Ας προχωρήσουμε στο πώς το κάναμε στη MySQL.
Η MySQL, από μόνη της, είναι μια απάτη. Υπάρχει ένα λογικό επίπεδο που ονομάζεται MySQL, το οποίο ασχολείται με κάθε είδους γενικές και μεμονωμένες περιπτώσεις από αποθήκευση δεδομένων - δικτύωση, βελτιστοποιητής, κρυφές μνήμες κ.λπ. Το συγκεκριμένο φυσικό επίπεδο που είναι υπεύθυνο για την αποθήκευση δεδομένων βρίσκεται έναν όροφο παρακάτω. Υπάρχουν πολλά ενσωματωμένα, υπάρχουν πρόσθετα. Αλλά ακόμα και τα ενσωματωμένα MyISAM, InnoDB κ.λπ. ζουν στο φυσικό επίπεδο. Η αρχιτεκτονική των προσθηκών είναι δροσερή, μπορείτε να παραλάβετε έναν νέο κινητήρα, αλλά αμέσως προκύπτει κάποια μη βελτιστοποίηση. Κατ 'αρχήν, το αρχείο καταγραφής συναλλαγών "και (WAL), το οποίο γράφει ούτως ή άλλως το επίπεδο φυσικής αποθήκευσης, θα ήταν καλό να χρησιμοποιηθεί για αναπαραγωγή και εάν το σύστημα γνωρίζει ότι υπάρχει ένα συγκεκριμένο φυσικό επίπεδο ή είναι αρκετά καλά διασυνδεδεμένο με αυτό φυσικό επίπεδο , τότε θα ήταν δυνατό να μην γράψετε ένα ξεχωριστό αρχείο καταγραφής στο λογικό επίπεδο, αλλά να χρησιμοποιήσετε το ίδιο WAL... Αλλά στη MySQL αυτό είναι εννοιολογικά αδύνατο ή εάν αλλάξετε τη διεπαφή στο PSE ώστε να γίνει εννοιολογικά δυνατό , τότε θα υπάρχει πολλή δουλειά.
Η αναπαραγωγή υλοποιείται στο επίπεδο της ίδιας της MySQL. Υπάρχει ένα καλό πράγμα σε αυτό - εκτός από ένα αρχείο καταγραφής με τη μορφή βαθιά εσωτερικών δεδομένων του κινητήρα αποθήκευσης, υπάρχει ένα περισσότερο ή λιγότερο λογικό αρχείο καταγραφής, ίσως σε επίπεδο δήλωσης, το οποίο διατηρείται ξεχωριστά από αυτόν τον κινητήρα. Και αυτό είναι "έξτρα" ασφάλεια κτλ. συν, αφού δεν υπάρχουν περιορισμοί στο εσωτερικό, μπορείτε να κάνετε κάθε είδους δημιουργικό όπως αλλαγή κινητήρα εν κινήσει.
Με τους όρους που εισήχθησαν στην MySQL 4.1, εφαρμόστηκε: master-slave, pull-based, αυστηρά ασύγχρονο και αυστηρά SBR. Εάν έχετε κολλήσει στην αρχαία εποχή 4.x, τότε μάλλον έχετε πρόβλημα. Οι εκδόσεις 5.x είναι ήδη σχεδόν 10 ετών - θα ήταν καιρός να αναβαθμιστούν.
Είναι αστείο να ακολουθείς τις εκδοχές για το πώς οι άνθρωποι πατούσαν σε κάθε είδους τσουγκράνες και, όταν δεν μπορούσε να γίνει τίποτα, βίδωσαν νέες τσουγκράνες σε αυτές τις τσουγκράνες για να μην είναι τόσο οδυνηρή η ζωή. Έτσι, στην έκδοση 5.1 βίδωσαν το RBR για να αντισταθμίσουν τα αναπόφευκτα προβλήματα με το SBR, και βίδωσαν τη μικτή λειτουργία. Στην έκδοση 5.6, προστέθηκαν μερικά ακόμη ωραία πράγματα: semi-sync, delayed slave, GTID.
Άλλη μια στιγμή. Δεδομένου ότι η MySQL είναι ένα είδος κοινού στρώματος, αφενός, και ένα σωρό κινητήρες με δυνατότητα σύνδεσης, από την άλλη, συμπεριλαμβανομένων των ενσωματωμένων, από μια συγκεκριμένη στιγμή υπάρχει ένα θεϊκό σύμπλεγμα NDB, για το οποίο μιλούν ψύχραιμα. Υπάρχει μια πλήρως σύγχρονη αναπαραγωγή master-master, μια πολύ προσιτή βάση δεδομένων στη μνήμη... Αλλά υπάρχει μια προειδοποίηση - μόλις αρχίσετε να αναζητάτε άτομα που χρησιμοποιούν το σύμπλεγμα NDB στην παραγωγή, υπάρχουν πολύ λίγα τέτοια άτομα.
Τι κάνει ο κύριος όταν αποφασίζετε να ενεργοποιήσετε την αναπαραγωγή; Υπάρχει αρκετή επιπλέον κίνηση στον κύριο. Ως συνήθως, λαμβάνουμε αιτήματα μέσω του δικτύου, τα αναλύουμε, εκτελούμε συναλλαγές, τα διορθώνουμε κ.λπ. Επιπλέον, στο λογικό επίπεδο της MySQL, ο κύριος αρχίζει να διατηρεί ένα δυαδικό αρχείο καταγραφής - ένα αρχείο, όχι εντελώς ένα αρχείο κειμένου, στο οποίο χύνονται όλες οι αλλαγές. Ο κύριος μπορεί επίσης να στείλει αυτά τα αρχεία καταγραφής μέσω του δικτύου. Όλα είναι πολύ απλά και φαίνεται να λειτουργούν.
Τι κάνει ο Slave; Είναι καλύτερα να μην στείλετε αλλαγές στον δούλο, γιατί μπορεί να μπείτε σε κάτι ακατανόητο. Ο σκλάβος έχει λίγη δουλειά ακόμα. Εκτός από τη διατήρηση ενός επιπλέον αρχείου καταγραφής και την αποστολή του κατόπιν αιτήματος, υπάρχει επίσης ένα νήμα που πηγαίνει σε έναν απομακρυσμένο κύριο, ίσως ούτε καν, και κατεβάζει το δυαδικό αρχείο καταγραφής "και από εκεί. Λύση" ας πάμε σε και από πολλούς απομακρυσμένους κύριους λήψη διαφορετικών αρχείων καταγραφής" είναι διφορούμενη. Από τη μία πλευρά, δεν είναι κακό, αλλά από την άλλη, αποδεικνύεται ότι είναι μια στιγμιαία απόκλιση. Είναι απλώς αδύνατο να αντιγράψετε φυσικά αρχεία χρησιμοποιώντας το SCP, αποδεικνύεται ήδη ένα αρχείο καταγραφής στον διακομιστή, έχει τις δικές του θέσεις, τοπικά τα τραβάμε κατά μήκος του πλέγματος, τα βάζουμε σε ξεχωριστό αρχείο καταγραφής, τρέχει επίσης ένα ξεχωριστό νήμα και προσπαθεί να παίξει αυτά τα τοπικά αρχεία καταγραφής. Το πιο κολασμένο πράγμα, κατά τη γνώμη μου, είναι ότι μέχρι την έκδοση 5.6 , η αναγνώριση μιας συγκεκριμένης συναλλαγής στο αρχείο καταγραφής πραγματοποιήθηκε με βάση το όνομα του αρχείου και τη θέση στην κύρια μονάδα. Μια ενδιαφέρουσα λύση.
Εδώ είναι η διαδρομή εγγραφής που διασχίζει ένα απλό ένθετο χωρίς αναπαραγωγή:
Η εφαρμογή συνδέθηκε στον διακομιστή, βάλτε την σε έναν πίνακα και κλείστε το τηλέφωνο.
Με την αναπαραγωγή, υπάρχουν πολλά πρόσθετα βήματα:
Η εφαρμογή εγγραφής πηγαίνει στον κύριο με τον ίδιο τρόπο, αλλά επιπλέον, αυτά τα δεδομένα εισέρχονται στο δυαδικό αρχείο καταγραφής με τη μία ή την άλλη μορφή, στη συνέχεια μεταφορτώνονται μέσω του δικτύου στο αρχείο καταγραφής αναμετάδοσης, στη συνέχεια από το αρχείο καταγραφής αναμετάδοσης "και σταδιακά αναπαράγονται (αν είμαστε τυχεροί και ο σκλάβος δεν υστερεί, επαναλαμβάνονται αμέσως) στον πίνακα του δούλου, μετά από αυτό όλα είναι διαθέσιμα στον αναγνώστη.
Τι συγκεκριμένα μπαίνει στο δυαδικό αρχείο καταγραφής εξαρτάται από τις ρυθμίσεις SBR/RBR/μικτές. Από πού προέρχονται όλα αυτά; Ας προσποιηθούμε ότι είμαστε μια βάση δεδομένων. Λάβαμε ένα απλό αίτημα "ενημέρωση μιας συγκεκριμένης εγγραφής" - ΕΝΗΜΕΡΩΣΗ χρηστών SET x=123 WHERE id=456
Τι να γράψω στο δυαδικό αρχείο καταγραφής; Βασικά, δεν έχει μεγάλη σημασία. Μπορούμε να καταγράψουμε ένα σύντομο ερώτημα ή (και ενημέρωσε μια εγγραφή) μπορούμε να καταγράψουμε την αλλαγή με κάποιο τρόπο σε μια ή την άλλη μορφή.
Άλλη κατάσταση. Ας φανταστούμε ότι λάβαμε το ίδιο αίτημα, το οποίο είναι μικρό από μόνο του, αλλά αλλάζει πολλά δεδομένα - ΕΝΗΜΕΡΩΣΗ χρηστών SET bonus=bonus+100
Υπάρχει μόνο μία αποτελεσματική επιλογή εδώ - να γράψετε το ίδιο το αίτημα, επειδή το αίτημα είναι ακριβώς 32 byte και μπορεί να ενημερώσει έναν αυθαίρετο αριθμό εγγραφών - 1000, 100.000, 1.000.000, όσες θέλετε... Είναι αναποτελεσματικό να εγγραφή αλλαγμένων εγγραφών στο αρχείο καταγραφής.
Και τι θα συμβεί αν βάλουμε ένα τόσο απλό αίτημα στο αρχείο καταγραφής "ας απενεργοποιήσουμε όλους τους χρήστες που δεν έχουν συνδεθεί για μεγάλο χρονικό διάστημα" - ΕΝΗΜΕΡΩΣΗ χρηστών SET disabled=1 WHERE last_login
Ξαφνικά επικρατεί τρόμος. Το πρόβλημα είναι ότι εάν το ίδιο το αίτημα αναπαραχθεί ιδανικά, τότε, πρώτον, ο χρόνος δεν είναι ποτέ σύγχρονος μεταξύ δύο κόμβων, επιπλέον, λόγω του γεγονότος ότι η διαδρομή εγγραφής είναι τόσο μεγάλη, τη στιγμή της επανάληψης αυτό το "NOW" θα διασκορπίζω. Το αντίγραφο ξαφνικά διαφωνεί με τον κύριο και όλες οι επόμενες αλλαγές, τυπικά μιλώντας, δεν είναι πλέον ασφαλείς, μπορούν να οδηγήσουν σε οτιδήποτε.
Σε γενικές γραμμές, για τέτοια αιτήματα, ανεξάρτητα από τον όγκο των δεδομένων που έχουν αλλάξει, ιδανικά, οι ίδιες οι γραμμές θα πρέπει να αντιγράφονται. Στη συγκεκριμένη περίπτωση, δεν μπορείτε να αντιγράψετε τις ίδιες τις γραμμές, αλλά να διορθώσετε τη σταθερά και να γράψετε στο αρχείο καταγραφής όχι "NOW", αλλά μια συγκεκριμένη χρονική σήμανση που χρησιμοποιήθηκε από τον κύριο κατά τη στιγμή της αναπαραγωγής.
Διασκεδαστικά γεγονότα που μαθαίνεις κατά λάθος ενώ βουτάς στην άγρια φύση της αναπαραγωγής. Επιπλέον, μπορείτε να βουτήξετε ρηχά - τα συναντάτε αμέσως. Με τυχαία σειρά είναι:
- ο κύριος είναι πολύκλωστος, αλλά ο σκλάβος όχι. Είναι σαφές ότι εάν ο κύριος χύνει το φορτίο σε τέσσερις πυρήνες, ο slave δεν έχει χρόνο να ρίξει αυτό το φορτίο σε έναν πυρήνα. Όλα είναι πολύ άσχημα.
- η κατάσταση slave καθορίζεται από το όνομα θέσης στο κύριο αρχείο. Σκεφτείτε το - η κατάσταση ενός κόμβου στο σύμπλεγμα καθορίζεται από το όνομα του αρχείου και τη θέση σε αυτό το αρχείο στον άλλο κόμβο του συμπλέγματος, με τον οποίο μπορεί να συμβεί οτιδήποτε για οποιοδήποτε λόγο!
- "εξοικονόμηση" RBR. Αποδεικνύεται ότι από προεπιλογή, πλήρεις εικόνες πριν/μετά τη σειρά γράφονται εκεί, π.χ. αλλάξαμε μια στήλη σε μια σειρά πέντε kilobyte, ωχ! - 10 Kb κίνησης και 20-40 byte γενικής χρήσης ανά γραμμή, μετά op! - μια τόσο τολμηρή γραμμή της προηγούμενης έκδοσης πηγαίνει, op! – ακολουθεί αυτή την έκδοση με νέες τιμές. Οι διαχειριστές ουρλιάζουν από κοινού! Ωστόσο, είναι απλά φοβερό όσον αφορά ορισμένες διεστραμμένες εφαρμογές, όπως εξωτερικοί αναγνώστες που προσπαθούν να συνδεθούν με τον διακομιστή MySQL, να αντλήσουν δεδομένα από αυτόν και να κάνουν κάτι με αυτόν, όπως να τον τοποθετήσουν σε ένα ευρετήριο πλήρους κειμένου. Όσο κακό κι αν είναι από την άποψη της διαχείρισης της βάσης δεδομένων, στην οποία μια αλλαγή τριών byte δημιουργεί 10 Kb κίνησης στη βίδα και στη συνέχεια 10 Kb κίνησης δικτύου ανά υποτελή, είναι εξίσου καλή για οποιαδήποτε αναζήτηση πλήρους κειμένου τύπου συστήματα όπως το Sphinx, τα οποία έχουν δεν υπάρχει τοπικό αντίγραφο των δεδομένων και δεν υπάρχει καμία επιθυμία να εφαρμοστεί η MySQL από την αρχή. Στην MySQL 5.6, το συνειδητοποίησαν και έφτιαξαν το binlog_row_image (αλλά γεμάτο από προεπιλογή, όχι minimal ή noblob).
Με λίγα λόγια, όλα δεν είναι τακτοποιημένα με πονηριά - ένα ραβδί, ένα σχοινί, ένα κούτσουρο, το δεύτερο κούτσουρο. Και ακόμη και σε αυτό το αρχείο καταγραφής, οι "παιδικές" ασθένειες είναι πολύ αστείες:
Για ένα άτομο που χρησιμοποιεί την αναπαραγωγή για δύο ημέρες, όλα αυτά είναι τρομακτικά και σκληρά. Αλλά, γνωρίζοντας πόσο απλό είναι, κατ 'αρχήν, είναι σαφές πώς να ζήσετε με αυτό:
- Καταρχάς, δεν πιστεύουμε στις προεπιλογές.
- κοιτάξτε προσεκτικά τις ρυθμίσεις, σκεφτείτε τι θέλουμε - SBR, RBR κ.λπ.
Και είναι καλύτερα να το ρυθμίσετε αμέσως για να μην αποσυναρμολογήσετε αργότερα την περίεργη γέμιση.
Στην κατάσταση "το αρχείο καταγραφής είναι σάπιο, η θέση έχει φύγει, δεν είναι γνωστό τι συμβαίνει" υπάρχει μια συγκεκριμένη εργαλειοθήκη - εξετάζουμε τα γεγονότα, προσπαθούμε να καταλάβουμε ποια συναλλαγή έχει ήδη γλιστρήσει, ποια όχι, μπορεί ολόκληρο το πράγμα να αποθηκευτεί ή να αποκατασταθεί, κ.λπ. Εάν το GTID «Αν καταφέρατε να το ενεργοποιήσετε εκ των προτέρων, τότε η ζωή γίνεται ευκολότερη.
Ένα άλλο σημείο παρατήρησης αντιγραφής. Είναι ενδιαφέρον να δούμε πώς η εσωτερική στραβά συσκευή προκαλεί όχι μόνο τον ανταγωνισμό, αλλά τη δημιουργία πρόσθετων προϊόντων. Ο "μαγικός" αντιγραφέας βολφραμίου, λένε, λύνει καλά το πρόβλημα που ονομάζεται "ο σκλάβος με ένα σπείρωμα είναι κακό" και αν δεν υπήρχαν οι εγγενείς δυσκολίες, δεν θα υπήρχε επιπλέον προϊόν που να σας επιτρέπει να χρησιμοποιήσετε αυτόν τον μηχανισμό, να μεταφέρετε δεδομένα σε άλλα συστήματα, αφενός, και ταυτόχρονα να λύσει μια σειρά προβλημάτων που είναι ενσωματωμένα στο υπάρχον σύστημα, αφετέρου.
Ως συνήθως, είναι αδύνατο να συμβουλεύσουμε. Βοηθάει κάποιον, κάποιος θα φτύσει πολύ. Αλλά, λένε, υπάρχουν καταστάσεις στις οποίες το Tungsten αντιμετωπίζει καλά την αναπόφευκτη υστέρηση ενός νήματος. Είμαι βέβαιος ότι υπάρχουν και άλλα δύσκολα κόλπα, αλλά ένα εσωτερικό μονόκλωστο slave είναι δύσκολο.
Τι να κάνετε εάν για κάποιο λόγο χρησιμοποιήσατε αντίγραφα ως αντίγραφο ασφαλείας; Νομίζω ότι πρέπει να χτυπήσεις το κεφάλι σου στον τοίχο, γιατί ένα αντίγραφο και ένα εφεδρικό είναι δύο διαφορετικά πράγματα. Ωστόσο, αν είστε δημιουργικοί τύποι και χρησιμοποιείτε μια αρκετά νέα έκδοση, η καθυστερημένη αναπαραγωγή σας σώζει αφενός, αλλά αφετέρου, αν δεν κάνετε πλήρη αντίγραφα ασφαλείας, τίποτα δεν θα σας σώσει έτσι κι αλλιώς.
Μετά ένα άλλο στοιχείο δημιουργικότητας. Είναι εύκολο να φανταστεί κανείς μια κατάσταση όταν ο κύριος καταγράφει ολόκληρο το δίσκο cloud των 10 PB με αρχεία καταγραφής ή γέμισε ολόκληρο το δίκτυο με τη διανομή αυτών των αρχείων καταγραφής, ενώ δεν χρειαζόμαστε το 90% αυτών των ενημερώσεων, επειδή μας ενδιαφέρει να αναπαράγουμε, για Για παράδειγμα, ένας πίνακας συγκεκριμένα ή μια βάση δεδομένων ειδικά, και από προεπιλογή όλα εμπίπτουν σε έναν άξονα σε ένα δυαδικό αρχείο καταγραφής - όλες οι αλλαγές σε όλες τις βάσεις δεδομένων, σε όλους τους πίνακες, σε όλα. Η λύση είναι και πάλι εντυπωσιακή στη δημιουργικότητά της. Από τη μία πλευρά, υπάρχουν τέσσερις ρυθμίσεις - (binlog|replicate)_(do|ignore)_db, οι οποίες σας επιτρέπουν να φιλτράρετε στο master - τι θα καταγραφεί και τι θα αγνοηθεί. Στο slave, αντίστοιχα, σας επιτρέπει να κάνετε το ίδιο. Εκείνοι. στον κύριο, μπορούμε να φιλτράρουμε ό,τι μπαίνει στο δυαδικό αρχείο καταγραφής - σε αυτήν τη διοχέτευση, η οποία στη συνέχεια συγχωνεύεται στο δίκτυο, και στο slave, αντίστοιχα, μπορούμε να βάλουμε ένα εισερχόμενο φίλτρο σε ό,τι έρχεται από το δίκτυο. Ή γράψτε μόνο ένα μέρος των δεδομένων στο δίσκο και, στη συνέχεια, επαναλάβετε, ξανά, μόνο ένα μέρος των δεδομένων στη βοηθητική μονάδα. Ξαφνικά, ακόμα και σε αυτή την απλή ιστορία, ο τρόμος εμφανίζεται, γιατί ο συνδυασμός - χρησιμοποιούμε μια βάση δεδομένων και ενημερώνουμε τον πίνακα σε μια άλλη βάση δεδομένων μέσω μιας ενδιαφέρουσας σύνταξης - συμπεριφέρεται κάπως ... Αλλά το πώς ακριβώς θα συμπεριφερθεί είναι άγνωστο, γιατί. διαφορετικά φίλτρα λειτουργούν σε διαφορετικούς χρόνους.
Δεν υπάρχουν ενσωματωμένα ωραία πράγματα που λέγονται "επανεκλογή του κυρίου αν πέθανε ξαφνικά", πρέπει να το σηκώσεις με τα χέρια σου. Η έλλειψη εργαλείων για τη διαχείριση συστάδων - αυτό, κατά τη γνώμη μου, είναι καλό - δημιουργεί ανταγωνισμό, δημιουργεί τη δημιουργία πρόσθετων προϊόντων. Πράγματι, εάν ένα πολύ ωραίο master-master replication λειτουργούσε ιδανικά σε κανονική MySQL, ή τουλάχιστον αυτόματη αύξηση μετά από αποτυχίες, τότε γιατί θα χρειαζόταν οποιοδήποτε σύμπλεγμα Galera, Percona / MariaDB, κ.λπ.;
Λίγα κόλπα ακόμα. Μια ενδιαφέρουσα εφαρμογή αναπαραγωγής, η οποία είναι τόσο απλή όσο ένα ραβδί και ένα σχοινί, χωρίς κανέναν έλεγχο, αφενός, και χωρίς εργαλεία για πιο ευχάριστη διαχείριση ενός αναπαραγόμενου συμπλέγματος σκλάβων, από την άλλη. Αυτό είναι κακό. Αλλά από την άλλη, μπορείτε να σκαλίσετε χειροκίνητα τόσο ενδιαφέρουσες διαμορφώσεις από αυτό που όλοι όσοι θα έρθουν αργότερα και θα το διαλύσουν θα ανατριχιάσουν.
Διαμόρφωση #1. Το master-master σε στυλ MySQL γίνεται ως εξής:
Αυτό που με τρομάζει είναι πόσοι ηλίθιοι υπάρχουν στον κόσμο! Google "MySQL Replication Wizard" - κάθε δεύτερος σύνδεσμος είναι κάπως έτσι. Η Κόλαση και το Ολοκαύτωμα.
Focus αριθμός 2 - catch-all σκλάβος - πιο ευχάριστο. Δεν υπάρχουν περιττοί έλεγχοι - τι πετάει από ποιον, σε ποιον παίρνει και τι να κάνει με αυτό. Λόγω αυτού, μπορείτε να κάνετε αστεία πράγματα όπως ένα slave, στον οποίο είτε μέρος των δεδομένων από μια δέσμη διακομιστών συγχωνεύεται σκόπιμα είτε όλα τα δεδομένα από όλους τους διακομιστές συγχωνεύονται σκόπιμα - ένας διακομιστής με όλα, όλα τα αντίγραφα ασφαλείας. Αλλά, επαναλαμβάνω, υπάρχει αντιγραφή, δηλ. υπάρχει κάποιο βασικό εργαλείο που αντιγράφει τον πίνακα Α αντί για το Β και τέλος.
Και τέλος, εστίαση αριθμός 3 - αντικαθιστούμε τα πάντα. Θυμηθείτε ότι η αναπαραγωγή ζει σε ένα λογικό επίπεδο που δεν έχει καμία σχέση με το επίπεδο φυσικής αποθήκευσης. Εξαιτίας αυτού, μπορεί να είναι εξαιρετικά ενδιαφέρον η στροφή. Μπορείτε να αλλάξετε τη μηχανή "on the fly" για ακατανόητους σκοπούς - εδώ είναι η αληθινή ιστορία, ότι, λένε, η αναπαραγωγή από βάσεις δεδομένων InnoDB σε πίνακες MyISAM είναι μόνο για χάρη της αναζήτησης πλήρους κειμένου που λειτουργεί τουλάχιστον με κάποιο τρόπο. Υπάρχει ένα δημιουργικό τέχνασμα που ονομάζεται "αλλαγή σχήματος μέσω αναπαραγωγής". Αρνούμαι να καταλάβω τι είναι το λίπος, αλλά υπάρχουν τέτοια κόλπα. Λοιπόν, υπάρχει ένας κατανοητός και ενδιαφέρον τρόπος λειτουργίας που ονομάζεται "παρανοϊκή αναβάθμιση έκδοσης μέσω αναπαραγωγής".
Κατά την παρουσίαση μάθαμε:
Ωστόσο, μπορείτε να ζήσετε με αυτήν την κόλαση, αν καταλάβετε τουλάχιστον κατά προσέγγιση πώς λειτουργεί.
Το βασικό μήνυμα είναι ότι:
Το 2015, στο συνέδριο HighLoad++ Junior, ο Andrey Aksyonov διάβασε μια νέα έκδοση της αναφοράς του σχετικά με τη συσκευή αναπαραγωγής στη MySQL. Το αποκρυπτογραφήσαμε και στο blog μας.
αντιγραφή- μια τεχνική που χρησιμοποιείται στην αρχιτεκτονική συστημάτων που λειτουργούν υπό φορτίο, το αποτέλεσμα της οποίας είναι η κατανομή του φορτίου κατά την εργασία με μία βάση δεδομένων σε πολλούς διακομιστές. Η αναπαραγωγή MySQL MASTER SLAVE χρησιμοποιείται πιο συχνά, αλλά χρησιμοποιείται επίσης ένας δεύτερος τύπος αναπαραγωγής - Master-Master.
Τι είναι η αναπαραγωγή MySQL MASTER SLAVE και σε τι χρησιμοποιείται;
αντιγραφή αφέντης-σκλάβοςπεριλαμβάνει την αντιγραφή δεδομένων σε έναν slave διακομιστή MySQL, αυτή η αντιγραφή γίνεται κυρίως με σκοπό τη διασφάλιση της αξιοπιστίας. Σε περίπτωση αποτυχίας του Master server, οι λειτουργίες του αλλάζουν στον Slave.
Η αναπαραγωγή μπορεί επίσης να πραγματοποιηθεί για τη βελτίωση της απόδοσης του συστήματος, αλλά η απόδοση είναι σχεδόν πάντα δευτερεύουσα εδώ.
Όταν μια εφαρμογή λειτουργεί με μια βάση δεδομένων, οι πιο συχνές λειτουργίες είναι λειτουργίες ΕΠΙΛΕΓΩ- αιτήματα για ανάγνωση δεδομένων, τροποποίηση δεδομένων - αιτήματα ΔΙΑΓΡΑΦΩ, ΕΙΣΑΓΕΤΕ, ΕΚΣΥΓΧΡΟΝΙΖΩ, ΑΛΛΑΖΩστατιστικά εμφανίζεται πολύ λιγότερο συχνά.
Για να αποτραπεί η απώλεια δεδομένων σε περίπτωση αποτυχίας ενός από τους διακομιστές, οι λειτουργίες αλλαγής πληροφοριών στους πίνακες υποβάλλονται πάντα σε επεξεργασία από τον κύριο διακομιστή. Στη συνέχεια, οι αλλαγές αναπαράγονται στο Slave. Η ανάγνωση μπορεί να γίνει από τον διακομιστή που παίζει το ρόλο του Slave.
Λόγω αυτού, μπορείτε να έχετε κέρδος απόδοσης μαζί με αξιοπιστία.
Η λύση είναι δημοφιλής, αλλά δεν είναι πάντα εφαρμόσιμη, καθώς η αναπαραγωγή ενδέχεται να παρουσιάσει καθυστερήσεις - εάν συμβεί αυτό, οι πληροφορίες πρέπει επίσης να διαβαστούν από τον κύριο διακομιστή.
Η κατεύθυνση των αιτημάτων ενός συγκεκριμένου τύπου προς έναν συγκεκριμένο διακομιστή βάσης δεδομένων υλοποιείται σε κάθε περίπτωση σε επίπεδο εφαρμογής.
Εάν διαχωρίσετε τα ερωτήματα SELECT και όλα τα υπόλοιπα σε επίπεδο προγράμματος στέλνοντάς τα στον επιθυμητό διακομιστή, εάν ένα από αυτά αποτύχει, η εφαρμογή που εξυπηρετεί την υποδομή θα είναι μη λειτουργική. Για να λειτουργήσει αυτό, πρέπει να παρέχετε ένα πιο περίπλοκο σχήμα και να κάνετε κράτηση για καθέναν από τους διακομιστές.
Η αναπαραγωγή είναι για ανοχή σφαλμάτων, όχι για κλιμάκωση.
Αντιγραφή MySQL MASTER SLAVE - εγκατάσταση στο Debian
Θα χρησιμοποιήσουμε δύο διακομιστές με διευθύνσεις:
- Κύριος διακομιστής 192.168.0.1
- Slave server 192.168.0.2
Για επίδειξη, χρησιμοποιούνται VDS συνδεδεμένα σε τοπικό δίκτυο.
Για να γνωρίζουμε πάντα με βεβαιότητα σε ποιον διακομιστή εκτελούμε αυτήν ή εκείνη την εντολή, θα επεξεργαστούμε τα αρχεία /etc/hosts και στους δύο διακομιστές
192.168.0.1 κύριος
192.168.0.2 σκλάβος
Θα αντικαταστήσουμε τις υπάρχουσες τιμές στο /etc/hostname με master και slave αντίστοιχα, ώστε οι αλλαγές να τεθούν σε ισχύ, ο διακομιστής να επανεκκινηθεί.
1. Κάνουμε ρυθμίσεις στον κύριο διακομιστή.
Επεξεργασία του αρχείου διαμόρφωσης του κύριου διακομιστή βάσης δεδομένων
mcedit /etc/mysql/my.cnf
Επιλέξτε το αναγνωριστικό διακομιστή - μπορείτε να καθορίσετε οποιονδήποτε αριθμό, η προεπιλογή είναι 1 - απλώς αφαιρέστε το σχόλιο της γραμμής
Αναγνωριστικό διακομιστή = 1
Ρυθμίστε τη διαδρομή στο δυαδικό αρχείο καταγραφής - καθορίζεται επίσης από προεπιλογή, χωρίς σχολιασμό
Ορίζουμε το όνομα της βάσης δεδομένων που θα αντιγράψουμε σε άλλο διακομιστή
binlog_do_db = db1
Κάντε επανεκκίνηση της Mysql έτσι ώστε το αρχείο ρυθμίσεων να ξαναδιαβαστεί και οι αλλαγές να τεθούν σε ισχύ:
/etc/init.d/mysql επανεκκίνηση
2. Ορίστε στον χρήστη τα απαραίτητα δικαιώματα
Μεταβείτε στην κονσόλα διακομιστή βάσης δεδομένων:
Παρέχουμε στον χρήστη του slave server τα απαραίτητα δικαιώματα:
ΧΟΡΗΓΗΣΤΕ ΑΝΑΠΑΡΑΓΩΓΗ SLAVE ON *.* TO "slave_user"@"%" ΠΟΥ ΑΝΑΓΝΩΡΙΖΕΤΑΙ ΑΠΟ "123";
Κλείδωμα όλων των πινάκων στη βάση δεδομένων
ΞΕΦΛΕΞΕΤΕ ΤΡΑΠΕΖΙΑ ΜΕ ΚΛΕΙΔΑΡΙΑ ΔΙΑΒΑΣΗΣ.
Ελέγξτε την κατάσταση του κύριου διακομιστή:
+——————+———-+—————+——————+
| αρχείο | θέση | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+—————+——————+
| mysql-bin.000001 | 327 | db1 | |
+——————+———-+—————+——————+
1 σειρά στο σετ (0,00 δευτ.)
3. Δημιουργήστε μια ένδειξη βάσης δεδομένων στο διακομιστή
Δημιουργήστε μια ένδειξη απόδειξης βάσης δεδομένων:
mysqldump -u ρίζα -p db1 > db1.sql
Ξεκλείδωμα πινάκων στην κονσόλα mysql:
4. Μεταφέρετε την ένδειξη δεδομένων βάσης δεδομένων στον διακομιστή Slave
scp db1.sql [email προστατευμένο]:/Σπίτι
Εκτελούμε περαιτέρω ενέργειες στον διακομιστή Slave
5. Δημιουργία βάσης δεδομένων
Φόρτωση της χωματερής:
mysql -u root -p db1< db1.sql
6. Πραγματοποίηση αλλαγών στο my.cnf
mcedit /etc/mysql/my.cnf
Εκχωρήστε ένα αναγνωριστικό αυξάνοντας την τιμή που έχει οριστεί στον κύριο διακομιστή
Αναγνωριστικό διακομιστή = 2
Ορίστε τη διαδρομή προς το αρχείο καταγραφής ρελέ
relay-log = /var/log/mysql/mysql-relay-bin.log
και τη διαδρομή κάδου προς το αρχείο καταγραφής στον κύριο διακομιστή
log_bin = /var/log/mysql/mysql-bin.log
Προσδιορίστε τη βάση
binlog_do_db = db1
Επανεκκίνηση της υπηρεσίας
/etc/init.d/mysql επανεκκίνηση
7. Ρυθμίστε τη σύνδεση με τον κύριο διακομιστή
CHANGE MASTER TO MASTER_HOST="192.168.0.1", MASTER_USER="slave_user", MASTER_PASSWORD="123", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 327;
Ξεκινάμε την αναπαραγωγή στον slave server:
Μπορείτε να ελέγξετε τη λειτουργία της αναπαραγωγής στο Slave κάνοντας ερώτημα:
****************************** 1η σειρά ****************** **********
Slave_IO_State: Αναμονή για αποστολή συμβάντος από τον κύριο
Master_Host: 192.168.0.1
master_user: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 107
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Ναι
Slave_SQL_Running: Ναι
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 555
Μέχρι_Κατάσταση: Κανένα
Μέχρι_αρχείο_καταγραφής:
Μέχρι_Log_Pos: 0
Master_SSL_Allowed: Όχι
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: Όχι
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 σειρά στο σετ (0,00 δευτ.)
Δεδομένου ότι δεν παρουσιάστηκαν σφάλματα, μπορούμε να συμπεράνουμε ότι η αναπαραγωγή έχει ρυθμιστεί σωστά.
Είναι ένα καλό εργαλείο κλιμάκωσης, αλλά ως κύριο μειονέκτημα έχει τον αποσυγχρονισμό της αντιγραφής δεδομένων και τις καθυστερήσεις, που μπορεί να είναι κρίσιμες.
Μπορούν να αποφευχθούν εντελώς χρησιμοποιώντας μια πιο σύγχρονη λύση. Είναι εύκολο στη ρύθμιση, αξιόπιστο και εξαλείφει την ανάγκη μη αυτόματης αντιγραφής απορριμμάτων βάσης δεδομένων.
Η αναπαραγωγή είναι ένας μηχανισμός για τον συγχρονισμό των περιεχομένων πολλών αντιγράφων ενός αντικειμένου. Αυτή η διαδικασία αναφέρεται στην αντιγραφή δεδομένων από μια πηγή σε πολλές άλλες και αντίστροφα.
Ονομασίες:
- master - ο κύριος διακομιστής του οποίου τα δεδομένα πρέπει να αντιγραφούν.
- replica - ένας επισκευασμένος διακομιστής που αποθηκεύει ένα αντίγραφο των δεδομένων του κύριου
Για να ρυθμίσετε την αναπαραγωγή στη MySQL, πρέπει να ακολουθήσετε την ακολουθία ενεργειών που περιγράφονται παρακάτω, αλλά αυτό δεν είναι δόγμα και οι παράμετροι ενδέχεται να αλλάξουν ανάλογα με τις περιστάσεις.
Στον κύριο διακομιστή, επεξεργαστείτε το αρχείο my.cnf, προσθέστε τις ακόλουθες γραμμές στην ενότητα mysqld:
server-id=log-bin=mysql-bin log-bin-index=mysql-bin.index log-error=mysql-bin.err relay-log=relay-bin relay-log-info-file=relay-bin. πληροφορίες relay-log-index = relay-bin.index expire_logs_days=7 binlog-do-db =
- - Μοναδικό αναγνωριστικό διακομιστή MySQL, αριθμός στην περιοχή 2 (0-31)
- - το όνομα της βάσης δεδομένων, πληροφορίες για το οποίο θα εγγραφούν στο δυαδικό αρχείο καταγραφής, εάν υπάρχουν πολλές βάσεις δεδομένων, τότε η καθεμία απαιτεί ξεχωριστή γραμμή με την παράμετρο binlog_do_db
Στο slave, επεξεργαστείτε το αρχείο my.cnf, προσθέστε τις ακόλουθες γραμμές στην ενότητα mysqld:
server-id=master-host=master master-user=replication master-password=password master-port=3306 relay-log=relay-bin relay-log-info-file=relay-log.info relay-log-index= relay-log.index replicate-do-db =
Στον κύριο διακομιστή, προσθέστε έναν χρήστη αναπαραγωγής με δικαιώματα αναπαραγωγής δεδομένων:
ΧΟΡΗΓΗΣΤΕ ΑΝΑΠΑΡΑΓΩΓΗ ΣΚΛΑΒΟΥ ΣΕ *.* ΣΕ "αντιγραφή"@"αντίγραφο" ΑΝΑΓΝΩΡΙΣΜΕΝΟ ΜΕ "κωδικό πρόσβασης"
Ας αποκλείσουμε τις αναπαραγόμενες βάσεις δεδομένων στον κύριο διακομιστή από το να αλλάζουν δεδομένα, μέσω προγραμματισμού ή χρησιμοποιώντας τη λειτουργία MySQL:
[email προστατευμένο]> ΞΕΦΛΕΨΤΕ ΤΡΑΠΕΖΙΑ ΜΕ ΚΛΕΙΔΑΡΙΑ ΑΝΑΓΝΩΣΗΣ. [email προστατευμένο]> SET GLOBAL read_only = ON;
Η εντολή για ξεκλείδωμα είναι:
[email προστατευμένο]> SET GLOBAL read_only = OFF.
Ας δημιουργήσουμε αντίγραφα ασφαλείας όλων των βάσεων δεδομένων στον κύριο διακομιστή (ή εκείνων που χρειαζόμαστε):
[email προστατευμένο]# tar -czf mysqldir.tar.gz /var/lib/mysql/
ή χρησιμοποιώντας το βοηθητικό πρόγραμμα mysqldump:
[email προστατευμένο]# mysqldump -u root -p --lock-all-tables > dbdump.sql
Ας σταματήσουμε και τους δύο διακομιστές (σε ορισμένες περιπτώσεις, μπορείτε να το κάνετε χωρίς αυτόν):
[email προστατευμένο]# mysqlamdin -u root -p τερματισμός λειτουργίας [email προστατευμένο]# mysqlamdin -u root -p τερματισμός λειτουργίας
Ας επαναφέρουμε τις αναπαραγόμενες βάσεις δεδομένων στον εξαρτημένο διακομιστή αντιγράφοντας τον κατάλογο. Πριν ξεκινήσετε την αναπαραγωγή, οι βάσεις δεδομένων πρέπει να είναι ίδιες:
[email προστατευμένο]# cd /var/lib/mysql [email προστατευμένο]# tar -xzf mysqldir.tar.gz
ή λειτουργικότητα mysql, τότε δεν χρειαζόταν να σταματήσει η mysql στον slave διακομιστή:
[email προστατευμένο]# mysql -u root -p< dbdump.sql
Ας ξεκινήσουμε τη mysql στον κύριο διακομιστή (και στη συνέχεια στον slave, εάν χρειάζεται):
[email προστατευμένο]# /etc/init.d/mysql start [email προστατευμένο]# /etc/init.d/mysql start
Ας ελέγξουμε τη δουλειά των διακομιστών κύριου και υποτελούς:
[email προστατευμένο]> έναρξη σκλάβος? [email προστατευμένο]> ΕΜΦΑΝΙΣΗ ΚΑΤΑΣΤΑΣΗΣ ΣΚΛΑΒΟΥ\G [email προστατευμένο]> ΕΜΦΑΝΙΣΗ ΚΑΤΑΣΤΑΣΗΣ ΚΥΡΙΟΥ\G
Στον υποτελή διακομιστή, ελέγξτε τα αρχεία καταγραφής στο αρχείο master.info, θα πρέπει να περιέχουν αιτήματα για αλλαγή δεδομένων στη βάση δεδομένων. Επομένως, αυτό το δυαδικό αρχείο πρέπει πρώτα να μετατραπεί σε μορφή κειμένου:
[email προστατευμένο]# mysqlbinlog master.info > master_info.sql
Εάν παρουσιαστούν σφάλματα, μπορείτε να χρησιμοποιήσετε τις εντολές:
[email προστατευμένο]> stop slave? [email προστατευμένο]> RESET SLAVE [email προστατευμένο]> RESET MASTER.
και επαναλάβετε όλες τις ενέργειες ξεκινώντας από το κλείδωμα της βάσης δεδομένων.
Για να προσθέσετε διακομιστές αναπαραγωγής, μπορείτε να χρησιμοποιήσετε τη σύνταξη:
[email προστατευμένο]> ΕΜΦΑΝΙΣΗ ΚΑΤΑΣΤΑΣΗΣ ΣΚΛΑΒΟΥ\G [email προστατευμένο]> ΕΜΦΑΝΙΣΗ ΚΑΤΑΣΤΑΣΗΣ ΚΥΡΙΟΥ\G [email προστατευμένο]> CHANGE MASTER TO MASTER_HOST = "master", MASTER_USER ="replication ", MASTER_PASSWORD = "password", MASTER_LOG_FILE ="mysql-bin.000004 ", MASTER_LOG_POS = 155; [email προστατευμένο]> START SLAVE?
Οι πληροφορίες από τις καταστάσεις θα δείχνουν τη θέση και το όνομα του τρέχοντος αρχείου καταγραφής.
Στην περίπτωση της ασύγχρονης αναπαραγωγής, η ενημέρωση ενός αντιγράφου διαδίδεται σε άλλα κάποια στιγμή αργότερα, και όχι στην ίδια συναλλαγή. Έτσι, η ασύγχρονη αναπαραγωγή εισάγει μια καθυστέρηση ή ένα χρονικό όριο, κατά το οποίο τα μεμονωμένα αντίγραφα μπορεί να μην είναι ουσιαστικά πανομοιότυπα. Αλλά αυτός ο τύπος αναπαραγωγής έχει επίσης θετικές πτυχές: ο κύριος διακομιστής δεν χρειάζεται να ανησυχεί για το συγχρονισμό δεδομένων, μπορείτε να κλειδώσετε τη βάση δεδομένων (για παράδειγμα, για να δημιουργήσετε ένα αντίγραφο ασφαλείας) σε μια εξαρτημένη μηχανή, χωρίς προβλήματα για τους χρήστες.
Κατάλογος πηγών που χρησιμοποιήθηκαν
- Habrahabr.ru - Βασικά στοιχεία αναπαραγωγής στη MySQL (http://habrahabr.ru/blogs/mysql/56702/)
- Wikipedia (http://ru.wikipedia.org/wiki/Replication_(computer_engineering))
Όταν χρησιμοποιείτε οποιοδήποτε υλικό από τον ιστότοπο, εν όλω ή εν μέρει, πρέπει να αναφέρετε ρητά ως πηγή έναν σύνδεσμο προς.