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

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

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

• Καταγραφή σφαλμάτων (καταγραφή σφαλμάτων): καταγράφει τις διαδικασίες εκκίνησης, εκτέλεσης και τερματισμού λειτουργίας της MySQL.
• Δυαδικό αρχείο καταγραφής (binarylog, binlog): καταγράφει κυρίως εντολές SQL που αλλάζουν δεδομένα βάσης δεδομένων.
• Γενικό αρχείο καταγραφής ερωτημάτων: Όλες οι εγγραφές SQL που αποστέλλονται στον διακομιστή MySQL από τον πελάτη που έχει δημιουργήσει μια σύνδεση Επειδή η ποσότητα της SQL είναι σχετικά μεγάλη, δεν είναι ενεργοποιημένη από προεπιλογή και δεν συνιστάται.
• Αρχείο καταγραφής αργού ερωτήματος (sow querylog): Ο χρόνος εκτέλεσης του ερωτήματος υπερβαίνει τα long_query_time δευτερόλεπτα, που χρησιμοποιείται κατά την επίλυση προβλημάτων αργού ερωτήματος SQL.
• Αρχείο καταγραφής συναλλαγών (redo log και undo log): το αρχείο καταγραφής επανάληψης είναι ένα αρχείο καταγραφής επανάληψης και το αρχείο καταγραφής αναίρεσης είναι ένα αρχείο καταγραφής επαναφοράς.
• Ημερολόγιο αναμετάδοσης: Το αρχείο καταγραφής αναμετάδοσης είναι ένα αρχείο καταγραφής που δημιουργείται κατά τη διαδικασία αναπαραγωγής Είναι παρόμοιο με το δυαδικό αρχείο καταγραφής από πολλές απόψεις. Ωστόσο, το αρχείο καταγραφής αναμετάδοσης στοχεύει στη βάση δεδομένων υποτελών στην αναπαραγωγή master-slave.
• Αρχείο καταγραφής DDL (μεταδεδομένα): Λειτουργίες μεταδεδομένων που εκτελούνται από δηλώσεις DDL

Το δυαδικό αρχείο καταγραφής (binlog) και το αρχείο καταγραφής συναλλαγών (redo log και undo log) είναι πιο σημαντικά και απαιτούν την εστίασή μας.

1. Αργό αρχείο καταγραφής ερωτημάτων

