Κοινή χρήση τεχνολογίας

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

---

1. Υποδομή: Πώς εκτελείται μια δήλωση ερωτήματος SQL;

ΣΦΑΙΡΙΚΗ ΕΙΚΟΝΑ

Σε γενικές γραμμές, η MySQL μπορεί να χωριστεί σε δύο επίπεδα

• Επίπεδο διακομιστή
  Καλύπτει τις περισσότερες από τις βασικές λειτουργίες υπηρεσιών της MySQL
  • Συνδετήρας
  • Προσωρινή μνήμη ερωτήματος
  • Αναλυτής
  • βελτιστοποιητής
  • Ενεργοποιητής
  • Όλες οι ενσωματωμένες συναρτήσεις (όπως ημερομηνία, ώρα, μαθηματικές και κρυπτογραφικές συναρτήσεις κ.λπ.)
  • Δυνατότητες σε όλους τους κινητήρες αποθήκευσης
    • αποθηκευμένη διαδικασία
    • δώσει το έναυσμα για
    • θέα
    • ……
• στρώμα κινητήρα αποθήκευσης
  Αρχιτεκτονική Plug-in, υπεύθυνη για την αποθήκευση και την ανάκτηση δεδομένων
  • Innodb
  • MyISAM
  • Μνήμη

Συνδετήρας

mysql -h$ip -P$port -u$user -p
1

Το mysql στην εντολή σύνδεσης είναι ένα εργαλείο πελάτη που χρησιμοποιείται για τη δημιουργία σύνδεσης με τον διακομιστή.Μετά την ολοκλήρωση της κλασικής χειραψίας TCP, ο σύνδεσμος
Πρόκειται να ξεκινήσει ο έλεγχος ταυτότητας Αυτή τη στιγμή, το όνομα χρήστη και ο κωδικός πρόσβασης που εισαγάγατε θα χρησιμοποιηθούν.

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

Εάν ο υπολογιστής-πελάτης είναι ανενεργός για μεγάλο χρονικό διάστημα, ο σύνδεσμος θα τον αποσυνδέσει αυτόματα. Αυτός ο χρόνος ελέγχεται από την παράμετρο wait_timeout και η προεπιλεγμένη τιμή είναι 8 ώρες.

Εάν ο πελάτης στείλει ένα αίτημα ξανά μετά την αποσύνδεση της σύνδεσης, θα λάβει μια υπενθύμιση σφάλματος: Lost connection to MySQL server during query . Εάν θέλετε να συνεχίσετε αυτήν τη στιγμή, πρέπει να συνδεθείτε ξανά και στη συνέχεια να εκτελέσετε το αίτημα.

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

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

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

Πώς να λύσετε αυτό το πρόβλημα; Μπορείτε να εξετάσετε τις ακόλουθες δύο επιλογές.

• Αποσυνδέετε περιοδικά τις μακριές συνδέσεις . Αφού το χρησιμοποιήσετε για ένα χρονικό διάστημα ή αφού το πρόγραμμα καθορίσει ότι έχει εκτελεστεί ένα μεγάλο ερώτημα που καταλαμβάνει μνήμη, η σύνδεση αποσυνδέεται και, στη συνέχεια, απαιτείται το ερώτημα και στη συνέχεια επανασυνδέεται.
• Εάν χρησιμοποιείτε MySQL 5.7 ή νεότερη έκδοση, μπορείτε να την εκτελέσετε mysql_reset_connection για να αρχικοποιήσετε ξανά τους πόρους σύνδεσης. Αυτή η διαδικασία δεν απαιτεί επανασύνδεση και επαλήθευση άδειας, αλλά θα επαναφέρει τη σύνδεση στην κατάσταση που μόλις δημιουργήθηκε.

Προσωρινή μνήμη ερωτήματος

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

Εάν η δήλωση δεν βρίσκεται στη μνήμη cache του ερωτήματος, η φάση εκτέλεσης συνεχίζεται. Αφού ολοκληρωθεί η εκτέλεση, τα αποτελέσματα της εκτέλεσης θα αποθηκευτούν στην κρυφή μνήμη του ερωτήματος. Μπορείτε να δείτε ότι εάν το ερώτημα φτάσει στη μνήμη cache, η MySQL μπορεί να επιστρέψει απευθείας το αποτέλεσμα χωρίς να εκτελέσει επακόλουθες πολύπλοκες λειτουργίες, κάτι που είναι πολύ αποτελεσματικό.

