Ο κύριος στόχος του Patroni είναι να παρέχει υψηλή διαθεσιμότητα για την PostgreSQL. Αλλά το Patroni είναι απλώς ένα πρότυπο, όχι ένα έτοιμο εργαλείο (κάτι που ουσιαστικά λέει η τεκμηρίωση). Με την πρώτη ματιά, ρυθμίζοντας το Patroni σε ένα εργαστήριο δοκιμών, μπορείτε να καταλάβετε πόσο εξαιρετικό εργαλείο είναι και πόσο εύκολα χειρίζεται τις προσπάθειές μας να σπάσουμε το σύμπλεγμα. Ωστόσο, στην πράξη, σε ένα περιβάλλον παραγωγής, τα πράγματα δεν συμβαίνουν πάντα τόσο όμορφα και κομψά όσο σε ένα εργαστήριο δοκιμών.
Επιτρέψτε μου να σας πω λίγα πράγματα για τον εαυτό μου. Ξεκίνησα ως διαχειριστής συστήματος. Εργάστηκε στην ανάπτυξη ιστοσελίδων. Εργάζομαι στην Data Egret από το 2014. Η εταιρεία ασχολείται με συμβουλευτικές υπηρεσίες στον τομέα της Postgres. Και εξυπηρετούμε συγκεκριμένα την Postgres και συνεργαζόμαστε με την Postgres καθημερινά, επομένως έχουμε διαφορετική εξειδίκευση σε θέματα λειτουργίας.
Και στα τέλη του 2018, αρχίσαμε σιγά σιγά να χρησιμοποιούμε το Patroni. Και έχει συσσωρευτεί κάποια συγκεκριμένη εμπειρία. Με κάποιο τρόπο το διαγνώσαμε, το ρυθμίσαμε και καταλήξαμε στις βέλτιστες πρακτικές μας. Και σε αυτή την αναφορά θα μιλήσω γι' αυτούς.
Εκτός από το Postgres, μου αρέσει και το Postgres. LinuxΜου αρέσει να πειραματίζομαι με αυτό και να εξερευνώ, και μου αρέσει να κατασκευάζω πυρήνες. Μου αρέσει η εικονικοποίηση, τα κοντέινερ, το Docker και το Kubernetes. Ενδιαφέρομαι για όλα αυτά επειδή οι παλιές μου συνήθειες διαχείρισης αρχίζουν να με ξεπερνούν. Μου αρέσει να πειραματίζομαι με την παρακολούθηση. Μου αρέσουν επίσης τα πράγματα που σχετίζονται με το Postgres και σχετίζονται με τη διαχείριση, όπως η αναπαραγωγή και τα αντίγραφα ασφαλείας. Και στον ελεύθερο χρόνο μου, γράφω σε Go. Δεν είμαι μηχανικός λογισμικού, απλώς γράφω σε Go για τον εαυτό μου. Και το απολαμβάνω.
- Νομίζω ότι πολλοί από εσάς γνωρίζετε ότι το Postgres δεν διαθέτει HA (Υψηλή Διαθεσιμότητα) αμέσως μόλις το αγοράσετε. Για να αποκτήσετε το HA, πρέπει να εγκαταστήσετε κάτι, να το ρυθμίσετε, να καταβάλετε κάποια προσπάθεια και να το αποκτήσετε.
- Υπάρχουν πολλά εργαλεία και το Patroni είναι ένα από αυτά που λύνει το HA αρκετά καλό και πολύ καλά. Αλλά τοποθετώντας τα όλα σε ένα εργαστήριο δοκιμών και εκτελώντας τα, μπορούμε να δούμε ότι όλα λειτουργούν, μπορούμε να αναπαράγουμε ορισμένα προβλήματα, να δούμε πώς τα χειρίζεται το Patroni. Και θα δούμε ότι όλα θα λειτουργήσουν τέλεια.
- Στην πράξη όμως αντιμετωπίσαμε διαφορετικά προβλήματα. Και θα μιλήσω για αυτά τα προβλήματα.
- Θα σας πω πώς το διαγνώσαμε, τι προσαρμόσαμε, αν μας βοήθησε ή όχι.
- Δεν θα σας πω πώς να εγκαταστήσετε το Patroni, επειδή μπορείτε να το αναζητήσετε στο Google στο Διαδίκτυο, μπορείτε να δείτε τα αρχεία ρυθμίσεων για να καταλάβετε πώς ξεκινούν όλα, πώς διαμορφώνονται. Μπορείτε να κατανοήσετε τα σχήματα και τις αρχιτεκτονικές βρίσκοντας πληροφορίες σχετικά με αυτά στο Διαδίκτυο.
- Δεν θα μιλήσω για τις εμπειρίες άλλων ανθρώπων. Θα μιλήσω μόνο για τα προβλήματα που αντιμετωπίσαμε.
- Και δεν θα μιλήσω για τα προβλήματα που ξεπερνούν το Patroni και την PostgreSQL. Αν, για παράδειγμα, υπάρχουν προβλήματα που σχετίζονται με την εξισορρόπηση, όταν το σύμπλεγμά μας καταρρέει, δεν θα μιλήσω γι' αυτό.
Και μια μικρή παρατήρηση πριν ξεκινήσουμε την αναφορά μας.
Όλα αυτά τα προβλήματα που αντιμετωπίσαμε, τα είχαμε τους πρώτους 6-7-8 μήνες λειτουργίας. Με την πάροδο του χρόνου, καταλήξαμε στις δικές μας εσωτερικές βέλτιστες πρακτικές. Και τα προβλήματά μας εξαφανίστηκαν. Γι' αυτόν τον λόγο ανακοινώθηκε η έκθεση πριν από περίπου έξι μήνες, όταν όλα ήταν φρέσκα στο μυαλό μου και τα θυμόμουν όλα τέλεια.
Καθώς ετοίμαζα την έκθεση, ανέσυρα ήδη παλιές νεκροψίες και εξέταζα αρχεία καταγραφής. Και ορισμένες από τις λεπτομέρειες θα μπορούσαν να έχουν ξεχαστεί ή ορισμένες από τις λεπτομέρειες θα μπορούσαν να μην έχουν διερευνηθεί πλήρως κατά την ανάλυση των προβλημάτων, επομένως σε ορισμένα σημεία μπορεί να φαίνεται ότι τα προβλήματα δεν έχουν εξεταστεί πλήρως ή ότι υπάρχει κάποια έλλειψη πληροφοριών. Και γι' αυτό, σας ζητώ να με συγχωρήσετε για αυτή τη στιγμή.
Τι είναι το Πατρόνι;
- Αυτό είναι ένα πρότυπο για την κατασκευή HA. Αυτό είναι γραμμένο στην τεκμηρίωση. Και από την δική μου οπτική γωνία, αυτή είναι μια πολύ σωστή διευκρίνιση. Το Patroni δεν είναι η ιδανική λύση για όλα τα προβλήματά σας, δηλαδή πρέπει να καταβάλετε κάποια προσπάθεια για να λειτουργήσει και να είναι χρήσιμο.
- Αυτή είναι μια υπηρεσία agent που εγκαθίσταται σε κάθε υπηρεσία με βάση δεδομένων και η οποία είναι ένα είδος συστήματος init για το Postgres σας. Ξεκινά το Postgres, το σταματά, το επανεκκινεί, αλλάζει τη διαμόρφωσή του και αλλάζει την τοπολογία του συμπλέγματός σας.
- Συνεπώς, για να αποθηκευτεί η κατάσταση του cluster, η τρέχουσα αναπαράστασή του και η εμφάνισή του, απαιτείται κάποιο είδος αποθήκευσης. Και από αυτή την άποψη, ο Patroni ακολούθησε την πορεία αποθήκευσης κατάστασης σε ένα εξωτερικό σύστημα. Είναι ένα κατανεμημένο σύστημα αποθήκευσης διαμόρφωσης. Θα μπορούσε να είναι Etcd, Consul, ZooKeeper ή Etcd του Kubernetes, δηλαδή μία από αυτές τις επιλογές.
- Και ένα από τα χαρακτηριστικά του Patroni είναι ότι μπορείτε να αποκτήσετε το autofileover αμέσως μόλις το ρυθμίσετε. Αν πάρουμε το Repmgr για σύγκριση, ο διαχειριστής αρχείων περιλαμβάνεται εκεί. Με το Repmgr έχουμε εναλλαγή, αλλά αν θέλουμε αυτόματη μετατροπή αρχείων, πρέπει να τη ρυθμίσουμε επιπλέον. Το Patroni έχει ήδη έτοιμη την αυτόματη αρχειοθέτηση.
- Και υπάρχουν πολλά άλλα πράγματα. Για παράδειγμα, συντήρηση διαμόρφωσης, προσθήκη νέων αντιγράφων, αντίγραφα ασφαλείας κ.λπ. Αλλά αυτό είναι πέρα από το πεδίο εφαρμογής της αναφοράς, δεν θα μιλήσω γι' αυτό.
Και μια σύντομη περίληψη είναι ότι η κύρια εργασία του Patroni είναι να κάνει αυτόματη αρχειοθέτηση σωστά και αξιόπιστα, έτσι ώστε το σύμπλεγμά μας να παραμένει λειτουργικό και η εφαρμογή να μην παρατηρεί αλλαγές στην τοπολογία του συμπλέγματος.
Αλλά όταν αρχίζουμε να χρησιμοποιούμε το Patroni, το σύστημά μας γίνεται λίγο πιο περίπλοκο. Αν είχαμε Postgres πριν, τότε όταν χρησιμοποιούμε το Patroni παίρνουμε το ίδιο το Patroni, παίρνουμε το DCS, όπου αποθηκεύεται η κατάσταση. Και όλα αυτά πρέπει με κάποιο τρόπο να λειτουργήσουν. Τι μπορεί λοιπόν να σπάσει;
Μπορεί να σπάσει:
- Το Postgres μπορεί να χαλάσει. Θα μπορούσε να είναι ένα πρωτότυπο ή ένα αντίγραφο, ένα από αυτά θα μπορούσε να αποτύχει.
- Το ίδιο το Patroni μπορεί να σπάσει.
- Το DCS, όπου αποθηκεύεται η κατάσταση, ενδέχεται να παρουσιάσει σφάλμα.
- Και το δίκτυο μπορεί να σπάσει.
Θα εξετάσω όλα αυτά τα σημεία στην έκθεση.
Θα εξετάσω τις υποθέσεις κατά σειρά πολυπλοκότητάς τους και όχι από την άποψη ότι η υπόθεση επηρεάζει πολλά στοιχεία. Και από την άποψη των υποκειμενικών συναισθημάτων, αυτή η θήκη ήταν δύσκολη για μένα, ήταν δύσκολο να αποσυναρμολογηθεί... και αντίστροφα, μερικές θήκες ήταν ελαφριές και εύκολες στην αποσυναρμολόγηση.
Και η πρώτη περίπτωση είναι η πιο απλή. Αυτή είναι η περίπτωση όταν πήραμε ένα σύμπλεγμα βάσεων δεδομένων και αναπτύξαμε τον χώρο αποθήκευσης DCS στο ίδιο σύμπλεγμα. Αυτό είναι το πιο συνηθισμένο λάθος. Αυτό είναι ένα σφάλμα αρχιτεκτονικού σχεδιασμού, δηλαδή ο συνδυασμός διαφορετικών στοιχείων σε ένα μέρος.
Λοιπόν, έχει συμβεί ένα filer, ας δούμε τι συνέβη.
Και εδώ μας ενδιαφέρει πότε συνέβη το filer. Δηλαδή, μας ενδιαφέρει αυτή η χρονική στιγμή κατά την οποία συνέβη η αλλαγή στην κατάσταση του συμπλέγματος.
Αλλά η διαδικασία αρχειοθέτησης δεν είναι πάντα στιγμιαία, δηλαδή δεν χρειάζεται συγκεκριμένο χρονικό διάστημα, μπορεί να παραταθεί. Μπορεί να είναι μακράς διαρκείας.
Επομένως, έχει ώρα έναρξης και ώρα λήξης, δηλαδή είναι ένα συνεχές γεγονός. Και διαιρούμε όλα τα γεγονότα σε τρία διαστήματα: έχουμε χρόνο πριν από την καταχώρηση, κατά τη διάρκεια της καταχώρησης και μετά την καταχώρηση. Δηλαδή, λαμβάνουμε υπόψη όλα τα γεγονότα σε αυτήν τη χρονογραμμή.
Και το πρώτο πράγμα που κάνουμε όταν συμβαίνει μια καταχώρηση είναι να αναζητήσουμε τον λόγο, τι συνέβη, τι προκάλεσε και τι οδήγησε στην καταχώρηση.
Αν κοιτάξουμε τα αρχεία καταγραφής, αυτά θα είναι κλασικά αρχεία καταγραφής Patroni. Σε αυτά, μας λέει ότι ο διακομιστής έχει γίνει master και ο ρόλος του master έχει περάσει σε αυτόν τον κόμβο. Είναι επισημασμένο εδώ.
Στη συνέχεια, πρέπει να κατανοήσουμε γιατί συνέβη το filer, δηλαδή ποια γεγονότα συνέβησαν που προκάλεσαν τη μετακίνηση του κύριου ρόλου από τον έναν κόμβο στον άλλο. Και σε αυτή την περίπτωση, όλα είναι απλά. Παρουσιάστηκε σφάλμα κατά την αλληλεπίδραση με το σύστημα αποθήκευσης. Ο πλοίαρχος συνειδητοποίησε ότι δεν μπορούσε να δουλέψει με το DCS, δηλαδή υπήρχε κάποιο πρόβλημα με την αλληλεπίδραση. Και λέει ότι δεν μπορεί πλέον να είναι αφέντης και παραιτείται. Αυτή η γραμμή «υποβιβασμένος εαυτός» λέει ακριβώς αυτό.
Αν κοιτάξουμε τα γεγονότα που προηγήθηκαν του καταλόγου, μπορούμε να δούμε εκεί τους ίδιους τους λόγους που λειτούργησαν ως πρόβλημα για τη συνέχιση του έργου του δασκάλου.
Αν κοιτάξουμε τα αρχεία καταγραφής του Patroni, θα δούμε ότι έχουμε πολλά σφάλματα, χρονικά όρια, δηλαδή ο παράγοντας Patroni δεν μπορεί να λειτουργήσει με το DCS. Σε αυτήν την περίπτωση, είναι ο πράκτορας του Προξένου, με τον οποίο η επικοινωνία λαμβάνει χώρα στη θύρα 8500.
Το πρόβλημα εδώ είναι ότι το Patroni και η βάση δεδομένων εκτελούνται στον ίδιο κεντρικό υπολογιστή. Οι διακομιστές Consul εκτελούνταν επίσης στον ίδιο κεντρικό υπολογιστή. Δημιουργώντας ένα φορτίο στον διακομιστή, δημιουργήσαμε προβλήματα για διακομιστές Πρόξενος. Δεν μπόρεσαν να επικοινωνήσουν κανονικά.
Μετά από κάποιο χρονικό διάστημα, όταν το φορτίο υποχώρησε, το Patroni μας μπόρεσε να επικοινωνήσει ξανά με τους πράκτορες. Οι κανονικές λειτουργίες έχουν επαναρχίσει. Και ο ίδιος διακομιστής Pgdb-2 έγινε ξανά ο κύριος. Δηλαδή, υπήρξε μια μικρή ανατροπή, λόγω της οποίας ο κόμβος παραιτήθηκε από τις δυνάμεις του ως κύριος και στη συνέχεια τις ανέλαβε ξανά, δηλαδή όλα επέστρεψαν στην αρχική τους κατάσταση.
Και αυτό μπορεί να θεωρηθεί ως ψευδής συναγερμός ή μπορεί να θεωρηθεί ότι ο Patroni κάνει τα πάντα σωστά. Δηλαδή, συνειδητοποίησε ότι δεν μπορούσε να διατηρήσει την κατάσταση του σμήνους και αφαίρεσε τις δυνάμεις του.
Και εδώ προέκυψε το πρόβλημα επειδή οι διακομιστές Consul βρίσκονται στο ίδιο υλικό με τις βάσεις δεδομένων. Συνεπώς, οποιοδήποτε φορτίο: είτε πρόκειται για φορτίο σε δίσκους είτε για επεξεργαστές, επηρεάζει επίσης την αλληλεπίδραση με το σύμπλεγμα Consul.
Και αποφασίσαμε ότι αυτό δεν πρέπει να ζουν μαζί, διαθέσαμε μια ξεχωριστή ομάδα για τον Πρόξενο. Και η Patroni συνεργαζόταν ήδη με ξεχωριστό Consul, δηλαδή υπήρχε ένα ξεχωριστό cluster Postgres, ένα ξεχωριστό cluster Consul. Αυτές είναι βασικές οδηγίες για το πώς να διανείμετε και να αποθηκεύσετε όλα αυτά τα πράγματα, ώστε να μην ζουν μαζί.
Προαιρετικά, μπορείτε να τροποποιήσετε τις παραμέτρους ttl, loop_wait, retry_timeout, δηλαδή να προσπαθήσετε να επιβιώσετε από αυτές τις βραχυπρόθεσμες αιχμές φορτίου αυξάνοντας αυτές τις παραμέτρους. Αλλά αυτή δεν είναι η καταλληλότερη επιλογή, επειδή αυτό το φορτίο μπορεί να είναι μακροπρόθεσμο. Και απλώς θα ξεπεράσουμε αυτά τα όρια αυτών των παραμέτρων. Και αυτό μπορεί να μην βοηθήσει καθόλου.
Το πρώτο πρόβλημα, όπως καταλαβαίνετε, είναι απλό. Πήραμε και βάλαμε το DCS μαζί με τη βάση, και αντιμετωπίσαμε ένα πρόβλημα.
Το δεύτερο πρόβλημα είναι παρόμοιο με το πρώτο. Είναι παρόμοιο με το ότι αντιμετωπίζουμε και πάλι προβλήματα στην αλληλεπίδραση με το σύστημα DCS.
Αν κοιτάξουμε τα αρχεία καταγραφής, θα δούμε ότι έχουμε ξανά ένα σφάλμα επικοινωνίας. Και ο Patroni λέει ότι δεν μπορώ να αλληλεπιδράσω με το DCS, οπότε ο τρέχων κύριος μεταβαίνει σε λειτουργία αντιγραφής.
Ο παλιός δάσκαλος γίνεται αντίγραφο, εδώ ο Πατρόνι λειτουργεί όπως πρέπει. Εκτελεί την εντολή pg_rewind για να επαναφέρει το αρχείο καταγραφής συναλλαγών και στη συνέχεια να συνδεθεί με τον νέο κύριο διακομιστή και στη συνέχεια να επικοινωνήσει με τον νέο κύριο διακομιστή. Εδώ η Patroni λειτουργεί όπως πρέπει.
Εδώ πρέπει να βρούμε τη θέση που προηγήθηκε του αρχειοθέτη, δηλαδή τα σφάλματα που ήταν η αιτία για την οποία παρουσιάστηκε ο αρχειοθέτης. Και από αυτή την άποψη, είναι αρκετά βολικό να εργαστείτε με τα αρχεία καταγραφής Patroni. Γράφει τα ίδια μηνύματα σε συγκεκριμένα χρονικά διαστήματα. Και αν αρχίσουμε να κάνουμε γρήγορη κύλιση σε αυτά τα αρχεία καταγραφής, τότε θα δούμε από αυτά ότι τα αρχεία καταγραφής έχουν αλλάξει, πράγμα που σημαίνει ότι έχουν ξεκινήσει κάποια προβλήματα. Επιστρέφουμε γρήγορα σε αυτό το μέρος και βλέπουμε τι συμβαίνει.
Και σε μια κανονική κατάσταση τα αρχεία καταγραφής μοιάζουν κάπως έτσι. Ο κάτοχος της κλειδαριάς ελέγχεται. Και αν ο ιδιοκτήτης, για παράδειγμα, αλλάξει, τότε μπορεί να συμβούν κάποια γεγονότα στα οποία η Patroni πρέπει να ανταποκριθεί. Αλλά σε αυτή την περίπτωση, όλα είναι καλά μαζί μας. Ψάχνουμε για το σημείο όπου ξεκίνησαν τα λάθη.
Και αφού έχουμε κάνει κύλιση στο σημείο όπου άρχισαν να εμφανίζονται τα σφάλματα, βλέπουμε ότι είχαμε αυτόματη επανεγγραφή αρχείων. Και επειδή τα σφάλματά μας σχετίζονταν με την αλληλεπίδραση με το DCS και στην περίπτωσή μας χρησιμοποιήσαμε το Consul, εξετάζουμε επίσης τα αρχεία καταγραφής του Consul για να δούμε τι συνέβαινε εκεί.
Έχοντας χονδρικά συγκρίνει τον χρόνο αρχειοθέτησης και τον χρόνο στα αρχεία καταγραφής του Consul, βλέπουμε ότι οι γείτονές μας στο σύμπλεγμα Consul έχουν αρχίσει να αμφιβάλλουν για την ύπαρξη άλλων συμμετεχόντων στο σύμπλεγμα Consul.
Και αν κοιτάξετε τα αρχεία καταγραφής άλλων πρακτόρων του Προξένου, μπορείτε επίσης να δείτε ότι συμβαίνει κάποιο είδος κατάρρευσης δικτύου εκεί. Και όλοι οι συμμετέχοντες της ομάδας των Προξένων αμφιβάλλουν ο ένας για την ύπαρξη του άλλου. Και αυτό ήταν το κίνητρο για τον καταθέτη.
Αν κοιτάξετε τι συνέβη πριν από αυτά τα σφάλματα, μπορείτε να δείτε ότι υπάρχουν κάθε είδους σφάλματα, για παράδειγμα, deadline, RPC failed, δηλαδή υπάρχει σαφώς κάποιο πρόβλημα στην αλληλεπίδραση των συμμετεχόντων στο σύμπλεγμα Consul μεταξύ τους.
Η πιο απλή απάντηση είναι να διορθώσετε το δίκτυο. Αλλά είναι εύκολο για μένα να το πω αυτό από το βήμα. Αλλά οι συνθήκες είναι τέτοιες που ο πελάτης δεν μπορεί πάντα να αντέξει οικονομικά την επισκευή του δικτύου. Μπορεί να ζει στην περιοχή DC και να μην έχει τη δυνατότητα να επισκευάσει το δίκτυο ή να επηρεάσει τον εξοπλισμό. Και γι' αυτό χρειάζονται κάποιες άλλες επιλογές.
Υπάρχουν επιλογές:
- Η απλούστερη επιλογή, η οποία είναι γραμμένη, κατά τη γνώμη μου, ακόμη και στην τεκμηρίωση, είναι η απενεργοποίηση των ελέγχων Consul, δηλαδή η απλή διαβίβαση ενός άδειου πίνακα. Και λέμε στον πράκτορα του Προξένου να μην χρησιμοποιήσει καμία επιταγή. Με αυτούς τους ελέγχους μπορούμε να αγνοήσουμε αυτές τις καταιγίδες δικτύου και να μην ξεκινήσουμε το πρόγραμμα αρχειοθέτησης.
- Μια άλλη επιλογή είναι να ελέγξετε ξανά το raft_multiplier. Αυτή είναι μια παράμετρος του ίδιου του διακομιστή Consul. Από προεπιλογή, έχει οριστεί σε 5. Αυτή η τιμή συνιστάται από την τεκμηρίωση για περιβάλλοντα προετοιμασίας. Ουσιαστικά, αυτό επηρεάζει τη συχνότητα ανταλλαγής μηνυμάτων μεταξύ των συμμετεχόντων στο δίκτυο Consul. Στην ουσία, αυτή η παράμετρος επηρεάζει την ταχύτητα επικοινωνίας μεταξύ των συμμετεχόντων στο σύμπλεγμα Consul. Και για την παραγωγή συνιστάται ήδη η μείωσή του, έτσι ώστε οι κόμβοι να ανταλλάσσουν μηνύματα πιο συχνά.
- Μια άλλη επιλογή που έχουμε αρχίσει να χρησιμοποιούμε είναι η αύξηση της προτεραιότητας των διεργασιών Consul μεταξύ άλλων διεργασιών για τον χρονοπρογραμματιστή διεργασιών του λειτουργικού συστήματος. Υπάρχει μια τέτοια παράμετρος "ωραία", η οποία καθορίζει την προτεραιότητα των διεργασιών που λαμβάνεται υπόψη από τον χρονοπρογραμματιστή του λειτουργικού συστήματος κατά τον προγραμματισμό. Μειώσαμε επίσης την τιμή nice για τους εκπροσώπους του Consul, δηλαδή αυξήσαμε την προτεραιότητα, έτσι ώστε το λειτουργικό σύστημα να δίνει στις διεργασίες του Consul περισσότερο χρόνο για να εργαστούν και να εκτελέσουν τον κώδικά τους. Στην περίπτωσή μας, αυτό έλυσε το πρόβλημά μας.
- Μια άλλη επιλογή είναι να μην χρησιμοποιήσετε το Consul. Έχω έναν φίλο που είναι μεγάλος υποστηρικτής του Etcd. Και μαλώνουμε τακτικά μαζί του για το τι είναι καλύτερο, το Etcd ή το Consul. Αλλά όσον αφορά το τι είναι καλύτερο, συνήθως συμφωνούμε ότι το Consul έχει έναν agent που θα πρέπει να εκτελείται σε κάθε κόμβο με μια βάση δεδομένων. Δηλαδή, η αλληλεπίδραση μεταξύ του Patroni και του συμπλέγματος Consul λαμβάνει χώρα μέσω αυτού του πράκτορα. Και αυτός ο παράγοντας μετατρέπεται σε εμπόδιο. Αν συμβεί κάτι στον πράκτορα, ο Patroni δεν μπορεί πλέον να συνεργαστεί με το σύμπλεγμα Consul. Και αυτό είναι ένα πρόβλημα. Δεν υπάρχει πράκτορας στο πρόγραμμα Etcd. Το Patroni μπορεί να συνεργαστεί απευθείας με τη λίστα των διακομιστών Etcd και να επικοινωνήσει ήδη μαζί τους. Από αυτή την άποψη, εάν χρησιμοποιείτε το Etcd στην εταιρεία σας, τότε το Etcd πιθανότατα θα είναι καλύτερη επιλογή από το Consul. Αλλά εμείς, ως πελάτες μας, είμαστε πάντα περιορισμένοι από αυτά που έχει επιλέξει και χρησιμοποιεί ο πελάτης. Και ως επί το πλείστον, όλοι οι πελάτες μας έχουν Σύμβουλο.
- Και το τελευταίο σημείο είναι να επανεξετάσουμε τις τιμές των παραμέτρων. Μπορούμε να αυξήσουμε αυτές τις παραμέτρους σε υψηλότερη τιμή με την ελπίδα ότι τα βραχυπρόθεσμα προβλήματα του δικτύου μας θα είναι βραχύβια και δεν θα βρίσκονται εκτός του εύρους αυτών των παραμέτρων. Με αυτόν τον τρόπο μπορούμε να μειώσουμε την επιθετικότητα του Patroni στην εκτέλεση αυτόματης επεξεργασίας αρχείων (autofileover) εάν προκύψουν προβλήματα δικτύου.
Νομίζω ότι πολλοί από όσους χρησιμοποιούν το Patroni είναι εξοικειωμένοι με αυτήν την εντολή.
Αυτή η εντολή δείχνει την τρέχουσα κατάσταση του συμπλέγματος. Και με την πρώτη ματιά αυτή η εικόνα μπορεί να φαίνεται φυσιολογική. Έχουμε ένα master, έχουμε ένα replica, δεν υπάρχει καθυστέρηση αναπαραγωγής. Αλλά αυτή η εικόνα είναι φυσιολογική μέχρι να γνωρίζουμε ότι θα πρέπει να υπάρχουν τρεις κόμβοι σε αυτό το σύμπλεγμα, όχι δύο.
Συνεπώς, πραγματοποιήθηκε αυτόματη επανεγκατάσταση αρχείων. Και μετά από αυτήν την αυτόματη μεταφορά αρχείων, το αντίγραφο μας εξαφανίστηκε. Πρέπει να βρούμε γιατί εξαφανίστηκε και να την φέρουμε πίσω, να την αποκαταστήσουμε. Και ξαναπάμε στα αρχεία καταγραφής και βλέπουμε γιατί είχαμε αυτόματη επανεγγραφή αρχείων.
Σε αυτήν την περίπτωση, το δεύτερο αντίγραφο έγινε το κύριο. Όλα είναι καλά εδώ.
Και πρέπει να εξετάσουμε το αντίγραφο που έχει πέσει και δεν βρίσκεται στο σύμπλεγμα. Ανοίγουμε τα αρχεία καταγραφής του Patroni και βλέπουμε ότι έχουμε πρόβλημα στο στάδιο pg_rewind κατά τη διαδικασία σύνδεσης με το σύμπλεγμα. Για να συνδεθείτε στο σύμπλεγμα, πρέπει να γυρίσετε πίσω το αρχείο καταγραφής συναλλαγών, να ζητήσετε το απαιτούμενο αρχείο καταγραφής συναλλαγών από τον κύριο διακομιστή και να το χρησιμοποιήσετε για να επικοινωνήσετε με τον κύριο διακομιστή.
Σε αυτήν την περίπτωση δεν έχουμε αρχείο καταγραφής συναλλαγών και η ρεπλίκα δεν μπορεί να ξεκινήσει. Συνεπώς, σταματάμε το Postgres με ένα σφάλμα. Και γι' αυτό δεν βρίσκεται στο σύμπλεγμα.
Πρέπει να καταλάβουμε γιατί δεν υπάρχει στο σύμπλεγμα και γιατί δεν υπήρχαν αρχεία καταγραφής. Πηγαίνουμε στον νέο κύριο φάκελο και βλέπουμε τι υπάρχει στα αρχεία καταγραφής του. Αποδεικνύεται ότι όταν ολοκληρώθηκε το pg_rewind, προέκυψε ένα σημείο ελέγχου. Και ορισμένα από τα παλιά αρχεία καταγραφής συναλλαγών απλώς μετονομάστηκαν. Όταν ο παλιός κύριος διακομιστής προσπάθησε να συνδεθεί με τον νέο και να ζητήσει αυτά τα αρχεία καταγραφής, αυτά είχαν ήδη μετονομαστεί, απλώς δεν υπήρχαν.
Σύγκρινα τις χρονικές σημάνσεις όταν συνέβησαν αυτά τα γεγονότα. Και υπάρχει μια διαφορά κυριολεκτικά 150 χιλιοστών του δευτερολέπτου, δηλαδή το σημείο ελέγχου ολοκληρώθηκε σε 369 χιλιοστά του δευτερολέπτου και τα τμήματα WAL μετονομάστηκαν. Και κυριολεκτικά στα 517, μετά από 150 χιλιοστά του δευτερολέπτου, ξεκίνησε η επαναφορά στο παλιό αντίγραφο. Δηλαδή, κυριολεκτικά 150 χιλιοστά του δευτερολέπτου ήταν αρκετά για να αποτρέψουμε τη σύνδεση και τη λειτουργία του αντιγράφου.
Ποιες είναι οι επιλογές;
Αρχικά χρησιμοποιήσαμε υποδοχές αναπαραγωγής. Το θεωρήσαμε καλό. Αν και στο πρώτο στάδιο της λειτουργίας απενεργοποιήσαμε τις υποδοχές. Θεωρήσαμε ότι αν οι υποδοχές συσσώρευαν πολλά τμήματα WAL, θα μπορούσαμε να καταρρεύσουμε την κύρια μονάδα. Θα πέσει. Υποφέραμε για κάποιο διάστημα χωρίς κουλοχέρηδες. Και συνειδητοποιήσαμε ότι χρειαζόμασταν υποδοχές, τις επιστρέψαμε.
Αλλά υπάρχει ένα πρόβλημα εδώ, ότι όταν ο κύριος κώδικας μεταβαίνει σε αντίγραφο, διαγράφει τις υποδοχές και διαγράφει τα τμήματα WAL μαζί με τις υποδοχές. Και για να αποτρέψουμε την εμφάνιση αυτού του προβλήματος, αποφασίσαμε να αυξήσουμε την παράμετρο wal_keep_segments. Έχει 8 τμήματα από προεπιλογή. Το ανεβάσαμε στα 1 και εξετάσαμε πόσο ελεύθερο χώρο είχαμε. Και δωρίσαμε 000 gigabyte στο wal_keep_segments. Δηλαδή, κατά την εναλλαγή, έχουμε πάντα ένα απόθεμα 16 gigabytes αρχείων καταγραφής συναλλαγών σε όλους τους κόμβους.
Και το πλεονέκτημα είναι ότι είναι επίσης σχετικό με μακροπρόθεσμες εργασίες συντήρησης. Ας υποθέσουμε ότι πρέπει να ενημερώσουμε ένα από τα αντίγραφα. Και θέλουμε να το απενεργοποιήσουμε. Πρέπει να ενημερώσουμε το λογισμικό, ίσως το λειτουργικό σύστημα, κάτι άλλο. Και όταν απενεργοποιούμε ένα αντίγραφο, η υποδοχή για αυτό το αντίγραφο αφαιρείται επίσης. Και αν χρησιμοποιήσουμε ένα μικρό wal_keep_segments, τότε αν υπάρχει μεγάλη απουσία ενός αντιγράφου, τα αρχεία καταγραφής συναλλαγών θα χαθούν. Θα εμφανίσουμε ένα αντίγραφο, θα ζητήσει τα αρχεία καταγραφής συναλλαγών από το σημείο που σταμάτησε, αλλά ενδέχεται να μην βρίσκονται στον κύριο φάκελο. Και το αντίγραφο δεν θα μπορεί να συνδεθεί. Γι' αυτό διατηρούμε ένα μεγάλο απόθεμα περιοδικών.
Έχουμε μια παραγωγική βάση. Υπάρχουν ήδη έργα που εκτελούνται εκεί.
Έχει προκύψει σφάλμα αρχειοθέτησης. Μπήκαμε μέσα και κοιτάξαμε - όλα ήταν καλά, τα αντίγραφα ήταν στη θέση τους, δεν υπήρχε καθυστέρηση στην αναπαραγωγή. Δεν υπάρχουν σφάλματα ούτε στα αρχεία καταγραφής, όλα είναι καλά.
Η ομάδα προϊόντος λέει ότι θα έπρεπε να υπάρχουν κάποια δεδομένα, αλλά τα βλέπουμε από μία πηγή, αλλά δεν τα βλέπουμε στη βάση δεδομένων. Και πρέπει να καταλάβουμε τι τους συνέβη.
Είναι σαφές ότι το pg_rewind τα διέγραψε. Το καταλάβαμε αμέσως, αλλά πήγαμε να δούμε τι συμβαίνει.
Στα αρχεία καταγραφής μπορούμε πάντα να βρούμε πότε έγινε ο filer, ποιος έγινε master και μπορούμε να προσδιορίσουμε ποιος ήταν ο παλιός master και πότε ήθελε να γίνει αντίγραφο, δηλαδή χρειαζόμαστε αυτά τα αρχεία καταγραφής για να βρούμε τον όγκο των αρχείων καταγραφής συναλλαγών που χάθηκαν.
Ο παλιός μας αφέντης έκανε επανεκκίνηση. Και το Patroni ήταν καταχωρημένο στην αυτόματη εκκίνηση. Το Patroni έχει κυκλοφορήσει. Στη συνέχεια λάνσαρε την Postgres. Πιο συγκεκριμένα, πριν ξεκινήσει το Postgres και πριν το κάνει αντίγραφο, το Patroni ξεκίνησε τη διαδικασία pg_rewind. Συνεπώς, έσβησε ορισμένα από τα αρχεία καταγραφής συναλλαγών, κατέβασε νέα και συνδέθηκε. Εδώ ο Πατρόνι έκανε εξαιρετική δουλειά, δηλαδή όπως έπρεπε. Το σύμπλεγμά μας έχει αποκατασταθεί. Είχαμε 3 κόμβους, μετά τον αρχειοθέτη 3 κόμβους - όλα είναι ωραία.
Χάσαμε κάποια δεδομένα. Και πρέπει να καταλάβουμε πόσα έχουμε χάσει. Ψάχνουμε ακριβώς εκείνη τη στιγμή που είχαμε μια επιστροφή. Μπορούμε να το διαπιστώσουμε αυτό από τέτοιες καταχωρήσεις ημερολογίου. Το Rewind ξεκίνησε, έκανε κάτι εκεί και τελείωσε.
Πρέπει να βρούμε τη θέση στο αρχείο καταγραφής συναλλαγών όπου σταμάτησε ο παλιός κύριος διακομιστής. Σε αυτή την περίπτωση, είναι αυτό το σημάδι. Και χρειαζόμαστε το δεύτερο σημάδι, δηλαδή την απόσταση κατά την οποία ο παλιός κύριος διαφέρει από τον καινούργιο.
Παίρνουμε ένα κανονικό pg_wal_lsn_diff και συγκρίνουμε αυτά τα δύο σημάδια. Και σε αυτήν την περίπτωση παίρνουμε 17 megabyte. Ο καθένας αποφασίζει μόνος του αν αυτό είναι πολύ ή λίγο. Γιατί για κάποιους 17 megabytes δεν είναι πολλά, για άλλους είναι πολλά και απαράδεκτα. Εδώ, ο καθένας αποφασίζει για τον εαυτό του σύμφωνα με τις επιχειρηματικές ανάγκες.
Αλλά τι ανακαλύψαμε εμείς οι ίδιοι;
Καταρχάς, πρέπει να αποφασίσουμε μόνοι μας - χρειαζόμαστε πάντα το Patroni να ξεκινά αυτόματα μετά από μια επανεκκίνηση του συστήματος; Τις περισσότερες φορές, πρέπει να πάμε στον παλιό δάσκαλο και να δούμε πόσο μακριά έχει ταξιδέψει. Ίσως να ελέγξετε τα τμήματα του αρχείου καταγραφής συναλλαγών και να δείτε τι υπάρχει εκεί. Και να κατανοήσουμε αν μπορούμε να χάσουμε αυτά τα δεδομένα ή αν χρειάζεται να εκτελέσουμε το παλιό master σε αυτόνομη λειτουργία για να εξαγάγουμε αυτά τα δεδομένα.
Και μόνο μετά από αυτό θα πρέπει να λάβουμε αποφάσεις σχετικά με το αν μπορούμε να απορρίψουμε αυτά τα δεδομένα ή αν μπορούμε να τα επαναφέρουμε και να συνδέσουμε αυτόν τον κόμβο ως αντίγραφο στο σύμπλεγμά μας.
Επιπλέον, υπάρχει μια παράμετρος "maximum_lag_on_failover". Από προεπιλογή, αν δεν με απατά η μνήμη μου, αυτή η παράμετρος έχει τιμή 1 megabyte.
Πώς λειτουργεί; Εάν το αντίγραφο μας υστερεί κατά 1 megabyte δεδομένων όσον αφορά την καθυστέρηση αναπαραγωγής, τότε αυτό το αντίγραφο δεν συμμετέχει στις εκλογές. Και αν ξαφνικά παρουσιαστεί κάποιο πρόβλημα με την αρχειοθέτηση, το Patroni εξετάζει ποια αντίγραφα υστερούν. Εάν υστερούν λόγω μεγάλου αριθμού αρχείων καταγραφής συναλλαγών, δεν μπορούν να γίνουν κύριοι. Αυτό είναι ένα πολύ καλό χαρακτηριστικό ασφαλείας που σας αποτρέπει από την απώλεια πολλών δεδομένων.
Υπάρχει όμως ένα πρόβλημα εδώ, καθώς η καθυστέρηση αναπαραγωγής στο σύμπλεγμα Patroni και στο DCS ενημερώνεται σε ένα συγκεκριμένο χρονικό διάστημα. Νομίζω ότι τα 30 δευτερόλεπτα είναι η προεπιλεγμένη τιμή ttl.
Συνεπώς, μπορεί να υπάρχει μια κατάσταση όπου η καθυστέρηση αναπαραγωγής για τα αντίγραφα στο DCS είναι μία, αλλά στην πραγματικότητα μπορεί να υπάρχει μια εντελώς διαφορετική καθυστέρηση ή μπορεί να μην υπάρχει καθόλου καθυστέρηση, δηλαδή αυτό το πράγμα δεν είναι σε πραγματικό χρόνο. Και δεν αντικατοπτρίζει πάντα την πραγματική εικόνα. Και δεν έχει νόημα να κάνουμε περίπλοκη λογική πάνω σε αυτό.
Και ο κίνδυνος απωλειών παραμένει πάντα. Και στη χειρότερη περίπτωση, ένας τύπος, και στη μέση περίπτωση, ένας άλλος τύπος. Δηλαδή, όταν σχεδιάζουμε την εφαρμογή του Patroni και εκτιμούμε πόσα δεδομένα μπορούμε να χάσουμε, πρέπει να βασιστούμε σε αυτούς τους τύπους και να έχουμε μια γενική ιδέα για το πόσα δεδομένα μπορούμε να χάσουμε.
Και υπάρχουν καλά νέα. Όταν ο παλιός δάσκαλος έχει προχωρήσει, μπορεί να προχωρήσει λόγω κάποιων διεργασιών στο παρασκήνιο. Δηλαδή, υπήρχε κάποιο είδος αυτόματου κενού, έγραφε τα δεδομένα, τα αποθήκευε στο αρχείο καταγραφής συναλλαγών. Και μπορούμε εύκολα να αγνοήσουμε και να χάσουμε αυτά τα δεδομένα. Δεν υπάρχει κανένα πρόβλημα με αυτό.
Και έτσι φαίνονται τα αρχεία καταγραφής εάν έχει οριστεί η maximum_lag_on_failover και έχει προκύψει ένα αρχείο αρχειοθέτησης και πρέπει να επιλεγεί ένα νέο κύριο αρχείο. Το αντίγραφο αυτοαξιολογείται ως ανίκανο να συμμετάσχει στις εκλογές. Και αρνείται να συμμετάσχει στην κούρσα για την ηγεσία. Και περιμένει να επιλεγεί ένας νέος αφέντης για να συνδεθεί μαζί του. Αυτό είναι ένα επιπλέον μέτρο κατά της απώλειας δεδομένων.
Εδώ έχουμε μια ομάδα προϊόντων που έγραψε ότι το προϊόν τους αντιμετωπίζει προβλήματα κατά την εργασία με την Postgres. Ωστόσο, δεν μπορείτε να αποκτήσετε πρόσβαση στον ίδιο τον κύριο διακομιστή (master) επειδή δεν είναι προσβάσιμος μέσω SSH. Και η αυτόματη μετατροπή αρχείων δεν συμβαίνει επίσης.
Αυτός ο κεντρικός υπολογιστής έχει αναγκαστεί να κάνει επανεκκίνηση. Λόγω της επανεκκίνησης, έγινε αυτόματη επανεκκίνηση, αν και ήταν δυνατό να γίνει χειροκίνητη αυτόματη επανεκκίνηση, όπως καταλαβαίνω τώρα. Και μετά την επανεκκίνηση θα δούμε ήδη τι είχαμε με τον τρέχοντα κύριο υπολογιστή.
Ταυτόχρονα, γνωρίζαμε εκ των προτέρων ότι είχαμε προβλήματα με τους δίσκους, δηλαδή γνωρίζαμε ήδη από την παρακολούθηση πού να σκάψουμε και τι να ψάξουμε.
Μπήκαμε στο αρχείο καταγραφής του postgres και αρχίσαμε να βλέπουμε τι συνέβαινε εκεί. Είδαμε υποβολές που διαρκούσαν ένα, δύο, τρία δευτερόλεπτα εκεί, κάτι που δεν είναι καθόλου φυσιολογικό. Παρατηρήσαμε ότι η αυτόματη ηλεκτρική σκούπα μας ξεκινά πολύ αργά και περίεργα. Και είδαμε προσωρινά αρχεία στον δίσκο. Δηλαδή, όλα αυτά είναι ενδείξεις προβλημάτων με τους δίσκους.
Εξετάσαμε το σύστημα dmesg (αρχείο καταγραφής πυρηνικών μηνυμάτων). Και είδαμε ότι είχαμε προβλήματα με έναν από τους δίσκους. Το υποσύστημα δίσκου ήταν μια επιδρομή λογισμικού. Ελέγξαμε το /proc/mdstat και είδαμε ότι μας έλειπε ένας δίσκος. Δηλαδή, υπάρχει ένα Raid 8 δίσκων, μας λείπει ένας. Αν κοιτάξετε προσεκτικά τη διαφάνεια, μπορείτε να δείτε στην έξοδο ότι δεν έχουμε sde εκεί. Έχουμε, ας πούμε, χάσει έναν δίσκο. Αυτό πυροδότησε προβλήματα δίσκου και οι εφαρμογές αντιμετώπισαν επίσης προβλήματα κατά την εργασία με το σύμπλεγμα Postgres.
Και σε αυτήν την περίπτωση, το Patroni δεν θα μας είχε βοηθήσει με κανέναν τρόπο, επειδή το Patroni δεν έχει την ευθύνη της παρακολούθησης της κατάστασης του διακομιστή, της κατάστασης του δίσκου. Και πρέπει να παρακολουθούμε τέτοιες καταστάσεις μέσω εξωτερικής παρακολούθησης. Προσθέσαμε γρήγορα την παρακολούθηση δίσκου στην εξωτερική παρακολούθηση.
Και υπήρχε αυτή η σκέψη - θα μπορούσε να μας βοηθήσει το λογισμικό περίφραξης ή το λογισμικό φύλαξης; Θεωρήσαμε απίθανο να μας βοηθήσει σε αυτήν την περίπτωση, επειδή κατά τη διάρκεια των προβλημάτων, το Patroni συνέχισε να αλληλεπιδρά με το σύμπλεγμα DCS και δεν είδε κανένα πρόβλημα. Δηλαδή, από την άποψη του DCS και του Patroni, όλα ήταν καλά με το σύμπλεγμα, αν και στην πραγματικότητα υπήρχαν προβλήματα με τον δίσκο, υπήρχαν προβλήματα με τη διαθεσιμότητα της βάσης δεδομένων.
Κατά τη γνώμη μου, αυτό είναι ένα από τα πιο παράξενα προβλήματα που ερευνώ εδώ και πολύ καιρό, ξαναδιαβάζοντας πολλά αρχεία καταγραφής, ψάχνοντάς τα και αποκαλώντας το προσομοιωτή συμπλέγματος.
Το πρόβλημα ήταν ότι ο παλιός κύριος κόμβος δεν μπορούσε να γίνει ένα κανονικό αντίγραφο, δηλαδή το Patroni θα το έτρεχε, το Patroni θα έδειχνε ότι αυτός ο κόμβος ήταν παρών ως αντίγραφο, αλλά ταυτόχρονα δεν ήταν ένα κανονικό αντίγραφο. Τώρα θα δείτε γιατί. Αυτό έχω από την ανάλυση αυτού του προβλήματος.
Και πώς ξεκίνησαν όλα; Ξεκίνησε, όπως και στο προηγούμενο πρόβλημα, με δισκόφρενα. Είχαμε υποβολές ενός δευτερολέπτου, δύο δευτερολέπτων.
Υπήρξαν διακοπές σύνδεσης, δηλαδή οι πελάτες ήταν διχασμένοι.
Υπήρχαν μπλοκαρίσματα ποικίλης σοβαρότητας.
Και, κατά συνέπεια, το υποσύστημα δίσκου δεν είναι πολύ ευαίσθητο.
Και το πιο μυστηριώδες πράγμα για μένα είναι το αίτημα άμεσου τερματισμού λειτουργίας που έφτασε. Το Postgres έχει τρεις λειτουργίες τερματισμού λειτουργίας:
- Είναι ευχάριστο όταν περιμένουμε όλοι οι πελάτες να αποσυνδεθούν μόνοι τους.
- Υπάρχει μια περίοδος νηστείας όπου αναγκάζουμε τους πελάτες να αποσυνδεθούν επειδή πρόκειται να κλείσουμε.
- Και άμεση. Σε αυτήν την περίπτωση, το immediate δεν λέει καν στους πελάτες να αποσυνδεθούν, απλώς αποσυνδέεται χωρίς προειδοποίηση. Και το λειτουργικό σύστημα στέλνει ένα μήνυμα RST σε όλους τους πελάτες (ένα μήνυμα TCP ότι η σύνδεση έχει διακοπεί και ο πελάτης δεν έχει τίποτα άλλο να πιάσει).
Ποιος έστειλε αυτό το σήμα; Οι διεργασίες υποβάθρου του Postgres δεν στέλνουν τέτοια σήματα η μία στην άλλη, δηλαδή αυτό είναι το kill-9. Δεν το στέλνουν αυτό ο ένας στον άλλον, απλώς αντιδρούν σε αυτό, δηλαδή πρόκειται για μια επείγουσα επανεκκίνηση του Postgres. Δεν ξέρω ποιος τον έστειλε.
Κοίταξα την εντολή "last" και είδα ένα άτομο που είχε συνδεθεί επίσης σε αυτόν τον διακομιστή μαζί μας, αλλά ντράπηκα να κάνω την ερώτηση. Μπορεί να ήταν και ένας θάνατος -9. Θα έβλεπα το kill -9 στα αρχεία καταγραφής, επειδή το Postgres λέει ότι δεχόταν το kill -9, αλλά δεν το είδα στα αρχεία καταγραφής.
Ερευνώντας περαιτέρω, είδα ότι ο Patroni δεν είχε γράψει στο αρχείο καταγραφής για αρκετό καιρό – 54 δευτερόλεπτα. Και αν συγκρίνετε τις δύο χρονικές σημάνσεις, δεν υπήρχαν μηνύματα για περίπου 54 δευτερόλεπτα.
Και κατά τη διάρκεια αυτής της περιόδου, πραγματοποιήθηκε αυτόματη επανεγγραφή αρχείων. Ο Patroni έκανε εξαιρετική δουλειά και πάλι εδώ. Ο παλιός μας αφέντης δεν ήταν διαθέσιμος, κάτι του συνέβαινε. Και ξεκίνησε η εκλογή νέου αρχηγού. Όλα πήγαν καλά εδώ. Έχουμε τον pgsql01 ως τον νέο ηγέτη.
Έχουμε ένα αντίγραφο που έχει γίνει master. Και υπάρχει και μια δεύτερη παρατήρηση. Και υπήρχαν προβλήματα με τη δεύτερη γραμμή. Προσπάθησε να επαναρυθμίσει. Από όσο καταλαβαίνω, προσπάθησε να αλλάξει το recovery.conf, να επανεκκινήσει το Postgres και να συνδεθεί με το νέο master. Στέλνει μήνυμα κάθε 10 δευτερόλεπτα ότι προσπαθεί αλλά δεν τα καταφέρνει.
Και κατά τη διάρκεια αυτών των προσπαθειών, ένα σήμα άμεσου τερματισμού φτάνει στον παλιό κύριο πομποδέκτη. Ο κύριος υπολογιστής επανεκκινείται. Και επίσης η ανάκτηση σταματά επειδή ο παλιός κύριος υπολογιστής επανεκκινείται. Δηλαδή, το αντίγραφο δεν μπορεί να συνδεθεί σε αυτό επειδή βρίσκεται σε κατάσταση τερματισμού λειτουργίας.
Κάποια στιγμή άρχισε να λειτουργεί, αλλά η αναπαραγωγή δεν ξεκίνησε.
Η μόνη υπόθεση που έχω είναι ότι το recovery.conf περιείχε την παλιά διεύθυνση του κύριου αρχείου. Και όταν εμφανίστηκε ο νέος master, το δεύτερο αντίγραφο προσπαθούσε ακόμα να συνδεθεί με τον παλιό master.
Όταν το Patroni ξεκίνησε στο δεύτερο αντίγραφο, ο κόμβος ξεκίνησε αλλά δεν μπόρεσε να συνδεθεί μέσω αναπαραγωγής. Και σχηματίστηκε μια καθυστέρηση αναπαραγωγής που έμοιαζε κάπως έτσι. Δηλαδή, και οι τρεις κόμβοι ήταν στη θέση τους, αλλά ο δεύτερος κόμβος υστερούσε.
Ωστόσο, αν κοιτάξετε τα αρχεία καταγραφής που γράφτηκαν, μπορείτε να δείτε ότι η αναπαραγωγή δεν μπορεί να ξεκινήσει επειδή τα αρχεία καταγραφής συναλλαγών είναι διαφορετικά. Και τα αρχεία καταγραφής συναλλαγών που προσφέρει ο κύριος κόμβος, τα οποία καθορίζονται στο recovery.conf, απλώς δεν ταιριάζουν στον τρέχοντα κόμβο μας.
Και εδώ έκανα ένα λάθος. Έπρεπε να δω τι υπήρχε στο recovery.conf για να ελέγξω την υπόθεσή μου ότι συνδεόμασταν σε λάθος master. Αλλά εκείνη τη στιγμή απλώς το προσπαθούσα να καταλάβω και δεν μου πέρασε από το μυαλό, ούτε είδα ότι η πετονιά καθυστερούσε και θα έπρεπε να ξαναχυθεί, δηλαδή έκανα μια δουλειά με μισή καρδιά. Ήταν δικό μου λάθος.
Μετά από 30 λεπτά έφτασε ο διαχειριστής, δηλαδή επανεκκίνησα το Patroni στο αντίγραφο. Το είχα ήδη παρατήσει, σκέφτηκα ότι θα έπρεπε να το ξαναγεμίσω. Και σκέφτηκα - θα ξαναρχίσω το Patroni, ίσως προκύψει κάτι καλό. Η ανάκαμψη έχει ξεκινήσει. Και η βάση άνοιξε ακόμη και ήταν έτοιμη να δεχτεί συνδέσεις.
Η αντιγραφή έχει ξεκινήσει. Αλλά μετά από ένα λεπτό, παρουσίασε σφάλμα ότι τα αρχεία καταγραφής συναλλαγών δεν ήταν κατάλληλα για αυτό.
Σκέφτηκα να κάνω ξανά επανεκκίνηση. Επανεκκίνησα ξανά το Patroni, και δεν επανεκκίνησα το Postgres, επανεκκίνησα το Patroni με την ελπίδα ότι θα ξεκινούσε μαγικά η βάση δεδομένων.
Η αναπαραγωγή ξεκίνησε ξανά, αλλά τα σημάδια στο αρχείο καταγραφής συναλλαγών ήταν διαφορετικά από την προηγούμενη προσπάθεια. Η αναπαραγωγή σταμάτησε ξανά. Και το μήνυμα ήταν ήδη λίγο διαφορετικό. Και δεν ήταν ιδιαίτερα ενημερωτικό για μένα.
Και τότε μου έρχεται στο μυαλό - τι θα γινόταν αν επανεκκινούσα το Postgres και εκείνη τη στιγμή δημιουργούσα ένα σημείο ελέγχου στον τρέχοντα κύριο φάκελο για να μετακινήσω το σημείο στο αρχείο καταγραφής συναλλαγών λίγο προς τα εμπρός, έτσι ώστε η ανάκτηση να ξεκινήσει από διαφορετικό σημείο; Επιπλέον, είχαμε ακόμα αποθέματα WAL εκεί.
Επανεκκίνησα το Patroni, έφτιαξα μερικά σημεία ελέγχου στην κύρια μονάδα και μερικά σημεία επανεκκίνησης στη ρέπλικα όταν άνοιξε. Και βοήθησε. Σκέφτηκα για πολύ καιρό γιατί βοήθησε και πώς λειτουργούσε. Και η αντιγραφή ξεκίνησε. Και η αναπαραγωγή δεν ήταν πλέον διακεκομμένη.
Αυτό το πρόβλημα είναι ένα από τα πιο μυστηριώδη για μένα, και ακόμα αναρωτιέμαι τι πραγματικά συνέβη εκεί.
Ποια είναι τα συμπεράσματα εδώ; Το Patroni μπορεί να λειτουργήσει όπως προβλέπεται και χωρίς σφάλματα. Αλλά ταυτόχρονα, αυτό δεν αποτελεί 100% εγγύηση ότι όλα είναι καλά μαζί μας. Το αντίγραφο μπορεί να ξεκινήσει, αλλά μπορεί να βρίσκεται σε ημι-λειτουργική κατάσταση και η εφαρμογή δεν μπορεί να λειτουργήσει με ένα τέτοιο αντίγραφο επειδή θα περιέχει παλιά δεδομένα.
Και μετά τον αρχειοθέτη, πρέπει πάντα να ελέγχουμε ότι όλα είναι εντάξει με το σύμπλεγμα, δηλαδή ότι υπάρχει ο απαιτούμενος αριθμός αντιγράφων, ότι δεν υπάρχει καθυστέρηση αναπαραγωγής.
Και καθώς εξετάζουμε αυτά τα ζητήματα, θα διατυπώσω συστάσεις. Προσπάθησα να τα συνδυάσω σε δύο διαφάνειες. Ίσως όλες οι ιστορίες θα μπορούσαν να είχαν συνδυαστεί σε δύο διαφάνειες και μόνο αυτές να είχαν ειπωθεί.
Όταν χρησιμοποιείτε το Patroni, πρέπει να έχετε παρακολούθηση. Θα πρέπει πάντα να γνωρίζετε πότε έχει συμβεί μια αυτόματη επανεγγραφή, επειδή αν δεν γνωρίζετε ότι είχατε αυτόματη επανεγγραφή, δεν ελέγχετε το σύμπλεγμα. Και αυτό είναι κακό.
Μετά από κάθε αρχείο θα πρέπει πάντα να ελέγχουμε το σύμπλεγμα χειροκίνητα. Πρέπει να βεβαιωθούμε ότι έχουμε πάντα έναν ενημερωμένο αριθμό αντιγράφων, ότι δεν υπάρχει καθυστέρηση στην αναπαραγωγή, ότι δεν υπάρχουν σφάλματα στα αρχεία καταγραφής που σχετίζονται με τη ροή αναπαραγωγής, στο Patroni, στο σύστημα DCS.
Τα αυτόματα μπορούν να λειτουργήσουν με επιτυχία, το Patroni είναι ένα πολύ καλό εργαλείο. Μπορεί να λειτουργήσει, αλλά δεν θα φέρει το σύμπλεγμα στην επιθυμητή κατάσταση. Και αν δεν το γνωρίζουμε αυτό, θα έχουμε προβλήματα.
Και το Patroni δεν είναι πανάκεια. Πρέπει ακόμα να κατανοήσουμε πώς λειτουργεί το Postgres, πώς λειτουργεί η αναπαραγωγή και πώς λειτουργεί το Patroni με το Postgres και πώς παρέχεται η επικοινωνία μεταξύ των κόμβων. Αυτό είναι απαραίτητο για να μπορέσετε να διορθώσετε προβλήματα που προκύπτουν με τα χέρια σας.
Πώς προσεγγίζω το ζήτημα της διάγνωσης; Τυχαίνει να συνεργαζόμαστε με διαφορετικούς πελάτες και κανείς δεν έχει στοίβα ELK, και πρέπει να ταξινομήσουμε τα αρχεία καταγραφής ανοίγοντας 6 κονσόλες και 2 καρτέλες. Σε μία καρτέλα υπάρχουν τα αρχεία καταγραφής Patroni για κάθε κόμβο, σε μια άλλη καρτέλα υπάρχουν τα αρχεία καταγραφής Consul ή Postgres, εάν είναι απαραίτητο. Είναι πολύ δύσκολο να διαγνωστεί.
Ποιες προσεγγίσεις έχω αναπτύξει; Καταρχάς, κοιτάζω πάντα πότε φτάνει ο υπεύθυνος ταχυμεταφορών. Και για μένα αυτό είναι ένα είδος ορόσημου. Εξετάζω τι συνέβη πριν από την ταξινόμηση, κατά τη διάρκεια της ταξινόμησης και μετά την ταξινόμηση. Το fileover έχει δύο σημάδια: την ώρα έναρξης και την ώρα λήξης.
Στη συνέχεια, αναζητώ στα αρχεία καταγραφής συμβάντα πριν από τον καταγραφέα, τι προηγήθηκε του καταγραφέα, δηλαδή αναζητώ τους λόγους για τους οποίους συνέβη ο καταγραφέας.
Και αυτό δίνει μια εικόνα για την κατανόηση του τι συνέβη και τι μπορεί να γίνει στο μέλλον, ώστε να μην προκύψουν τέτοιες περιστάσεις (και ως εκ τούτου, να μην προκύψει καταχώρηση).
Και πού κοιτάμε συνήθως; Κοιτάζω:
- Πρώτο στα αρχεία καταγραφής Patroni.
- Στη συνέχεια, κοιτάζω τα αρχεία καταγραφής Postgres ή τα αρχεία καταγραφής DCS, ανάλογα με το τι βρέθηκε στα αρχεία καταγραφής Patroni.
- Και τα αρχεία καταγραφής συστήματος παρέχουν μερικές φορές μια κατανόηση του τι προκάλεσε το αρχείο.
Πώς νιώθω για την Πατρόνι; Έχω πολύ καλή στάση απέναντι στην Πατρόνι. Κατά τη γνώμη μου, αυτό είναι το καλύτερο που υπάρχει σήμερα. Γνωρίζω πολλά άλλα προϊόντα. Αυτά είναι τα Stolon, Repmgr, Pg_auto_failover, PAF. 4 όργανα. Τα έχω δοκιμάσει όλα. Μου άρεσε περισσότερο ο Πατρόνι.
Αν με ρωτήσουν: «Συνιστώ την Patroni;» Θα πω ναι, επειδή μου αρέσει ο Πατρόνι. Και νομίζω ότι έμαθα να το μαγειρεύω.
Αν ενδιαφέρεστε να δείτε ποια άλλα προβλήματα υπάρχουν με το Patroni, εκτός από τα προβλήματα που ανέφερα, μπορείτε πάντα να μεταβείτε στη σελίδα στο GitHub. Υπάρχουν πολλές διαφορετικές ιστορίες εκεί και συζητούνται πολλά ενδιαφέροντα ζητήματα. Και ως αποτέλεσμα, ορισμένα σφάλματα εισήχθησαν και επιλύθηκαν, δηλαδή είναι ένα ενδιαφέρον ανάγνωσμα.
Υπάρχουν μερικές ενδιαφέρουσες ιστορίες για ανθρώπους που αυτοπυροβολήθηκαν στο πόδι. Πολύ κατατοπιστικό. Διαβάζεις και καταλαβαίνεις ότι δεν πρέπει να το κάνεις αυτό. Τσεκάρα το κουτάκι για τον εαυτό μου.
Και θα ήθελα να ευχαριστήσω ιδιαίτερα την Zalando για την ανάπτυξη αυτού του έργου, δηλαδή τον Alexander Kukushkin και τον Alexey Klyukin. Ο Alexey Klyukin είναι ένας από τους συν-συγγραφείς, δεν εργάζεται πλέον στη Zalando, αλλά πρόκειται για δύο άτομα που άρχισαν να εργάζονται με αυτό το προϊόν.
Και νομίζω ότι το Patroni είναι πολύ ωραίο πράγμα. Χαίρομαι που υπάρχει, είναι ενδιαφέρον μαζί της. Και ένα μεγάλο ευχαριστώ σε όλους τους συντελεστές που γράφουν ενημερώσεις κώδικα στο Patroni. Ελπίζω ότι ο Πατρόνι θα γίνει πιο ώριμος, ψύχραιμος και αποτελεσματικός με την πάροδο του χρόνου. Είναι ήδη λειτουργικό, αλλά ελπίζω να βελτιωθεί ακόμα περισσότερο. Αν λοιπόν σκοπεύετε να χρησιμοποιήσετε το Patroni, μην φοβάστε. Αυτή είναι μια καλή λύση, μπορεί να εφαρμοστεί και να χρησιμοποιηθεί.
Αυτό είναι όλο. Αν έχετε οποιεσδήποτε ερωτήσεις, παρακαλώ ρωτήστε.
ερωτήσεις
Ευχαριστώ για την αναφορά! Αν μετά το φίλτρο πρέπει να κοιτάξουμε πολύ προσεκτικά, τότε γιατί χρειαζόμαστε αυτόματο φίλτρο;
Επειδή είναι κάτι καινούργιο. Δουλεύουμε μαζί της μόνο ένα χρόνο. Καλύτερα να είσαι ασφαλής παρά να το μετανιώσεις. Θέλουμε να μπούμε μέσα και να δούμε ότι όλα λειτούργησαν όπως έπρεπε. Αυτό είναι το επίπεδο δυσπιστίας των ενηλίκων - είναι καλύτερο να το ελέγξετε ξανά και να δείτε.
Για παράδειγμα, πήγαμε σήμερα το πρωί και κοιτάξαμε, σωστά;
Όχι το πρωί, συνήθως ανακαλύπτουμε για το autofileover σχεδόν αμέσως. Λαμβάνουμε ειδοποιήσεις και βλέπουμε ότι έχει πραγματοποιηθεί αυτόματη επανεγγραφή αρχείων. Μπαίνουμε μέσα και ρίχνουμε μια ματιά σχεδόν αμέσως. Αλλά όλοι αυτοί οι έλεγχοι πρέπει να λαμβάνονται σε επίπεδο παρακολούθησης. Εάν έχετε πρόσβαση στο Patroni μέσω του REST API, υπάρχει ιστορικό. Χρησιμοποιώντας το ιστορικό, μπορείτε να δείτε τις χρονικές σημάνσεις όταν εκτελέστηκε ο αρχειοθέτης. Με βάση αυτό, μπορεί να γίνει παρακολούθηση. Μπορείτε να ανατρέξετε στην ιστορία για να δείτε πόσα γεγονότα υπήρξαν. Αν έχουμε περισσότερα συμβάντα, σημαίνει ότι έχει συμβεί αυτόματη επανεγγραφή αρχείων. Μπορείς να πας και να δεις. Ή το αυτόματο σύστημα παρακολούθησης έλεγξε ότι όλα τα αντίγραφά μας είναι στη θέση τους, δεν υπάρχει καθυστέρηση και όλα είναι καλά.
Σας ευχαριστούμε!
Σας ευχαριστώ πολύ για την υπέροχη ιστορία! Αν μετακινήσαμε το σύμπλεγμα DCS κάπου μακριά από το σύμπλεγμα Postgres, χρειάζεται και αυτό το σύμπλεγμα να συντηρείται περιοδικά; Ποιες είναι οι βέλτιστες πρακτικές όσον αφορά την απενεργοποίηση ορισμένων τμημάτων του συμπλέγματος DCS, την πραγματοποίηση κάποιας ενέργειας με αυτά κ.λπ.; Πώς ζει όλη αυτή η δομή; Και πώς να τα κάνεις αυτά;
Μια εταιρεία χρειαζόταν να δημιουργήσει έναν πίνακα προβλημάτων για το τι θα συμβεί εάν ένα ή περισσότερα εξαρτήματα αποτύχουν. Χρησιμοποιώντας αυτόν τον πίνακα, εξετάζουμε διαδοχικά όλα τα στοιχεία και δημιουργούμε σενάρια σε περίπτωση βλάβης αυτών των στοιχείων. Συνεπώς, για κάθε σενάριο αποτυχίας, μπορείτε να έχετε ένα σχέδιο δράσης για την ανάκαμψη. Και στην περίπτωση του DCS, αυτό αποτελεί μέρος της τυπικής υποδομής. Και ο διαχειριστής το διαχειρίζεται, και ήδη βασιζόμαστε στους διαχειριστές που το διαχειρίζονται και στην ικανότητά του να το διορθώσει σε περίπτωση ατυχημάτων. Εάν δεν υπάρχει καθόλου DCS, τότε το αναπτύσσουμε, αλλά δεν το παρακολουθούμε ιδιαίτερα, επειδή δεν είμαστε υπεύθυνοι για την υποδομή, αλλά δίνουμε συστάσεις για το πώς και τι πρέπει να παρακολουθείται.
Λοιπόν, κατάλαβα σωστά ότι πρέπει να απενεργοποιήσω το Patroni, να απενεργοποιήσω το πρόγραμμα αρχειοθέτησης, να απενεργοποιήσω τα πάντα πριν κάνω οτιδήποτε με τους κεντρικούς υπολογιστές;
Εξαρτάται από το πόσους κόμβους έχουμε στο σύμπλεγμα DCS. Εάν υπάρχουν πολλοί κόμβοι και εάν απενεργοποιήσουμε μόνο έναν από τους κόμβους (αντίγραφο), τότε η απαρτία διατηρείται στο σύμπλεγμα. Και το Patroni παραμένει λειτουργικό. Και τίποτα δεν ενεργοποιείται. Αν έχουμε κάποιες πολύπλοκες λειτουργίες που επηρεάζουν περισσότερους κόμβους, η απουσία των οποίων θα μπορούσε να διαταράξει την απαρτία, τότε ναι, ίσως έχει νόημα να θέσουμε σε παύση το Patroni. Έχει μια αντίστοιχη εντολή - πατρωνική παύση, πατρωνική συνέχιση. Απλώς το διακόπτουμε προσωρινά και η αυτόματη επανεγγραφή δεν λειτουργεί κατά τη διάρκεια αυτής της περιόδου. Κάνουμε συντήρηση στο σύμπλεγμα DCS, μετά αφαιρούμε την παύση και συνεχίζουμε να λειτουργούμε.
Σας ευχαριστώ πολύ!
Σας ευχαριστώ πολύ για την αναφορά! Πώς αισθάνεται η ομάδα προϊόντος για την απώλεια δεδομένων;
Οι ομάδες προϊόντων δεν δίνουν δεκάρα, αλλά οι επικεφαλής των ομάδων ανησυχούν.
Ποιες εγγυήσεις υπάρχουν;
Είναι πολύ δύσκολο με τις εγγυήσεις. Υπάρχει μια έκθεση του Alexander Kukushkin με τίτλο «Πώς να υπολογίσετε το RPO και το RTO», δηλαδή τον χρόνο ανάκτησης και πόσα δεδομένα μπορούμε να χάσουμε. Νομίζω ότι πρέπει να βρούμε αυτές τις διαφάνειες και να τις μελετήσουμε. Από όσο θυμάμαι, υπάρχουν συγκεκριμένα βήματα για τον τρόπο υπολογισμού αυτών των πραγμάτων. Πόσες συναλλαγές μπορούμε να χάσουμε, πόσα δεδομένα μπορούμε να χάσουμε. Προαιρετικά, μπορούμε να χρησιμοποιήσουμε σύγχρονη αναπαραγωγή σε επίπεδο Patroni, αλλά αυτό είναι δίκοπο μαχαίρι: είτε έχουμε αξιοπιστία δεδομένων είτε χάνουμε ταχύτητα. Υπάρχει σύγχρονη αναπαραγωγή, αλλά δεν εγγυάται 100% προστασία από την απώλεια δεδομένων.
Αλέξη, σε ευχαριστώ για την υπέροχη αναφορά! Υπάρχει κάποια εμπειρία από τη χρήση του Patroni για προστασία μηδενικού επιπέδου; Δηλαδή, σε συνδυασμό με σύγχρονη λειτουργία αναμονής; Αυτή είναι η πρώτη ερώτηση. Και το δεύτερο ερώτημα. Χρησιμοποιήσατε διαφορετικές λύσεις. Χρησιμοποιήσαμε το Repmgr, αλλά χωρίς το autofileover, και τώρα σχεδιάζουμε να συνδέσουμε το autofileover. Και εξετάζουμε το Patroni ως εναλλακτική λύση. Ποια πλεονεκτήματα μπορείτε να πείτε σε σύγκριση με το Repmgr;
Η πρώτη ερώτηση αφορούσε τις σύγχρονες παρατηρήσεις. Κανείς δεν χρησιμοποιεί σύγχρονη αναπαραγωγή εδώ επειδή όλοι φοβούνται (Αρκετοί πελάτες τη χρησιμοποιούν ήδη και δεν έχουμε παρατηρήσει κανένα πρόβλημα απόδοσης κατ' αρχήν — Σημείωμα ομιλητή). Αλλά έχουμε αναπτύξει έναν κανόνα για εμάς ότι θα πρέπει να υπάρχουν τουλάχιστον τρεις κόμβοι σε ένα σύμπλεγμα σύγχρονης αναπαραγωγής, επειδή αν έχουμε δύο κόμβους και αν ο κύριος ή το αντίγραφο αποτύχει, τότε το Patroni μετατρέπει αυτόν τον κόμβο σε αυτόνομη λειτουργία, έτσι ώστε η εφαρμογή να συνεχίσει να λειτουργεί. Σε αυτήν την περίπτωση, υπάρχει κίνδυνος απώλειας δεδομένων.
Όσον αφορά τη δεύτερη ερώτηση, χρησιμοποιήσαμε το Repmgr και εξακολουθούμε να το χρησιμοποιούμε σε ορισμένους πελάτες για ιστορικούς λόγους. Τι μπορεί να πει κανείς; Στο Patroni, το autofileover είναι διαθέσιμο αμέσως, στο Repmgr, το autofileover είναι μια επιπλέον λειτουργία που πρέπει να ενεργοποιηθεί. Πρέπει να εκτελέσουμε το daemon Repmgr σε κάθε κόμβο και στη συνέχεια να ρυθμίσουμε το autofileover.
Το Repmgr ελέγχει αν οι κόμβοι Postgres είναι ενεργοί. Οι διεργασίες Repmgr ελέγχουν η μία την άλλη, κάτι που δεν είναι πολύ αποτελεσματικό, επειδή μπορεί να υπάρχουν πολύπλοκες περιπτώσεις απομόνωσης δικτύου στις οποίες ένα μεγάλο σύμπλεγμα Repmgr μπορεί να διασπαστεί σε πολλά μικρότερα και να συνεχίσει να λειτουργεί. Δεν παρακολουθώ το Repmgr εδώ και πολύ καιρό, ίσως να έχει διορθωθεί αυτό... ή ίσως όχι. Αλλά η εξαγωγή πληροφοριών σχετικά με την κατάσταση του συμπλέγματος στο DCS, όπως κάνουν οι Stolon και Patroni, είναι η πιο βιώσιμη επιλογή.
Αλέξι, έχω μια ερώτηση, ίσως χαζή. Σε ένα από τα πρώτα παραδείγματα, μετακινήσατε το DCS από τον τοπικό υπολογιστή σε έναν απομακρυσμένο κόμβο. Καταλαβαίνουμε ότι το δίκτυο είναι κάτι που έχει τα δικά του χαρακτηριστικά. ζει μόνο του. Και τι συμβαίνει εάν για κάποιο λόγο το σύμπλεγμα DCS δεν είναι διαθέσιμο; Δεν θα αναφέρω τους λόγους, θα μπορούσαν να υπάρχουν πολλοί: από τα στραβά χέρια των δικτυωτών μέχρι πραγματικά προβλήματα.
Δεν το είπα αυτό δυνατά, αλλά ένα σύμπλεγμα DCS πρέπει επίσης να είναι ανεκτικό σε σφάλματα, που σημαίνει ότι χρειάζεται έναν περιττό αριθμό κόμβων ώστε να επιτευχθεί απαρτία. Τι συμβαίνει εάν το σύμπλεγμα DCS δεν είναι διαθέσιμο ή δεν μπορεί να φτάσει στην απαρτία, δηλαδή εάν υπάρχει κάποια διαίρεση δικτύου ή σφάλμα κόμβου; Σε αυτήν την περίπτωση, το σύμπλεγμα Patroni μεταβαίνει σε λειτουργία μόνο ανάγνωσης. Το σύμπλεγμα Patroni δεν μπορεί να προσδιορίσει την κατάσταση του συμπλέγματος και τι πρέπει να κάνει. Δεν μπορεί να επικοινωνήσει με το DCS και να αποθηκεύσει εκεί τη νέα κατάσταση του συμπλέγματος, επομένως ολόκληρο το σύμπλεγμα μεταβαίνει μόνο για ανάγνωση. Και περιμένει είτε τη χειροκίνητη παρέμβαση του χειριστή είτε την αποκατάσταση του DCS.
Σε γενικές γραμμές, η DCS γίνεται μια υπηρεσία για εμάς τόσο σημαντική όσο η ίδια η βάση δεδομένων;
Ναι, ναι. Σε πολλές σύγχρονες εταιρείες, η Ανακάλυψη Υπηρεσιών αποτελεί αναπόσπαστο μέρος της υποδομής. Υλοποιείται πριν καν υπάρξει βάση δεδομένων στην υποδομή. Συμβατικά, η υποδομή ξεκίνησε, αναπτύχθηκε στο κέντρο δεδομένων και αμέσως έχουμε το Service Discovery. Αν είναι Consul, τότε το DNS μπορεί επίσης να κατασκευαστεί σε αυτό. Αν είναι Etcd, τότε θα μπορούσε να είναι μέρος ενός cluster Kubernetes, στο οποίο θα αναπτυχθούν όλα τα άλλα. Μου φαίνεται ότι η Ανακάλυψη Υπηρεσιών αποτελεί ήδη αναπόσπαστο μέρος των σύγχρονων υποδομών. Και το σκέφτονται πολύ νωρίτερα από ό,τι σκέφτονται τις βάσεις δεδομένων.
Σας ευχαριστούμε!
Πηγή: www.habr.com
