Δεν μπορείτε να κάνετε load balancing σε μια εγγραφή.
Πανομοιότυποι κόμβοι βάσης δεδομένων μοιάζουν με πολλαπλασιασμένη χωρητικότητα εγγραφών. Μοιράστε τις εγγραφές σας σε αυτούς και το cluster παράγει deadlocks. Ο σχεδιασμός που δουλεύει.
Σε αυτό το άρθρο 2 ενότητες
- Το διαισθητικό στήσιμο cluster: πανομοιότυποι κόμβοι, ένας load balancer, όλα σε round-robin. Μοιάζει με πολλαπλασιασμένη χωρητικότητα.
- Υπό εντελώς φυσιολογικό φορτίο παραδίδει σφάλματα deadlock σε συντάκτες στη μέση της δημοσίευσης, χωρίς κανένα locking bug πουθενά στον κώδικα. Δύο συντάκτες, δύο κόμβοι, μία καυτή γραμμή, και ο έλεγχος σύγκρουσης του cluster πετάει τον έναν πίσω.
- Η αντιδιαισθητική λύση: κάθε εγγραφή πηγαίνει σε έναν εκλεγμένο κόμβο, και μόνο οι αναγνώσεις μοιράζονται.
- Η ανατροπή που απαντά στο «μα δεν είναι πιο γρήγορη η κατανομή;»: ο όγκος εγγραφών σπάνια είναι ο περιορισμός. Η χωρητικότητα αναγνώσεων είναι αυτό που κλιμακώνεται, και τα σφάλματα εξαφανίζονται.
Αγοράσατε ένα cluster βάσης δεδομένων. Κανείς δεν αγοράζει πολλά από ένα πράγμα για να χρησιμοποιεί ένα, οπότε η διαμόρφωση του load balancer πρακτικά γράφεται μόνη της: round-robin τα πάντα σε κάθε κόμβο. Η πεποίθηση από κάτω είναι απλή: ένα μεμονωμένο query δεν θα γίνει πιο γρήγορο, αλλά πολλά θα γίνουν, μοιρασμένα στα μηχανήματα. Ακούγεται προφανώς σωστό. Είναι επίσης ο πιο συνηθισμένος τρόπος που βλέπουμε αυτή την κλάση cluster να χρησιμοποιείται λάθος.
Το bug που δεν είναι στον κώδικα
Υπό συνηθισμένο φορτίο, οι συντάκτες πατούν κατά διαστήματα αποθήκευση και παίρνουν πίσω ένα ακατέργαστο σφάλμα βάσης μέσα από το CMS: deadlock found. Είναι διακοπτόμενο και δύσκολο να αναπαραχθεί, και όσο κι αν διαβάσετε τον κώδικα της εφαρμογής δεν θα το βρείτε, γιατί το bug δεν είναι στον κώδικα.
Ο φόρτος που γίνεται το όπλο είναι συνηθισμένος. Ένα CMS ξαναγράφει μια χούφτα γραμμές διαμόρφωσης με καθολικά ονόματα σχεδόν σε κάθε ενέργεια. Ένα SEO plugin ξαναχτίζει το sitemap του σε κάθε αποθήκευση. Χρονοσφραγίδες login και μετρητές προβολών αγγίζουν όλα τις ίδιες καυτές γραμμές. Το round-robin σκορπίζει αυτές τις ανταγωνιστικές εγγραφές σε κάθε κόμβο. Κάθε κόμβος δέχεται τη δική του εγγραφή τοπικά, και μετά το βήμα certification του cluster πιάνει τη σύγκρουση τη στιγμή του commit και την πετάει πίσω σε έναν client που δεν έκανε τίποτα λάθος. Δύο συντάκτες, δύο κόμβοι, η ίδια γραμμή: σφάλμα 1213.
Ένα deadlock υπό φυσιολογικό φορτίο, σε cluster, χωρίς κανένα μοτίβο locking πουθενά στην εφαρμογή, είναι σύμπτωμα δρομολόγησης. Ο φόρτος δεν είναι λάθος. Η τοπολογία είναι.
Ένας writer για ασφάλεια, μοιράστε τις αναγνώσεις
Το να διοχετεύετε όλες τις εγγραφές σε έναν κόμβο σπαταλά τους άλλους; Όχι. Οι αναγνώσεις ισορροπούν ομοιόμορφα σε όλο το cluster και κάθε εγγραφή πηγαίνει στον έναν εκλεγμένο writer. Το ένστικτο του round-robin έχει δίκιο για τις αναγνώσεις και άδικο για τις εγγραφές· η δρομολόγηση με έναν writer κρατά το μισό που είναι σωστό και διαγράφει τα σφάλματα που παράγει το άλλο μισό. Αν το πρώτο σας ένστικτο σε ένα φορτωμένο cluster είναι να κλιμακώσετε προς τα πάνω, το αδελφό μάθημα είναι ότι η σωστή κίνηση είναι συχνά η αντίθετη (μικρύνετε, μη μεγαλώνετε).
1213
1
“Ένα cluster είναι multi-primary-capable και single-writer-safe. Αυτές είναι διαφορετικές προτάσεις.”
Αν τρέχετε cluster με ισορροπημένες αναγνώσεις, πηγαίνετε να μάθετε πού πραγματικά προσγειώνονται οι εγγραφές σας. Αν η απάντηση είναι «όπου τύχει να τις στείλει ο balancer», είστε ένα φορτωμένο απόγευμα μακριά από το να παράγετε deadlocks από την ίδια σας την επιτυχία. Ο έλεγχος κοστίζει μια ανάγνωση config. Η λύση είναι ένας κανόνας δρομολόγησης, όχι ένα rewrite.
Ευθείες απαντήσεις
Γιατί παίρνω σφάλματα deadlock (1213) στο Galera ή PXC cluster μου υπό φυσιολογικό φορτίο;+
Αν δεν υπάρχει locking bug στον κώδικά σας, ελέγξτε τη δρομολόγηση των εγγραφών. Εγγραφές σκορπισμένες σε κόμβους συγκρούονται σε καυτές γραμμές τη στιγμή του certification, και το cluster αναφέρει τη σύγκρουση ως deadlock σε έναν αθώο client. Δρομολογήστε κάθε εγγραφή σε έναν κόμβο και όλη η κλάση σφάλματος εξαφανίζεται.
Το να στέλνω όλες τις εγγραφές σε έναν κόμβο δεν σπαταλά το cluster μου;+
Οι εγγραφές σχεδόν ποτέ δεν είναι το bottleneck· οι αναγνώσεις είναι ο όγκος. Με δρομολόγηση ενός writer, οι αναγνώσεις ισορροπούν ακόμα σε κάθε κόμβο και η απόδοση εγγραφών δεν αλλάζει, γιατί στην πράξη ένας κόμβος έκανε πάντα όλη τη δουλειά εγγραφών.
Μπορεί ένα Galera cluster να κάνει multi-master εγγραφές;+
Είναι ικανό να δέχεται εγγραφές σε κάθε κόμβο, και είναι ασφαλές όταν δεν χρειάζεται να πιστοποιήσει ανταγωνιστικές εγγραφές σε καυτές γραμμές από πολλούς ταυτόχρονα. Multi-primary-capable, single-writer-safe. Χρησιμοποιήστε την ικανότητα για failover, όχι για κατανομή φορτίου.
Πώς κλιμακώνω τότε τις εγγραφές βάσης δεδομένων;+
Πρώτα αποδείξτε ότι το χρειάζεστε: μετρήστε τον όγκο εγγραφών απέναντι στο περιθώριο του ενός writer, που συνήθως είναι σφάλμα στρογγυλοποίησης δίπλα στις αναγνώσεις. Η γνήσια κλιμάκωση εγγραφών είναι έδαφος sharding ή ανασχεδιασμού φόρτου, όχι ρύθμιση load balancer.
Τι δρομολογεί αναγνώσεις και εγγραφές διαφορετικά;+
Ένα επίπεδο proxy που μιλά το πρωτόκολλο της βάσης μπορεί να τις χωρίσει: οι αναγνώσεις μοιράζονται, οι εγγραφές καρφώνονται στον εκλεγμένο writer, και το failover εκλέγει ξανά writer αυτόματα. Τρέχουμε αυτό το μοτίβο σε παραγωγή: ProxySQL μπροστά από Percona XtraDB Cluster.
Βλέπετε deadlocks που δεν μπορείτε να βρείτε στον κώδικά σας;
Στείλτε μας μόνο το σφάλμα και το πώς ισορροπείται το cluster σας. Αν είναι η τοπολογία, θα σας το δείξουμε, και θα το διορθώσουμε στη δρομολόγηση, όχι στην εφαρμογή σας.
Μιλήστε με έναν μηχανικόΦτάσατε στο τέλος.
Βάλτε την ανάγνωση σε εφαρμογή
Τι τρέχετε;
Πείτε μας για τον φόρτο εργασίας, την κίνηση και τις απαιτήσεις ανάκαμψης. Ξεκινήστε από το εργαλείο διαμόρφωσης server ή συζητήστε τις λεπτομέρειες με έναν μηχανικό.
Γραμμένο από τους μηχανικούς που χτίζουν και λειτουργούν την υποδομή που περιγράφει.Μιλήστε με έναν μηχανικό