Αλλά τις περισσότερες φορές θα το κάνωΣυνιστάται να μην χρησιμοποιείτε προσωρινή αποθήκευση ερωτημάτων ,Γιατί; Επειδή η προσωρινή αποθήκευση ερωτημάτων συχνά κάνει περισσότερο κακό παρά καλό.

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

Ευτυχώς, η MySQL παρέχει επίσης αυτή τη μέθοδο "χρήση κατ' απαίτηση". Μπορείτε να ορίσετε την παράμετρο query_cache_type σε DEMAND, έτσι ώστε η κρυφή μνήμη ερωτήματος να μην χρησιμοποιείται για τις προεπιλεγμένες προτάσεις SQL. Για δηλώσεις που είστε βέβαιοι ότι θέλετε να χρησιμοποιήσετε την κρυφή μνήμη ερωτήματος, μπορείτε να χρησιμοποιήσετε το SQL_CACHE για να το προσδιορίσετε ρητά, όπως η ακόλουθη πρόταση:

select SQL_CACHE * from T where ID=10；
1

πρέπει να γνωρίζετε ότι είναι,Η έκδοση MySQL 8.0 διαγράφει απευθείας ολόκληρη τη λειτουργία προσωρινής μνήμης ερωτήματος, πράγμα που σημαίνει ότι αυτή η λειτουργία δεν θα είναι πλέον διαθέσιμη από την έκδοση 8.0.

Αναλυτής

Εάν η κρυφή μνήμη ερωτήματος δεν χτυπηθεί, ξεκινά η πραγματική εκτέλεση της δήλωσης. Πρώτα, η MySQL πρέπει να γνωρίζει τι θέλετε να κάνετε, επομένως πρέπει να αναλύσει τη δήλωση SQL.

βελτιστοποιητής

Ενεργοποιητής

2. Σύστημα καταγραφής: Πώς εκτελείται μια δήλωση ενημέρωσης SQL;

επανάληψη καταγραφής

Δεν ξέρω αν θυμάστε ακόμα το άρθρο "Kong Yiji Ο διευθυντής του ξενοδοχείου έχει έναν ροζ πίνακα που χρησιμοποιείται ειδικά για την καταγραφή των πιστωτικών αρχείων των επισκεπτών". Αν δεν είναι πολλά άτομα που πληρώνουν με πίστωση, τότε μπορεί να γράψει το όνομα και τον λογαριασμό του πελάτη στον πίνακα. Αλλά αν υπάρχουν πάρα πολλά άτομα με πιστωτικούς λογαριασμούς, θα υπάρχουν πάντα στιγμές που ο πίνακας θαυμαστών δεν μπορεί να τους παρακολουθήσει.

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

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

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

Όλη αυτή η διαδικασία είναι δύσκολο να σκεφτεί κανείς. Αντίθετα, είναι πιο εύκολο να το γράψετε πρώτα στον ροζ πίνακα. Σκεφτείτε το, αν ο καταστηματάρχης δεν έχει τη βοήθεια του ροζ πίνακα, πρέπει να αναποδογυρίζει το καθολικό κάθε φορά που καταγράφει λογαριασμούς Δεν είναι αφόρητα χαμηλή η απόδοση;

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

Η όλη διαδικασία συνεργασίας μεταξύ του ροζ πίνακα και του καθολικού είναι στην πραγματικότητα αυτό που αναφέρεται συχνά στη MySQL. WAL τεχνολογία,WAL Το πλήρες όνομα είναιWrite-Ahead Logging, το βασικό σημείο είναιΠρώτα γράψτε το αρχείο καταγραφής και μετά γράψτε στο δίσκο, δηλαδή, γράψε πρώτα τον ροζ πίνακα και μετά γράψε το βιβλίο λογαριασμού όταν δεν είσαι απασχολημένος.

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

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

Ομοίως, το αρχείο καταγραφής επανάληψης του InnoDB έχει σταθερό μέγεθος. Για παράδειγμα, μπορεί να ρυθμιστεί ως ένα σύνολο 4 αρχείων, κάθε αρχείο έχει μέγεθος 1 GB. Στη συνέχεια, αυτός ο "ροζ πίνακας" μπορεί να καταγράψει συνολικά λειτουργίες 4 GB. Ξεκινήστε να γράφετε από την αρχή και μετά επιστρέψτε στην αρχή για να γράψετε σε βρόχο, όπως φαίνεται στην παρακάτω εικόνα.