Το αργό αρχείο καταγραφής ερωτημάτων καταγράφει όλες τις δηλώσεις ερωτήματος των οποίων ο χρόνος εκτέλεσης υπερβαίνει το long_query_time (η προεπιλογή είναι 10 δευτ., συνήθως ορίζεται σε 1 δευτ. Χρησιμοποιείται συχνά κατά την επίλυση προβλήματος αργού ερωτήματος SQL (ο χρόνος εκτέλεσης της SQL είναι πολύ μεγάλος).
Η εύρεση αργής SQL είναι το πρώτο βήμα για τη βελτιστοποίηση της απόδοσης των εντολών SQL Στη συνέχεια, χρησιμοποιήστε την εντολή EXPLAIN για να αναλύσετε την αργή SQL και να λάβετε πληροφορίες σχετικά με το σχέδιο εκτέλεσης.
Μπορείτε να χρησιμοποιήσετε τις μεταβλητές εμφάνισης, όπως η εντολή "slow_query_log" για να ελέγξετε εάν το αργό αρχείο καταγραφής ερωτημάτων είναι απενεργοποιημένο από προεπιλογή.

Μπορεί να ενεργοποιηθεί με SET GLOBAL slow_query_log=ON

Η παράμετρος long_query_time καθορίζει πόσο χρόνο χρειάζεται ένα ερώτημα για να μπορεί να οριστεί ως αργό ερώτημα.

Μπορεί επίσης να τροποποιηθεί: ορίστε καθολικό long_query_time = 12

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

[MySQL] mysqldumpslow εργαλείο--συνοψίζοντας αργά αρχεία καταγραφής ερωτημάτων-CSDN Blog

1.1 Πώς να ρωτήσετε τον τρέχοντα αριθμό αργών δηλώσεων ερωτήματος;

Υπάρχει μια μεταβλητή στη MySQL που καταγράφει τον τρέχοντα αριθμό αργών δηλώσεων ερωτήματος
w_queries%';

1.2 Πώς να βελτιστοποιήσετε αργά ερωτήματα

Η MySQL μας παρέχειΕΞΗΓΩεντολή για τη λήψη πληροφοριών σχετικά με το σχέδιο εκτέλεσης.
Το σχέδιο εκτέλεσης αναφέρεται στη συγκεκριμένη μέθοδο εκτέλεσης μιας δήλωσης SQL αφού βελτιστοποιηθεί από το εργαλείο βελτιστοποίησης ερωτημάτων MySQL. Τα σχέδια εκτέλεσης χρησιμοποιούνται συνήθως σε σενάρια όπως η ανάλυση και η βελτιστοποίηση απόδοσης SQL. Μέσω των αποτελεσμάτων του EXPLAIN, μπορείτε να μάθετε πληροφορίες όπως η ακολουθία ερωτημάτων του πίνακα δεδομένων, ο τύπος λειτουργίας της λειτουργίας ερωτήματος δεδομένων, ποια ευρετήρια μπορούν να χτυπηθούν, ποια ευρετήρια θα χτυπηθούν πραγματικά, πόσες σειρές εγγραφών σε κάθε δεδομένα ερωτήματα για τον πίνακα και άλλες πληροφορίες. Συγκεκριμένα, μπορούμε να βελτιστοποιήσουμε την SQL μέσω ορισμένων κοινών μεθόδων παρακάτω:

1. Αποφύγετε τη χρήση του SELECT *
SELECT * καταναλώνει περισσότερη CPU.
ΕΠΙΛΟΓΗ *Τα άχρηστα πεδία αυξάνουν την κατανάλωση πόρων εύρους ζώνης δικτύου και τον χρόνο μετάδοσης δεδομένων, ειδικά τα μεγάλα πεδία (όπως το varchar,
blob, κείμενο).
Το SELECT * δεν μπορεί να χρησιμοποιήσει το εργαλείο βελτιστοποίησης MySQL για να καλύψει τη βελτιστοποίηση ευρετηρίου (η στρατηγική "κάλυψης ευρετηρίου" που βασίζεται στο βελτιστοποιητή MySQL είναι εξαιρετικά γρήγορη και αποτελεσματική και είναι μια μέθοδος βελτιστοποίησης ερωτημάτων που συνιστάται ιδιαίτερα στον κλάδο)
SELECT Η <λίστα πεδίων> μπορεί να μειώσει τον αντίκτυπο των αλλαγών στη δομή του πίνακα.

2. Βελτιστοποίηση σελιδοποίησης

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

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

Πώς να βελτιστοποιήσετε Μπορείτε να τροποποιήσετε την παραπάνω δήλωση SQL σε ένα δευτερεύον ερώτημα.

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

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

3. Κάνετε λιγότερες ενώσεις

Εγχειρίδιο ανάπτυξης Alibaba:

Μπορείτε να διαβάσετε τη συζήτηση στο Zhihu:

https://www.zhihu.com/question/68258877https://www.zhihu.com/question/682588774. Συνιστάται να μην χρησιμοποιείτε ξένα κλειδιά και καταρράκτες

Εγχειρίδιο Alibaba Java Development:

5. Επιλέξτε τον κατάλληλο τύπο πεδίου

6. Προσπαθήστε να χρησιμοποιήσετε UNION ALL αντί για UNION

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

7. Λειτουργίες παρτίδας

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

8. Χρησιμοποιήστε σωστά τα ευρετήρια

Υπάρχει πολύ περιεχόμενο σε αυτή την ενότητα, το οποίο θα παρουσιαστεί αργότερα σε ξεχωριστό ιστολόγιο.

2. δυαδικό αρχείο καταγραφής binlog

binlog (το δυαδικό αρχείο καταγραφής είναι ένα δυαδικό αρχείο καταγραφής) καταγράφει κυρίως όλες τις λειτουργίες που έχουν αλλάξει στη βάση δεδομένων MSQL (όλες οι δηλώσεις DDL και DML που εκτελούνται από τη βάση δεδομένων), συμπεριλαμβανομένων των αλλαγών στη δομή του πίνακα (CREATE, ALTER, DROP TABLE.), δεδομένων πίνακα τροποποιήσεις ( INSERT.UPDATE, DELETE..), αλλά δεν περιλαμβάνει SELECT, SHOW και άλλες λειτουργίες που δεν προκαλούν αλλαγές στη βάση δεδομένων.

Μπορείτε να χρησιμοποιήσετε την εντολή show binary logs για να προβάλετε μια λίστα με όλα τα δυαδικά αρχεία καταγραφής:

2.1 Μορφή Binlog

Υπάρχουν 3 τύποι μεθόδων δυαδικής εγγραφής:

• Λειτουργία δήλωσης: Κάθε δήλωση SQL που τροποποιεί δεδομένα θα καταγράφεται στο binlog, όπως εισαγωγές, ενημερώσεις και διαγραφές.·
• Λειτουργία γραμμής (συνιστάται): Τα συγκεκριμένα συμβάντα αλλαγής κάθε σειράς θα καταγράφονται στο binlog. ·
• Μικτή λειτουργία: ένας συνδυασμός λειτουργίας δήλωσης και λειτουργίας γραμμής. Η λειτουργία δήλωσης χρησιμοποιείται από προεπιλογή και μεταβαίνει αυτόματα στη λειτουργία γραμμής σε μερικά ειδικά σενάρια.

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

Πριν από την MySQL 5.1.5, η μορφή του binlog ήταν μόνο STATEMENT 5.1.5. Πριν από την MySQL 5.7.7, η λειτουργία δήλωσης χρησιμοποιήθηκε από προεπιλογή. Το MySQL5.7.7 χρησιμοποιεί τη λειτουργία γραμμής από προεπιλογή.

Μπορείτε να χρησιμοποιήσετε μεταβλητές εμφάνισης όπως "%binlog format%" για να δείτε τη μορφή που χρησιμοποιείται από το binlog

2.2 Ο ρόλος του binlog

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

Η αρχή της αναπαραγωγής master-slave φαίνεται στο παρακάτω σχήμα:

1. Η κύρια βιβλιοθήκη εγγράφει τις αλλαγές στα δεδομένα στη βάση δεδομένων σε binlog
2. Συνδέστε τη βοηθητική βιβλιοθήκη με την κύρια βιβλιοθήκη
3. Η υποτελής βιβλιοθήκη θα δημιουργήσει ένα νήμα I0 για να ζητήσει το ενημερωμένο binlog από την κύρια βιβλιοθήκη.
4. Η κύρια βιβλιοθήκη θα δημιουργήσει ένα νήμα dump binlog για να στείλει το binlog και το νήμα I/0 στη slave βιβλιοθήκη είναι υπεύθυνο για τη λήψη 5. Το νήμα I/0 της slave βιβλιοθήκης θα γράψει το νήμα binlog στο ρελέ. κούτσουρο.
6. Διαβάστε το αρχείο καταγραφής αναμετάδοσης από το νήμα SQL της βιβλιοθήκης και συγχρονίστε τα δεδομένα τοπικά (δηλαδή, εκτελέστε ξανά την SQL)

2.3 Πώς να επιλέξετε το χρονοδιάγραμμα για το flushing binlog;

Για τη μηχανή αποθήκευσης InnoDB, κατά την εκτέλεση μιας συναλλαγής, το αρχείο καταγραφής θα εγγραφεί πρώτα στην binlogcache Μόνο όταν υποβληθεί η συναλλαγή, το αρχείο καταγραφής binlogcache θα παραμείνει στο αρχείο binlogcache. Η εγγραφή στη μνήμη είναι πιο γρήγορη και αυτό γίνεται επίσης για λόγους αποτελεσματικότητας.

Επειδή το binlog μιας συναλλαγής δεν μπορεί να διαχωριστεί, ανεξάρτητα από το πόσο μεγάλη είναι η συναλλαγή, πρέπει να γραφτεί μία φορά, επομένως το σύστημα θα εκχωρήσει ένα μπλοκ μνήμης σε κάθε νήμα ως κρυφή μνήμη binlog. Μπορούμε να ελέγξουμε το μέγεθος binlogcache ενός μεμονωμένου νήματος μέσω της παραμέτρου binlog_cache_size Εάν το περιεχόμενο αποθήκευσης υπερβαίνει αυτήν την παράμετρο, πρέπει να αποθηκευτεί προσωρινά στο δίσκο (swap).

Λοιπόν, πότε το binlog ξεπλένεται στο δίσκο Μπορείτε να ελέγξετε τον χρονισμό έκπλυσης biglog μέσω της παραμέτρου sync_binlog Το εύρος τιμών είναι 0-N και η προεπιλογή είναι 0:
·0: Καμία υποχρεωτική απαίτηση, το σύστημα θα αποφασίσει πότε θα γράψει στο δίσκο.
·1: Κάθε φορά που υποβάλλεται μια συναλλαγή, το binlog πρέπει να γράφεται στο δίσκο:
·N: Το Binlog θα εγγράφεται στο δίσκο κάθε N συναλλαγές.Κίνδυνος απώλειας

Πριν από το MySQL5.7, η προεπιλεγμένη τιμή του sync_binlog ήταν 0. Μετά το MySQL5.7, η προεπιλεγμένη τιμή του sync_binlog είναι 1. Γενικά, δεν συνιστάται να ορίσετε την τιμή του sync_binlog σε 0. Εάν οι απαιτήσεις απόδοσης είναι σχετικά υψηλές ή παρουσιαστεί συμφόρηση IO του δίσκου, η τιμή του sync_binlog μπορεί να αυξηθεί κατάλληλα, ωστόσο, αυτό θα αυξήσει τον κίνδυνο απώλειας δεδομένων.

2.4 Υπό ποιες συνθήκες θα αναδημιουργηθεί το binlog;

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

• Ο διακομιστής MySQL σταματά ή επανεκκινεί
• Αφού χρησιμοποιήσετε την εντολή flush logs
• Αφού το μέγεθος του αρχείου binlog υπερβεί το όριο της μεταβλητής μέγιστου μεγέθους binlog.

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

Γνωρίζουμε ότι η μηχανή αποθήκευσης InnoD8 διαχειρίζεται τον χώρο αποθήκευσης σε μονάδες σελίδων Τα δεδομένα που εισάγουμε στη MySQL υπάρχουν τελικά στη σελίδα. Προκειμένου να μειωθεί η επιβάρυνση του δίσκου IO, υπάρχει επίσης μια περιοχή που ονομάζεται Buffer Pool, η οποία υπάρχει στη μνήμη. Όταν η σελίδα που αντιστοιχεί στα δεδομένα μας δεν υπάρχει στο Buffer Pool, το MSQL θα αποθηκεύσει πρώτα τη σελίδα στο δίσκο στο Buffer Pool, έτσι ώστε αργότερα να λειτουργήσουμε απευθείας τη σελίδα στο Buffer Pool, κάτι που βελτιώνει σημαντικά την απόδοση ανάγνωσης και εγγραφής .

Μετά τη δέσμευση μιας συναλλαγής, οι τροποποιήσεις μας στην αντίστοιχη σελίδα στο Buffer Pool ενδέχεται να μην παραμείνουν στο δίσκο. Αυτή τη στιγμή, εάν η MySQL διακοπεί ξαφνικά, θα εξαφανιστούν άμεσα οι αλλαγές σε αυτήν τη συναλλαγή;
Προφανώς όχι, αν ναι, προφανώς θα παραβίαζε τη διάρκεια της συναλλαγής.

Η μηχανή MySQLInnoDB χρησιμοποιεί το αρχείο καταγραφής επανάληψης για να διασφαλίσει την ανθεκτικότητα των συναλλαγών. Το κύριο πράγμα που κάνει το redo log είναι να καταγράφει τις τροποποιήσεις της σελίδας, όπως πόσα byte έχουν τροποποιηθεί σε μια συγκεκριμένη μετατόπιση σε μια συγκεκριμένη σελίδα και ποιο είναι το συγκεκριμένο τροποποιημένο περιεχόμενο. Κάθε εγγραφή στο αρχείο καταγραφής επανάληψης περιέχει τον αριθμό χώρου πίνακα, τον αριθμό σελίδας δεδομένων, τη μετατόπιση, τα συγκεκριμένα τροποποιημένα δεδομένα και μπορεί ακόμη και να καταγράφει το μήκος των τροποποιημένων δεδομένων (ανάλογα με τον τύπο του αρχείου καταγραφής επανάληψης).
Όταν ολοκληρωθεί η συναλλαγή, θα ξεπλύνουμε το αρχείο καταγραφής επανάληψης στο δίσκο σύμφωνα με τη στρατηγική έκπλυσης. Με αυτόν τον τρόπο, ακόμη και αν η MySQL διακοπεί, τα δεδομένα που απέτυχαν να εγγραφούν στο δίσκο μπορούν να ανακτηθούν μετά την επανεκκίνηση, διασφαλίζοντας έτσι την ανθεκτικότητα. της συναλλαγής. Με άλλα λόγια, το αρχείο καταγραφής επανάληψης δίνει δυνατότητες ανάκτησης σφαλμάτων MySQL.

1. Εξασφάλιση ανθεκτικότητας δεδομένων (Ανθεκτικότητα)

Το Redo Log καταγράφει όλες τις λειτουργίες τροποποίησης στη βάση δεδομένων. Όταν η βάση δεδομένων εκτελεί λειτουργίες εγγραφής (ΕΙΣΑΓΩΓΗ, ΕΝΗΜΕΡΩΣΗ, ΔΙΑΓΡΑΦΗ), αυτές οι λειτουργίες πρώτα θα καταγραφούν στο αρχείο καταγραφής επανάληψης και στη συνέχεια θα εφαρμοστούν στο αρχείο δεδομένων. Με αυτόν τον τρόπο, ακόμη και αν το σύστημα αποτύχει πριν ολοκληρωθεί η εγγραφή της λειτουργίας τροποποίησης δεδομένων στο δίσκο, το Redo Log μπορεί να διασφαλίσει ότι τα δεδομένα δεν θα χαθούν. Κατά την ανάκτηση, η βάση δεδομένων θα επαναλάβει αυτές τις ημιτελείς λειτουργίες τροποποίησης από το αρχείο καταγραφής επανάληψης για να διασφαλίσει τη συνοχή των δεδομένων.

2. Ανάκτηση δεδομένων (Ανάκτηση)

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

3. Βελτιώστε την απόδοση εγγραφής

Προκειμένου να βελτιωθεί η απόδοση των λειτουργιών εγγραφής, οι βάσεις δεδομένων χρησιμοποιούν συχνά μηχανισμούς προσωρινής αποθήκευσης (όπως πισίνες buffer) για να αποθηκεύουν προσωρινά τις λειτουργίες τροποποίησης στη μνήμη αντί να τις γράφουν αμέσως στο δίσκο. Η ύπαρξη του Redo Log καθιστά δυνατό αυτόν τον μηχανισμό αποθήκευσης στην κρυφή μνήμη, επειδή εφόσον διασφαλίζεται ότι το Redo Log διατηρείται, δεν υπάρχει κίνδυνος απώλειας δεδομένων ακόμα και αν τα δεδομένα στη μνήμη cache δεν έχουν γραφτεί στο δίσκο.

Κατά τη διεξαγωγή μιας συναλλαγής, το αρχείο καταγραφής επανάληψης στην προσωρινή μνήμη καταγραφής θα ξεπλυθεί στο δίσκο. Μπορείτε να χρησιμοποιήσετε το innodb_flush_log_at
δέσμευση ελέγχου παραμέτρων. Πρέπει να δώσουμε προσοχή στον ορισμό της σωστής πολιτικής έκπλυσης innodb_flush_log_at_trx_commit Ανάλογα με τη στρατηγική έκπλυσης που έχει ρυθμιστεί στη MySQL, ενδέχεται να υπάρχουν μικρά προβλήματα απώλειας δεδομένων μετά τη διακοπή λειτουργίας της MySQL.

innodb_flush_log_at_trx_commit Είναι μια σημαντική παράμετρος διαμόρφωσης στη μηχανή αποθήκευσης MySQL InnoDB Καθορίζει τις στρατηγικές ξεπλύματος (flush) και εγγραφής (εγγραφής) του αρχείου καταγραφής κατά την υποβολή μιας συναλλαγής, επηρεάζοντας έτσι τη διάρκεια και την απόδοση των δεδομένων. Έχει τρεις τιμές, δηλαδή 0, 1 και 2. Κάθε τιμή αντιπροσωπεύει μια διαφορετική στρατηγική βουρτσίσματος.

• innodb_flush_log_at_trx_commit = 0

  • περιγράφω : Όταν μια συναλλαγή δεσμεύεται, το αρχείο καταγραφής εγγράφεται στο buffer καταγραφής, αλλά όχι αμέσως στο δίσκο. Τα αρχεία καταγραφής εγγράφονται στο δίσκο κάθε δευτερόλεπτο και το buffer καταγραφής ξεπλένεται κάθε δευτερόλεπτο.
  • πλεονέκτημα: Υψηλότερη απόδοση επειδή μειώνονται οι λειτουργίες εισόδου/εξόδου του δίσκου.
  • έλλειψη: Όταν το σύστημα κολλάει, όλες οι συναλλαγές στο τελευταίο 1 δευτερόλεπτο ενδέχεται να χαθούν.
  • Εφαρμόσιμη σκηνή: Κατάλληλο για σενάρια εφαρμογών με απαιτήσεις υψηλών επιδόσεων και χαλαρές απαιτήσεις διατήρησης δεδομένων.

• innodb_flush_log_at_trx_commit = 1

  • περιγράφω : Κάθε φορά που δεσμεύεται μια συναλλαγή, το αρχείο καταγραφής γράφεται αμέσως στο δίσκο και το buffer καταγραφής ξεπλένεται αμέσως στο δίσκο. Αυτή είναι η πιο ασφαλής ρύθμιση και διασφαλίζει τη διάρκεια της συναλλαγής.
  • πλεονέκτημα: Η υψηλότερη ασφάλεια, η οποία διασφαλίζει ότι κάθε υποβληθείσα συναλλαγή διατηρείται και οι υποβληθείσες συναλλαγές δεν θα χαθούν ακόμη και αν το σύστημα διακοπεί.
  • έλλειψη: Χαμηλότερη απόδοση επειδή κάθε δέσμευση ενεργοποιεί μια λειτουργία εισόδου/εξόδου δίσκου.
  • Εφαρμόσιμη σκηνή: Κατάλληλο για σενάρια εφαρμογών που απαιτούν υψηλή επιμονή δεδομένων, όπως χρηματοοικονομικά συστήματα, ηλεκτρονικό εμπόριο κ.λπ.

• innodb_flush_log_at_trx_commit = 2

  • περιγράφω : Κάθε φορά που δεσμεύεται μια συναλλαγή, το αρχείο καταγραφής γράφεται στην προσωρινή μνήμη καταγραφής και εκπέμπεται αμέσως στο δίσκο, αλλά δεν εγγράφεται αμέσως στο αρχείο καταγραφής. Τα αρχεία καταγραφής εγγράφονται στο δίσκο μία φορά το δευτερόλεπτο.
  • πλεονέκτημα: Βελτιώνει την απόδοση σε κάποιο βαθμό, ενώ μειώνει τον όγκο των δεδομένων που μπορεί να χαθούν (οι συναλλαγές εντός 1 δευτερολέπτου χάνονται το πολύ).
  • έλλειψη: Όταν το σύστημα κολλάει, οι συναλλαγές εντός του τελευταίου 1 δευτερολέπτου ενδέχεται να χαθούν.
  • Εφαρμόσιμη σκηνή: Κατάλληλο για σενάρια εφαρμογών που έχουν συγκεκριμένες απαιτήσεις ισορροπίας σχετικά με την απόδοση και την αντοχή των δεδομένων.

Σύνοψη της στρατηγικής του πινέλου

• 0: Η καλύτερη απόδοση, αλλά ο υψηλότερος κίνδυνος, όλες οι συναλλαγές στο τελευταίο 1 δευτερόλεπτο μπορεί να χαθούν.
• 1: Το πιο ασφαλές, διασφαλίζοντας ότι κάθε δεσμευμένη συναλλαγή διατηρείται και η απόδοση είναι σχετικά χαμηλή.
• 2: Ένας συμβιβασμός μεταξύ απόδοσης και ασφάλειας.

4. Παρουσιάζεται απώλεια δεδομένων

1. Το αρχείο καταγραφής επανάληψης εγγράφεται στην προσωρινή μνήμη καταγραφής, αλλά δεν έχει γραφτεί ακόμη στη μνήμη cache της σελίδας Αυτή τη στιγμή, η βάση δεδομένων διακόπτεται και συμβαίνει απώλεια δεδομένων (αυτή η απώλεια δεδομένων μπορεί να προκύψει όταν η τιμή της πολιτικής flush innodb_flush log_at trx_commit είναι. 0);

2. Το αρχείο καταγραφής επανάληψης έχει γραφτεί στη μνήμη cache της σελίδας, αλλά δεν έχει εγγραφεί ακόμη στο δίσκο Το λειτουργικό σύστημα θα διακοπεί και ενδέχεται να προκύψει απώλεια δεδομένων (αυτή η απώλεια δεδομένων μπορεί να συμβεί όταν η τιμή της πολιτικής έκπλυσης innodb2 flush log_at trx_commit είναι. 2).

5. Ποια είναι η διαφορά μεταξύ binlog και redolog;

• Το Binlog χρησιμοποιείται κυρίως για την αποκατάσταση της βάσης δεδομένων, η οποία ανήκει στην ανάκτηση δεδομένων σε επίπεδο Master-Slave είναι το πιο κοινό σενάριο εφαρμογής του binlog που χρησιμοποιείται κυρίως για τη διασφάλιση της διάρκειας των συναλλαγών, η οποία ανήκει στην ανάκτηση δεδομένων σε επίπεδο συναλλαγής.
• Το Redolog είναι μοναδικό για τη μηχανή InnoDB και το binlog είναι κοινό σε όλες τις μηχανές αποθήκευσης, επειδή το binlog υλοποιείται από το επίπεδο διακομιστή της MySQL.
• Το Redolog είναι ένα φυσικό αρχείο καταγραφής, το οποίο καταγράφει κυρίως την τροποποίηση μιας συγκεκριμένης σελίδας. Το Binlog είναι ένα λογικό αρχείο καταγραφής, το οποίο καταγράφει κυρίως όλες τις δηλώσεις DDL και DML που εκτελούνται από τη βάση δεδομένων.
• Το Binlog γράφεται με προσάρτηση και δεν υπάρχει όριο στο μέγεθος. Η Redolog χρησιμοποιεί μια μέθοδο γραφής βρόχου για να γράψει, με σταθερό μέγεθος Όταν γράφει μέχρι το τέλος, θα επιστρέψει στην αρχή για να γράψει αρχεία καταγραφής σε έναν βρόχο.

4. αναίρεση αρχείου καταγραφής αναίρεσης αρχείου καταγραφής

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

Πώς το Undo Log διασφαλίζει την ατομικότητα των συναλλαγών

Η ατομικότητα μιας συναλλαγής σημαίνει ότι όλες οι λειτουργίες της συναλλαγής είτε εκτελούνται όλες είτε δεν εκτελούνται καμία. Το Undo Log διασφαλίζει την ατομικότητα των συναλλαγών μέσω των ακόλουθων μηχανισμών:

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

2. Συναλλαγή επαναφοράς Εάν η συναλλαγή αποτύχει για κάποιο λόγο (όπως σφάλμα ή ρητή επαναφορά), το σύστημα βάσης δεδομένων διαβάζει το αρχείο καταγραφής αναίρεσης και επαναφέρει τα δεδομένα στην κατάσταση πριν από την έναρξη της συναλλαγής σύμφωνα με την καταγεγραμμένη λειτουργία αναίρεσης. Με αυτόν τον τρόπο, μπορείτε να διασφαλίσετε ότι η αποτυχημένη συναλλαγή δεν έχει καμία επίδραση στη βάση δεδομένων, διασφαλίζοντας έτσι την ατομικότητα της συναλλαγής.

Παραθέτω, αναφορά:

Λεπτομερής επεξήγηση του διαχωρισμού ανάγνωσης-εγγραφής και της υποβάσης δεδομένων και του πίνακα JavaGuide