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