Η εγγραφή pos είναι η θέση της τρέχουσας εγγραφής. Μετακινείται προς τα πίσω κατά την εγγραφή στο τέλος του αρχείου Νο. 0. Το σημείο ελέγχου είναι η τρέχουσα θέση που πρέπει να διαγραφεί και επίσης μετακινείται προς τα εμπρός και επαναλαμβάνεται πριν από τη διαγραφή της εγγραφής, η εγγραφή πρέπει να ενημερωθεί στο αρχείο δεδομένων.

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

Με το αρχείο καταγραφής επανάληψης, το InnoDB μπορεί να διασφαλίσει ότι ακόμη και αν η βάση δεδομένων επανεκκινηθεί ασυνήθιστα, οι εγγραφές που υποβλήθηκαν προηγουμένως δεν θα χαθούνcrash-safe。

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

binlog

Όπως αναφέραμε προηγουμένως, η MySQL στο σύνολό της έχει στην πραγματικότητα δύο μέρη: το ένα είναι το επίπεδο διακομιστή, το οποίο κάνει κυρίως πράγματα στο λειτουργικό επίπεδο της MySQL, το άλλο είναι το στρώμα κινητήρα, το οποίο είναι υπεύθυνο για συγκεκριμένα θέματα που σχετίζονται με την αποθήκευση.Ο ροζ πίνακας για τον οποίο μιλήσαμε παραπάνωΤο αρχείο καταγραφής επανάληψης είναι ένα αρχείο καταγραφής μοναδικό για τη μηχανή InnoDB,και Το επίπεδο διακομιστή έχει επίσης το δικό του αρχείο καταγραφής, που ονομάζεται binlog (αρχειοθέτηση)。

Νομίζω ότι θα ρωτήσετε, γιατί υπάρχουν δύο κούτσουρα;

Επειδή δεν υπήρχε κινητήρας InnoDB στη MySQL στην αρχή. Η μηχανή της δικής της MySQL είναι η MyISAM, αλλά το MyISAM δεν διαθέτει δυνατότητες ασφαλείας για σφάλματα και τα αρχεία καταγραφής binlog μπορούν να χρησιμοποιηθούν μόνο για αρχειοθέτηση. Το InnoDB εισήχθη στη MySQL με τη μορφή plug-in από άλλη εταιρεία Δεδομένου ότι το να βασίζεσαι μόνο στο binlog δεν έχει δυνατότητες ασφαλείας για σφάλματα, το InnoDB χρησιμοποιεί ένα άλλο σύστημα καταγραφής, δηλαδή το redo log, για να επιτύχει δυνατότητες ασφαλείας.

Αυτά τα δύο αρχεία καταγραφής έχουν τις ακόλουθες τρεις διαφορές.

1. Το αρχείο καταγραφής επανάληψης είναι μοναδικό για τη μηχανή InnoDB το binlog υλοποιείται από το επίπεδο διακομιστή της MySQL και μπορεί να χρησιμοποιηθεί από όλους τους κινητήρες.
2. Το αρχείο καταγραφής επανάληψης είναι ένα φυσικό αρχείο καταγραφής, καταγράφει "τι τροποποιήσεις έγιναν σε μια συγκεκριμένη σελίδα δεδομένων"·Το binlog είναι ένα λογικό αρχείο καταγραφής, αυτό που καταγράφεται είναι η αρχική λογική αυτής της δήλωσης, όπως "προσθήκη 1 στο πεδίο c της σειράς με ID=2".
3. Το αρχείο καταγραφής επανάληψης γράφεται σε βρόχο, ο χώρος θα εξαντληθεί.Το binlog μπορεί να γραφτεί επιπλέον . "Προσθήκη εγγραφής" σημαίνει ότι αφού το αρχείο binlog φτάσει σε ένα συγκεκριμένο μέγεθος, θα αλλάξει στο επόμενο και δεν θα αντικαταστήσει το προηγούμενο αρχείο καταγραφής.

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

1. Ο εκτελεστής αρχικά αναζητά τον κινητήρα για να πάρει το αναγνωριστικό γραμμής=2. Το ID είναι το πρωτεύον κλειδί και η μηχανή χρησιμοποιεί απευθείας την αναζήτηση δέντρου για να βρει αυτήν τη σειρά. Εάν η σελίδα δεδομένων όπου βρίσκεται η σειρά με ID=2 είναι ήδη στη μνήμη, θα επιστραφεί απευθείας στον εκτελεστή, διαφορετικά πρέπει να διαβαστεί στη μνήμη από το δίσκο και μετά να επιστραφεί.
2. Ο εκτελεστής λαμβάνει τα δεδομένα σειράς που δίνονται από τον κινητήρα, προσθέτει 1 σε αυτήν την τιμή, για παράδειγμα, ήταν N, αλλά τώρα είναι N+1, λαμβάνει μια νέα σειρά δεδομένων και, στη συνέχεια, καλεί τη διεπαφή του κινητήρα για να γράψει αυτό νέα σειρά δεδομένων.
3. Ο κινητήρας ενημερώνει αυτή τη νέα σειρά δεδομένων στη μνήμη και καταγράφει τη λειτουργία ενημέρωσης στο αρχείο καταγραφής επανάληψης αυτήν τη στιγμή επανάληψη καταγραφής σεπροετοιμάζω κατάσταση. Στη συνέχεια, ενημερώστε τον εκτελεστή ότι η εκτέλεση ολοκληρώθηκε και η συναλλαγή μπορεί να υποβληθεί ανά πάσα στιγμή.
4. Ο εκτελεστής δημιουργεί ένα binlog αυτής της λειτουργίας και βάζει binlog γραμμένο στο δίσκο。
5. Ο εκτελεστής καλεί τη διεπαφή συναλλαγής δέσμευσης του κινητήρα και ο κινητήρας γράφει το επανάληψη καταγραφής Αλλαγή για υποβολή (διαπράττω) κατάσταση, η ενημέρωση ολοκληρώθηκε.

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

διαδικασία εκτέλεσης δήλωσης ενημέρωσης

Ίσως έχετε παρατηρήσει ότι τα τρία τελευταία βήματα φαίνονται κάπως "κυκλικά".

δέσμευση δύο φάσεων

Γιατί είναι απαραίτητη η «υποβολή σε δύο φάσεις»;Αυτό γίνεται για να επιτρέπεται η διαφορά μεταξύ των δύο αρχείων καταγραφήςλογικά συνεπής . Για να εξηγήσουμε αυτό το πρόβλημα, πρέπει να ξεκινήσουμε με την ερώτηση στην αρχή του άρθρου: Πώς να επαναφέρετε τη βάση δεδομένων στην κατάσταση οποιουδήποτε δευτερολέπτου μέσα σε μισό μήνα;

Όπως είπαμε και προηγουμένως, το binlog θα καταγράφει όλες τις λογικές πράξεις και θα υιοθετεί τη μορφή της «εγγραφής παραρτήματος». Εάν το DBA σας υπόσχεται ότι μπορεί να αποκατασταθεί μέσα σε μισό μήνα, τότε το σύστημα δημιουργίας αντιγράφων ασφαλείας θα αποθηκεύσει σίγουρα όλα τα binlogs τον τελευταίο μισό μήνα και το σύστημα θα πραγματοποιεί τακτικά αντίγραφα ασφαλείας ολόκληρης της βάσης δεδομένων. Το "κανονικό" εδώ εξαρτάται από τη σημασία του συστήματος, το οποίο μπορεί να είναι μία φορά την ημέρα ή μία φορά την εβδομάδα.

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

• Πρώτα, βρείτε το πιο πρόσφατο πλήρες αντίγραφο ασφαλείας Εάν είστε τυχεροί, μπορεί να είναι ένα αντίγραφο ασφαλείας από χθες το βράδυ και επαναφέρετε από αυτό το αντίγραφο ασφαλείας στην προσωρινή βάση δεδομένων.
• Στη συνέχεια, ξεκινώντας από το χρονικό σημείο δημιουργίας αντιγράφων ασφαλείας, τα εφεδρικά binlog αφαιρούνται με τη σειρά και αναπαράγονται ξανά μέχρι την ώρα πριν από την κατά λάθος διαγραφή του πίνακα το μεσημέρι.
  Με αυτόν τον τρόπο, η προσωρινή βάση δεδομένων σας θα είναι ίδια με την ηλεκτρονική βάση δεδομένων πριν τη διαγράψετε κατά λάθος. Στη συνέχεια, μπορείτε να αφαιρέσετε τα δεδομένα του πίνακα από την προσωρινή βάση δεδομένων και να τα επαναφέρετε στην ηλεκτρονική βάση δεδομένων.

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

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

Χρησιμοποιήστε ακόμα την προηγούμενη δήλωση ενημέρωσης ως παράδειγμα. Ας υποθέσουμε ότι η τιμή του πεδίου c στην τρέχουσα σειρά με ID=2 είναι 0, και ας υποθέσουμε ότι κατά την εκτέλεση της δήλωσης ενημέρωσης, παρουσιάζεται σφάλμα μετά την εγγραφή του πρώτου αρχείου καταγραφής αλλά πριν από την εγγραφή του δεύτερου αρχείου καταγραφής;

• Γράψτε πρώτα το αρχείο καταγραφής επανάληψης και μετά bilog.
  Ας υποθέσουμε ότι η διαδικασία MySQL επανεκκινείται ασυνήθιστα όταν γράφεται το αρχείο καταγραφής επανάληψης, αλλά πριν γραφτεί το binlog. Όπως είπαμε και προηγουμένως, μετά την εγγραφή του αρχείου καταγραφής επανάληψης, ακόμη και αν το σύστημα διακοπεί, τα δεδομένα μπορούν να αποκατασταθούν, επομένως η τιμή του c σε αυτήν τη γραμμή μετά την ανάκτηση είναι 1. Ωστόσο, δεδομένου ότι το binlog συνετρίβη πριν ολοκληρωθεί, αυτή η δήλωση δεν καταγράφηκε στο binlog αυτή τη στιγμή. Επομένως, όταν δημιουργηθεί αντίγραφο ασφαλείας του αρχείου καταγραφής αργότερα, αυτή η δήλωση δεν θα συμπεριληφθεί στο αποθηκευμένο binlog. Στη συνέχεια, θα διαπιστώσετε ότι εάν πρέπει να χρησιμοποιήσετε αυτό το binlog για να επαναφέρετε την προσωρινή βιβλιοθήκη, επειδή το binlog αυτής της δήλωσης έχει χαθεί, η προσωρινή βιβλιοθήκη δεν θα ενημερωθεί αυτή τη φορά. Η τιμή του c στην επαναφερθείσα σειρά είναι 0 ίδια με την αξία της αρχικής βιβλιοθήκης.
• Γράψτε πρώτα το binlog και μετά επαναλάβετε το αρχείο καταγραφής.
  Εάν υπάρξει σφάλμα μετά την εγγραφή του binlog, καθώς το αρχείο καταγραφής επανάληψης δεν έχει γραφτεί ακόμα, η συναλλαγή θα είναι άκυρη μετά την ανάκτηση σφαλμάτων, επομένως η τιμή του c σε αυτήν τη γραμμή είναι 0. Αλλά το αρχείο καταγραφής "Αλλαγή c από 0 σε 1" έχει καταγραφεί στο binlog. Επομένως, όταν το binlog χρησιμοποιείται για επαναφορά αργότερα, θα βγει μια ακόμη συναλλαγή Η τιμή του c στην επαναφερόμενη σειρά είναι 1, η οποία είναι διαφορετική από την τιμή στην αρχική βάση δεδομένων.
  Μπορεί να φανεί ότι εάν δεν χρησιμοποιείται η "δέσμευση δύο φάσεων", η κατάσταση της βάσης δεδομένων μπορεί να είναι ασυνεπής με την κατάσταση της βιβλιοθήκης που αποκαταστάθηκε χρησιμοποιώντας το αρχείο καταγραφής της.

Μπορείτε να πείτε, είναι αυτή η πιθανότητα πολύ μικρή. Δεν υπάρχουν περιπτώσεις όπου η προσωρινή βιβλιοθήκη πρέπει να αποκατασταθεί ανά πάσα στιγμή;

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

Με απλά λόγια, τόσο το αρχείο καταγραφής επανάληψης όσο και το binlog μπορούν να χρησιμοποιηθούν για να αναπαραστήσουν την κατάσταση δέσμευσης μιας συναλλαγής καιΗ υποβολή σε δύο φάσεις είναι να διατηρήσει τις δύο καταστάσεις λογικά συνεπείς.。