Στην ομιλία του, ο Andrey Borodin θα σας πει πώς έλαβαν υπόψη την εμπειρία της κλιμάκωσης του PgBouncer όταν σχεδίαζαν ένα pooler σύνδεσης , πώς το έβγαλαν στην παραγωγή. Επιπλέον, θα συζητήσουμε ποιες λειτουργίες του pooler θα θέλαμε να δούμε σε νέες εκδόσεις: είναι σημαντικό για εμάς όχι μόνο να καλύψουμε τις ανάγκες μας, αλλά να αναπτύξουμε την κοινότητα των χρηστών .
Βίντεο:
Γεια σε όλους! Το όνομα μου είναι Ανδρέας.
Στο Yandex, αναπτύσσω βάσεις δεδομένων ανοιχτού κώδικα. Και σήμερα έχουμε ένα θέμα σχετικά με τις συνδέσεις πόλων σύνδεσης.
Αν ξέρετε πώς να καλέσετε το Connection Pooler στα Ρωσικά, τότε πείτε μου. Θέλω πραγματικά να βρω έναν καλό τεχνικό όρο που θα πρέπει να καθιερωθεί στην τεχνική βιβλιογραφία.
Το θέμα είναι αρκετά περίπλοκο, επειδή σε πολλές βάσεις δεδομένων το πρόγραμμα συγκέντρωσης συνδέσεων είναι ενσωματωμένο και δεν χρειάζεται καν να το γνωρίζετε. Κάποιες ρυθμίσεις, φυσικά, υπάρχουν παντού, αλλά στο Postgres αυτό δεν λειτουργεί. Και παράλληλα (στο HighLoad++ 2019) υπάρχει μια αναφορά του Nikolai Samokhvalov για τη ρύθμιση ερωτημάτων στο Postgres. Και καταλαβαίνω ότι έχουν έρθει εδώ άνθρωποι που έχουν ήδη διαμορφώσει τέλεια αιτήματα, και αυτοί είναι άνθρωποι που αντιμετωπίζουν σπανιότερα προβλήματα συστήματος που σχετίζονται με το δίκτυο, τη χρήση πόρων. Και σε ορισμένα σημεία μπορεί να είναι αρκετά δύσκολο με την έννοια ότι τα προβλήματα δεν είναι εμφανή.
Η Yandex διαθέτει Postgres. Πολλές υπηρεσίες Yandex ζουν στο Yandex.Cloud. Και έχουμε αρκετά petabyte δεδομένων που δημιουργούν τουλάχιστον ένα εκατομμύριο αιτήματα ανά δευτερόλεπτο στο Postgres.
Και παρέχουμε ένα αρκετά τυπικό σύμπλεγμα για όλες τις υπηρεσίες - αυτός είναι ο κύριος κύριος κόμβος του κόμβου, τα δύο συνηθισμένα αντίγραφα (σύγχρονη και ασύγχρονη), δημιουργία αντιγράφων ασφαλείας, κλιμάκωση αιτημάτων ανάγνωσης στο αντίγραφο.
Κάθε κόμβος συμπλέγματος είναι Postgres, στον οποίο, εκτός από το Postgres και τα συστήματα παρακολούθησης, είναι εγκατεστημένο και ένα pooler σύνδεσης. Το Connection Pooler χρησιμοποιείται για περίφραξη και για τον κύριο σκοπό του.
Ποιος είναι ο κύριος σκοπός ενός pooler σύνδεσης;
Η Postgres υιοθετεί ένα μοντέλο διαδικασίας για την εργασία με μια βάση δεδομένων. Αυτό σημαίνει ότι μία σύνδεση είναι μία διαδικασία, ένα Backend Postgres. Και υπάρχουν πολλές διαφορετικές κρυφές μνήμες σε αυτό το backend, που είναι αρκετά ακριβό να γίνουν διαφορετικές για διαφορετικές συνδέσεις.
Επίσης, υπάρχει ένας πίνακας στον κώδικα Postgres που ονομάζεται procArray. Περιέχει βασικά δεδομένα σχετικά με τις συνδέσεις δικτύου. Και σχεδόν όλοι οι αλγόριθμοι επεξεργασίας procArray έχουν γραμμική πολυπλοκότητα, διατρέχουν ολόκληρη τη σειρά των συνδέσεων δικτύου. Είναι ένας αρκετά γρήγορος κύκλος, αλλά με περισσότερες εισερχόμενες συνδέσεις δικτύου, τα πράγματα γίνονται λίγο πιο ακριβά. Και όταν τα πράγματα γίνονται λίγο πιο ακριβά, καταλήγετε να πληρώνετε πολύ υψηλό τίμημα για μεγάλο αριθμό συνδέσεων δικτύου.
Υπάρχουν 3 πιθανές προσεγγίσεις:
- Στην πλευρά της εφαρμογής.
- Στην πλευρά της βάσης δεδομένων.
- Και μεταξύ, δηλαδή, όλων των δυνατών συνδυασμών.
Δυστυχώς, το ενσωματωμένο pooler βρίσκεται επί του παρόντος υπό ανάπτυξη. Οι φίλοι στο PostgreSQL Professional το κάνουν κυρίως. Το πότε θα εμφανιστεί είναι δύσκολο να προβλεφθεί. Και μάλιστα, έχουμε δύο λύσεις για την επιλογή αρχιτέκτονα. Αυτά είναι η πισίνα από την πλευρά της εφαρμογής και η ομάδα μεσολάβησης.
Η πισίνα στην πλευρά της εφαρμογής είναι ο ευκολότερος τρόπος. Και σχεδόν όλα τα προγράμματα οδήγησης πελατών σάς παρέχουν έναν τρόπο: να αναπαραστήσετε εκατομμύρια από τις συνδέσεις σας στον κώδικα ως μερικές δεκάδες συνδέσεις στη βάση δεδομένων.
Υπάρχει ένα πρόβλημα με το γεγονός ότι σε ένα συγκεκριμένο σημείο θέλετε να κλιμακώσετε το backend, θέλετε να το αναπτύξετε σε πολλές εικονικές μηχανές.
Τότε εξακολουθείτε να συνειδητοποιείτε ότι έχετε πολλές περισσότερες ζώνες διαθεσιμότητας, πολλά κέντρα δεδομένων. Και η προσέγγιση συγκέντρωσης από την πλευρά του πελάτη οδηγεί σε μεγάλους αριθμούς. Οι μεγάλες είναι περίπου 10 συνδέσεις. Αυτή είναι μια άκρη που μπορεί να λειτουργήσει καλά.
Αν μιλάμε για proxy poolers, τότε υπάρχουν δύο poolers που μπορούν να κάνουν πολλά πράγματα. Δεν είναι μόνο ομαδοποιοί. Είναι poolers + πιο δροσερή λειτουργικότητα. Αυτό и .
Αλλά, δυστυχώς, δεν χρειάζονται όλοι αυτήν την πρόσθετη λειτουργία. Και οδηγεί στο γεγονός ότι τα προγράμματα συγκέντρωσης υποστηρίζουν μόνο τη συγκέντρωση συνεδριών, δηλαδή έναν εισερχόμενο πελάτη, έναν εξερχόμενο πελάτη στη βάση δεδομένων.
Αυτό δεν είναι πολύ κατάλληλο για τις εργασίες μας, επομένως χρησιμοποιούμε το PgBouncer, το οποίο υλοποιεί τη συγκέντρωση συναλλαγών, δηλαδή οι συνδέσεις διακομιστή αντιστοιχίζονται σε συνδέσεις πελατών μόνο για τη διάρκεια της συναλλαγής.
Και στο φορτίο μας - είναι αλήθεια. Υπάρχουν όμως αρκετά προβλήματα.
Τα προβλήματα ξεκινούν όταν θέλετε να διαγνώσετε μια περίοδο λειτουργίας, επειδή όλες οι εισερχόμενες συνδέσεις είναι τοπικές. Όλοι ήρθαν με loopback και με κάποιο τρόπο γίνεται δύσκολο να εντοπιστεί η συνεδρία.
Φυσικά μπορείτε να χρησιμοποιήσετε το application_name_add_host. Αυτός είναι ο τρόπος Bouncer για να προσθέσετε μια διεύθυνση IP στο application_name. Αλλά το application_name ορίζεται από μια πρόσθετη σύνδεση.
Σε αυτό το γράφημα, όπου η κίτρινη γραμμή είναι τα πραγματικά αιτήματα και όπου η μπλε γραμμή είναι τα αιτήματα που μεταφέρονται στη βάση δεδομένων. Και αυτή η διαφορά είναι ακριβώς η ρύθμιση του application_name, που χρειάζεται μόνο για τον εντοπισμό, αλλά δεν είναι καθόλου δωρεάν.
Επιπλέον, το Bouncer δεν μπορεί να περιορίσει ένα pool, δηλαδή τον αριθμό των συνδέσεων βάσης δεδομένων ανά χρήστη, ανά βάση δεδομένων.
Σε τι οδηγεί αυτό; Έχετε μια φορτωμένη υπηρεσία γραμμένη σε C ++ και κάπου κοντά μια μικρή υπηρεσία σε έναν κόμβο που δεν κάνει τίποτα κακό στη βάση, αλλά ο οδηγός του τρελαίνεται. Ανοίγει 20 συνδέσεις και όλα τα άλλα θα περιμένουν. Ακόμα και ο κωδικός σου είναι σωστός.
Φυσικά, γράψαμε μια μικρή ενημέρωση κώδικα για το Bouncer που πρόσθεσε αυτήν τη ρύθμιση, δηλαδή περιορίζοντας τους πελάτες στο pool.
Θα ήταν δυνατό να γίνει αυτό από την πλευρά Postgres, δηλαδή να περιορίσετε τους ρόλους στη βάση δεδομένων στον αριθμό των συνδέσεων.
Αλλά τότε χάνετε την ικανότητα να καταλάβετε γιατί δεν έχετε συνδέσεις με τον διακομιστή. Το PgBouncer δεν εκτελεί σφάλμα σύνδεσης, επιστρέφει πάντα τις ίδιες πληροφορίες. Και δεν μπορείτε να καταλάβετε: ίσως ο κωδικός πρόσβασής σας έχει αλλάξει, ίσως η βάση δεδομένων μόλις κατέβηκε, ίσως κάτι δεν πάει καλά. Δεν υπάρχει όμως διάγνωση. Εάν η συνεδρία δεν μπορεί να δημιουργηθεί, δεν θα ξέρετε γιατί δεν μπορεί να γίνει.
Σε ένα συγκεκριμένο σημείο, κοιτάς τα γραφήματα της εφαρμογής και βλέπεις ότι η εφαρμογή δεν λειτουργεί.
Κοιτάξτε την κορυφή και δείτε ότι το Bouncer είναι μονού νήματος. Αυτό είναι ένα σημείο καμπής στη ζωή της υπηρεσίας. Καταλαβαίνετε ότι προετοιμαζόσασταν να κλιμακώσετε τη βάση δεδομένων σε ενάμιση χρόνο, και πρέπει να κλιμακώσετε τη συγκέντρωση.
Καταλήξαμε στο συμπέρασμα ότι χρειαζόμαστε περισσότερα PgBouncer.
Το Bouncer έχει ελαφρώς διορθωθεί.
Και το έκαναν έτσι ώστε πολλά Bouncer να μπορούν να αυξηθούν με την επαναχρησιμοποίηση της θύρας TCP. Και ήδη το λειτουργικό σύστημα μεταφέρει αυτόματα τις εισερχόμενες συνδέσεις TCP μεταξύ τους μέσω round-robin'om.
Αυτό είναι διαφανές για τους πελάτες, δηλαδή φαίνεται ότι έχετε ένα Bouncer, αλλά έχετε κατακερματισμό των αδρανών συνδέσεων μεταξύ των εκτελούμενων Bouncer.
Και σε κάποιο σημείο, μπορεί να παρατηρήσετε ότι αυτοί οι 3 Bouncer τρώνε ο καθένας τους τον πυρήνα τους κατά 100%. Χρειάζεστε αρκετούς Bouncers. Γιατί;
Επειδή έχετε TLS. Έχετε κρυπτογραφημένη σύνδεση. Και αν κάνετε συγκριτική αξιολόγηση για το Postgres με και χωρίς TLS, θα διαπιστώσετε ότι ο αριθμός των εγκατεστημένων συνδέσεων μειώνεται σχεδόν κατά δύο τάξεις μεγέθους με ενεργοποιημένη την κρυπτογράφηση, επειδή η χειραψία TLS καταναλώνει πόρους CPU.
Και στην κορυφή, μπορείτε να δείτε αρκετές κρυπτογραφικές λειτουργίες που εκτελούνται κατά τη διάρκεια ενός κύματος εισερχόμενων συνδέσεων. Δεδομένου ότι το πρωτεύον μας μπορεί να εναλλάσσεται μεταξύ των ζωνών διαθεσιμότητας, ένα κύμα εισερχόμενων συνδέσεων είναι μια αρκετά τυπική κατάσταση. Δηλαδή, για κάποιο λόγο, το παλιό πρωτεύον δεν ήταν διαθέσιμο, ολόκληρο το φορτίο στάλθηκε σε άλλο κέντρο δεδομένων. Θα έρθουν όλοι να πουν ένα γεια στο TLS ταυτόχρονα.
Και ένας μεγάλος αριθμός χειραψιών TLS μπορεί να μην χαιρετήσει ήδη τον Bouncer, αλλά να του σφίξει το λαιμό. Ένα κύμα εισερχόμενων συνδέσεων ενδέχεται να μην εξαλειφθεί λόγω του χρονικού ορίου. Εάν προσπαθήσετε ξανά στη βάση χωρίς εκθετική υποχώρηση, δεν θα επανέλθουν ξανά και ξανά σε ένα συνεκτικό κύμα.
Ακολουθεί ένα παράδειγμα 16 PgBouncer που φορτώνουν 16 πυρήνες στο 100%.
Φτάσαμε στο καταρράκτη PgBouncer. Αυτή είναι η καλύτερη διαμόρφωση που μπορούμε να επιτύχουμε στο Bouncer load μας. Τα εξωτερικά μας Bouncer χρησιμεύουν για χειραψία TCP και τα εσωτερικά Bouncer χρησιμεύουν για πραγματική συγκέντρωση, προκειμένου να μην κατακερματιστούν σε μεγάλο βαθμό οι εξωτερικές συνδέσεις.
Σε αυτήν τη διαμόρφωση, είναι δυνατή μια ομαλή επανεκκίνηση. Μπορείτε να επανεκκινήσετε όλα αυτά τα 18 Bouncer ένα προς ένα. Αλλά η διατήρηση μιας τέτοιας διαμόρφωσης είναι αρκετά δύσκολη. Οι διαχειριστές συστήματος, οι DevOps και οι άνθρωποι που είναι πραγματικά υπεύθυνοι για αυτόν τον διακομιστή δεν θα είναι πολύ ευχαριστημένοι με αυτό το σχήμα.
Φαίνεται ότι όλες οι βελτιώσεις μας μπορούν να προωθηθούν σε ανοιχτό κώδικα, αλλά το Bouncer δεν υποστηρίζει πολύ καλά. Για παράδειγμα, η δυνατότητα εκτέλεσης πολλών PgBouncers στην ίδια θύρα δεσμεύτηκε πριν από ένα μήνα. Ένα αίτημα έλξης με αυτό το χαρακτηριστικό ήταν πριν από μερικά χρόνια.
Ή ένα ακόμη παράδειγμα. Στο Postgres, μπορείτε να ακυρώσετε ένα αίτημα που εκτελείται στέλνοντας το μυστικό σε άλλη σύνδεση χωρίς τον επιπλέον έλεγχο ταυτότητας. Αλλά ορισμένοι πελάτες απλώς στέλνουν μια επαναφορά TCP, δηλαδή διακόπτουν τη σύνδεση δικτύου. Τι θα κάνει ο Bouncer με αυτό; Δεν θα κάνει τίποτα. Θα συνεχίσει να εκτελεί το αίτημα. Εάν έχετε λάβει έναν τεράστιο αριθμό συνδέσεων που έχουν θέσει τη βάση με μικρά αιτήματα, τότε απλώς η αποσύνδεση της σύνδεσης από το Bouncer δεν θα είναι αρκετή, πρέπει επίσης να ολοκληρώσετε εκείνα τα αιτήματα που εκτελούνται στη βάση δεδομένων.
Αυτό έχει διορθωθεί και το ζήτημα εξακολουθεί να μην έχει συγχωνευθεί στο upstream του Bouncer.
Και έτσι καταλήξαμε στο συμπέρασμα ότι χρειαζόμαστε το δικό μας pooler σύνδεσης, το οποίο θα αναπτυχθεί, θα επιδιορθωθεί, στο οποίο θα είναι δυνατό να διορθωθούν γρήγορα προβλήματα και το οποίο, φυσικά, πρέπει να είναι πολλαπλών νημάτων.
Θέσαμε το multithreading ως κύριο καθήκον. Πρέπει να είμαστε σε θέση να χειριστούμε καλά το κύμα των εισερχόμενων συνδέσεων TLS.
Για να γίνει αυτό, έπρεπε να αναπτύξουμε μια ξεχωριστή βιβλιοθήκη που ονομάζεται Machinarium, η οποία έχει σχεδιαστεί για να περιγράφει τις καταστάσεις μηχανής μιας σύνδεσης δικτύου ως σειριακό κώδικα. Αν κοιτάξετε τον πηγαίο κώδικα του libpq, θα δείτε αρκετά περίπλοκες κλήσεις που μπορούν να σας επιστρέψουν ένα αποτέλεσμα και να σας πουν: "Καλέστε με λίγο αργότερα. Αυτήν τη στιγμή έχω IO προς το παρόν, αλλά όταν περάσει το IO, έχω φορτίο στον επεξεργαστή. Και αυτό είναι ένα πολυεπίπεδο σχήμα. Η αλληλεπίδραση δικτύου συνήθως περιγράφεται από μια μηχανή κατάστασης. Πολλοί κανόνες όπως "Εάν έλαβα προηγουμένως μια κεφαλίδα πακέτου μεγέθους N, τότε τώρα περιμένω N bytes", "Αν έστειλα ένα πακέτο SYNC, τότε τώρα περιμένω ένα πακέτο με μεταδεδομένα αποτελέσματος." Αποδεικνύεται ένας μάλλον δύσκολος αντιδιαισθητικός κώδικας, σαν ο λαβύρινθος να μετατράπηκε σε σάρωση γραμμής. Το κάναμε έτσι ώστε αντί για μηχανή κατάστασης, ο προγραμματιστής να περιγράφει την κύρια διαδρομή αλληλεπίδρασης με τη μορφή συνηθισμένου κώδικα προστακτικής. Απλώς σε αυτόν τον επιτακτική κώδικα, πρέπει να εισαγάγετε μέρη όπου η ακολουθία εκτέλεσης πρέπει να διακοπεί αναμένοντας δεδομένα από το δίκτυο, περνώντας το περιβάλλον εκτέλεσης σε άλλη κορουτίνα (πράσινο νήμα). Αυτή η προσέγγιση είναι παρόμοια με το γεγονός ότι γράφουμε το πιο αναμενόμενο μονοπάτι στο λαβύρινθο στη σειρά και, στη συνέχεια, προσθέτουμε κλάδους σε αυτό.
Ως αποτέλεσμα, έχουμε ένα νήμα που κάνει ένα TCP να δέχεται και το round-robin περνά μια σύνδεση TPC σε πολλούς εργαζόμενους.
Σε αυτήν την περίπτωση, κάθε σύνδεση πελάτη εκτελείται πάντα σε έναν επεξεργαστή. Και αυτό σας επιτρέπει να το κάνετε φιλικό στην κρυφή μνήμη.
Επιπλέον, έχουμε βελτιώσει ελαφρώς τη συλλογή μικρών πακέτων σε ένα μεγάλο πακέτο, προκειμένου να εκφορτωθεί η στοίβα TCP του συστήματος.
Επιπλέον, έχουμε βελτιώσει τη συγκέντρωση συναλλαγών με την έννοια ότι το Odyssey, όταν ρυθμιστεί, μπορεί να στείλει CANCEL και ROLLBACK σε περίπτωση αποτυχίας σύνδεσης δικτύου, δηλαδή εάν κανείς δεν περιμένει το αίτημα, η Odyssey θα πει στη βάση δεδομένων να μην προσπαθήσει να εκπληρώσει το αίτημα που μπορεί να σπαταλήσει πολύτιμους πόρους.
Και όποτε είναι δυνατόν, διατηρούμε συνδέσεις με τον ίδιο πελάτη. Αυτό αποφεύγει την επανεγκατάσταση του application_name_add_host. Εάν είναι δυνατόν, τότε δεν έχουμε επιπλέον επαναφορά των παραμέτρων που απαιτούνται για τα διαγνωστικά.
Εργαζόμαστε προς το συμφέρον του Yandex.Cloud. Και αν χρησιμοποιείτε τη διαχειριζόμενη PostgreSQL και έχετε εγκατεστημένο ένα πρόγραμμα συγκέντρωσης συνδέσεων, μπορείτε να δημιουργήσετε λογική αναπαραγωγή προς τα έξω, δηλαδή να μας αφήσετε αν θέλετε, χρησιμοποιώντας τη λογική αναπαραγωγή. Bouncer έξω από τη ροή της λογικής αναπαραγωγής δεν θα δώσει.
Αυτό είναι ένα παράδειγμα ρύθμισης λογικής αναπαραγωγής.
Επιπλέον, έχουμε υποστήριξη για φυσική αναπαραγωγή προς τα έξω. Στο Cloud, φυσικά, είναι αδύνατο, γιατί τότε το σύμπλεγμα θα σας δώσει πάρα πολλές πληροφορίες για τον εαυτό του. Αλλά στις εγκαταστάσεις σας, εάν χρειάζεστε φυσική αναπαραγωγή μέσω του Pooler σύνδεσης στην Odyssey, είναι δυνατό.
Το Odyssey έχει πλήρως συμβατή παρακολούθηση με το PgBouncer. Έχουμε την ίδια κονσόλα που εκτελεί σχεδόν όλες τις ίδιες εντολές. Αν κάτι λείπει, στείλτε ένα αίτημα έλξης ή τουλάχιστον ένα πρόβλημα στο GitHub, θα ολοκληρώσουμε τις απαραίτητες εντολές. Όμως έχουμε ήδη την κύρια λειτουργικότητα της κονσόλας PgBouncer.
Και φυσικά έχουμε σφάλμα προώθησης. Θα επιστρέψουμε το σφάλμα που αναφέρθηκε από τη βάση. Θα λάβετε πληροφορίες γιατί δεν είστε στη βάση, όχι απλώς ότι δεν είστε σε αυτήν.
Αυτή η δυνατότητα είναι απενεργοποιημένη σε περίπτωση που χρειάζεστε 100% συμβατότητα με το PgBouncer. Μπορούμε να συμπεριφερόμαστε σαν Bouncer, για κάθε ενδεχόμενο.
Ανάπτυξη
Λίγα λόγια για τον πηγαίο κώδικα της Οδύσσειας.
Για παράδειγμα, υπάρχουν εντολές "Παύση / Συνέχιση". Συνήθως χρησιμοποιούνται για την ενημέρωση της βάσης δεδομένων. Εάν χρειάζεται να αναβαθμίσετε το Postgres, μπορείτε να το θέσετε σε παύση στο πόλιερ σύνδεσης, να κάνετε pg_upgrade και μετά να συνεχίσετε. Και από την πλευρά του πελάτη, θα φαίνεται ότι η βάση δεδομένων απλώς επιβραδύνθηκε. Αυτή η λειτουργικότητα μας δόθηκε από άτομα από την κοινότητα. Δεν έχει πεθάνει ακόμα, αλλά σύντομα όλα θα γίνουν. (ήδη νεκρός)
- ήδη νεκρός
Επιπλέον, μία από τις νέες δυνατότητες του PgBouncer είναι η υποστήριξη ελέγχου ταυτότητας SCRAM, την οποία μας έφερε επίσης ένα άτομο που δεν εργάζεται στο Yandex.Cloud. Και τα δύο είναι πολύπλοκα λειτουργικά και σημαντικά.
Ως εκ τούτου, θα ήθελα να σας πω από τι είναι φτιαγμένο το Odyssey, σε περίπτωση που θέλετε να γράψετε τώρα κάποιο κώδικα.
Έχετε την αρχική βάση της Odyssey, η οποία βασίζεται σε δύο κύριες βιβλιοθήκες. Η βιβλιοθήκη Kiwi είναι μια υλοποίηση του πρωτοκόλλου μηνυμάτων Postgres. Δηλαδή, το εγγενές proto 3 της Postgres είναι τυπικά μηνύματα που μπορούν να ανταλλάξουν τα frontend και τα backend. Υλοποιούνται στη βιβλιοθήκη Kiwi.
Η βιβλιοθήκη Machinarium είναι μια βιβλιοθήκη υλοποίησης νημάτων. Ένα μικρό κομμάτι αυτού του Machinarium είναι γραμμένο σε assembler. Αλλά μην ανησυχείτε, υπάρχουν μόνο 15 γραμμές.
Αρχιτεκτονική της Οδύσσειας. Υπάρχει ένα κύριο μηχάνημα που τρέχει τις κορουτίνες. Αυτό το μηχάνημα υλοποιεί την αποδοχή εισερχόμενων συνδέσεων TCP και τη διανομή μεταξύ των εργαζομένων.
Μέσα σε έναν εργαζόμενο, μπορεί να λειτουργήσει ένας χειριστής για πολλούς πελάτες. Και επίσης στο κύριο νήμα, περιστρέφεται η κονσόλα και η επεξεργασία των εργασιών crone για την αφαίρεση συνδέσεων που δεν χρειάζονται πλέον στην πισίνα.
Το Odyssey δοκιμάζεται χρησιμοποιώντας την τυπική σουίτα δοκιμών Postgres. Απλώς εκτελούμε τον έλεγχο εγκατάστασης μέσω του Bouncer και μέσω του Odyssey, παίρνουμε ένα null div. Υπάρχουν πολλά τεστ που σχετίζονται με τη μορφοποίηση ημερομηνίας που αποτυγχάνουν ακριβώς το ίδιο στο Bouncer και στο Odyssey.
Επιπλέον, υπάρχουν πολλοί οδηγοί που έχουν τις δικές τους δοκιμές. Και χρησιμοποιούμε τις δοκιμές τους για να δοκιμάσουμε την Οδύσσεια.
Επίσης, λόγω της διαδοχικής μας διαμόρφωσης, πρέπει να δοκιμάσουμε διάφορα πακέτα: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey για να είμαστε σίγουροι ότι εάν το Odyssey βρίσκεται σε κάποιο από τα μέρη του καταρράκτη, λειτουργεί επίσης όπως αναμένεται. .
Ρακέτα
Χρησιμοποιούμε την Odyssey στην παραγωγή. Και δεν θα ήταν δίκαιο αν έλεγα ότι όλα λειτουργούν. Όχι, δηλαδή ναι, αλλά όχι πάντα. Για παράδειγμα, στην παραγωγή απλά όλα λειτουργούσαν, μετά ήρθαν οι φίλοι μας από την PostgreSQL Professional και είπαν ότι είχαμε διαρροή μνήμης. Πραγματικά ήταν, τα φτιάξαμε. Αλλά ήταν απλό.
Στη συνέχεια, διαπιστώσαμε ότι το πρόγραμμα συγκέντρωσης συνδέσεων έχει εισερχόμενες συνδέσεις TLS και εξερχόμενες συνδέσεις TLS. Και οι συνδέσεις χρειάζονται πιστοποιητικά πελάτη και πιστοποιητικά διακομιστή.
Τα πιστοποιητικά διακομιστή Bouncer και Odyssey διαβάζονται ξανά από την pcache, αλλά τα πιστοποιητικά πελάτη δεν χρειάζεται να ξαναδιαβαστούν από την pcache, επειδή το επεκτάσιμο Odyssey τελικά βασίζεται στην απόδοση του συστήματος κατά την ανάγνωση αυτού του πιστοποιητικού. Αυτό μας ξάφνιασε, γιατί δεν ξεκουράστηκε αμέσως. Στην αρχή, κλιμακώθηκε γραμμικά και μετά από 20 εισερχόμενες ταυτόχρονες συνδέσεις, αυτό το πρόβλημα εκδηλώθηκε.
Το Pluggable Authentication Method είναι η δυνατότητα ελέγχου ταυτότητας με ενσωματωμένα εργαλεία lunux. Στο PgBouncer, υλοποιείται με τέτοιο τρόπο ώστε να υπάρχει ένα ξεχωριστό νήμα που περιμένει απάντηση από το PAM και να υπάρχει ένα κύριο νήμα PgBouncer που εξυπηρετεί την τρέχουσα σύνδεση και μπορεί να τους ζητήσει να ζήσουν στο νήμα PAM.
Δεν το εφαρμόσαμε αυτό για έναν απλό λόγο. Έχουμε πολλά ρεύματα. Γιατί το χρειαζόμαστε;
Ως αποτέλεσμα, αυτό μπορεί να δημιουργήσει προβλήματα στο ότι εάν έχετε έλεγχο ταυτότητας PAM και έλεγχο ταυτότητας χωρίς PAM, τότε ένα μεγάλο κύμα ελέγχου ταυτότητας PAM μπορεί να καθυστερήσει σημαντικά τον έλεγχο ταυτότητας εκτός PAM. Είναι από εκείνα τα πράγματα που δεν έχουμε διορθώσει. Αλλά αν θέλετε να το διορθώσετε, μπορείτε να το κάνετε αυτό.
Μια άλλη γκανιότα ήταν με το γεγονός ότι έχουμε ένα νήμα που δέχεται όλες τις εισερχόμενες συνδέσεις. Και μετά μεταφέρονται στην πισίνα των εργαζομένων, όπου θα γίνει η χειραψία TLS.
Ως αποτέλεσμα, εάν έχετε ένα συνεκτικό κύμα 20 συνδέσεων δικτύου, θα γίνουν όλες αποδεκτές. Και από την πλευρά του πελάτη, το libpq θα αρχίσει να αναφέρει χρονικά όρια. Από προεπιλογή, είναι σαν 000 δευτερόλεπτα εκεί.
Εάν δεν μπορούν να εισέλθουν όλοι στη βάση ταυτόχρονα, τότε δεν μπορούν να εισέλθουν στη βάση, γιατί όλα αυτά μπορούν να καλυφθούν από μια μη εκθετική επανάληψη.
Καταλήξαμε να αντιγράψουμε το σχήμα PgBouncer εδώ, ώστε να έχουμε περιορισμό του αριθμού των συνδέσεων TCP που δεχόμαστε.
Αν δούμε ότι δεχόμαστε συνδέσεις, αλλά δεν έχουν χρόνο για χειραψία στο τέλος, τους βάζουμε σε ουρά για να μην καταναλώσουν πόρους της CPU. Αυτό οδηγεί στο γεγονός ότι μπορεί να μην πραγματοποιηθεί ταυτόχρονη χειραψία για όλες τις συνδέσεις που έχουν φτάσει. Αλλά τουλάχιστον κάποιος θα μπει στη βάση δεδομένων, ακόμα κι αν το φορτίο είναι αρκετά δυνατό.
Χάρτης πορείας
Τι θα θέλατε να δείτε στο μέλλον στην Οδύσσεια; Τι είμαστε έτοιμοι να αναπτύξουμε οι ίδιοι και τι περιμένουμε από την κοινότητα;
Για τον Αύγουστο του 2019.
Έτσι ήταν ο οδικός χάρτης της Οδύσσειας τον Αύγουστο:
- Θέλαμε έλεγχο ταυτότητας SCRAM και PAM.
- Θέλαμε να προωθήσουμε αιτήματα ανάγνωσης σε κατάσταση αναμονής.
- Θα ήθελα διαδικτυακή επανεκκίνηση.
- Και η δυνατότητα παύσης στον διακομιστή.
Το ήμισυ αυτού του οδικού χάρτη έχει γίνει και όχι από εμάς. Και αυτό είναι καλό. Ας συζητήσουμε λοιπόν τι έχει απομείνει και ας προσθέσουμε περισσότερα.
? Έχουμε αντίγραφα που, χωρίς την εκπλήρωση αιτημάτων, απλώς θα θερμαίνουν τον αέρα. Τους χρειαζόμαστε για να παρέχουν failover και switchover. Σε περίπτωση προβλημάτων σε ένα από τα κέντρα δεδομένων, θα ήθελα να τα απασχολήσω με κάποια χρήσιμη εργασία. Επειδή δεν μπορούμε να διαμορφώσουμε τους ίδιους κεντρικούς επεξεργαστές, την ίδια μνήμη με διαφορετικό τρόπο, γιατί η αναπαραγωγή δεν θα λειτουργήσει διαφορετικά.
Κατ 'αρχήν, στο Postgres, ξεκινώντας από το 10, είναι δυνατό να ορίσετε session_attrs κατά τη σύνδεση. Μπορείτε να απαριθμήσετε όλους τους κεντρικούς υπολογιστές βάσης δεδομένων στη σύνδεση και να πείτε γιατί πηγαίνετε στη βάση δεδομένων: μόνο εγγραφή ή ανάγνωση. Και ο ίδιος ο οδηγός θα επιλέξει τον πρώτο κεντρικό υπολογιστή στη λίστα που του αρέσει περισσότερο, ο οποίος πληροί τις απαιτήσεις του session_attrs.
Αλλά το πρόβλημα με αυτήν την προσέγγιση είναι ότι δεν ελέγχει την καθυστέρηση αναπαραγωγής. Μπορεί να έχετε κάποιο είδος ρεπλίκα που έχει καθυστερήσει από απαράδεκτο χρόνο για την υπηρεσία σας. Προκειμένου να κάνουμε πλήρη εκτέλεση αιτημάτων ανάγνωσης σε ένα αντίγραφο, στην πραγματικότητα, πρέπει να υποστηρίξουμε στην Odyssey τη δυνατότητα να μην λειτουργεί όταν είναι αδύνατη η ανάγνωση.
Η Odyssey πρέπει να πηγαίνει στη βάση δεδομένων από καιρό σε καιρό και να ζητά την απόσταση αναπαραγωγής από την κύρια. Και αν έχει φτάσει το όριο, μην αφήνετε νέα αιτήματα στη βάση δεδομένων, πείτε στον πελάτη ότι πρέπει να ξεκινήσετε ξανά τις συνδέσεις και, πιθανώς, να επιλέξετε έναν άλλο κεντρικό υπολογιστή για την εκτέλεση αιτημάτων. Αυτό θα επιτρέψει στη βάση δεδομένων να επαναφέρει γρήγορα την καθυστέρηση αναπαραγωγής και να επιστρέψει ξανά για να απαντήσει με ένα ερώτημα.
Είναι δύσκολο να ονομάσουμε τις ημερομηνίες υλοποίησης, επειδή είναι ανοιχτού κώδικα. Αλλά, ελπίζω, όχι 2,5 χρόνια όπως οι συνάδελφοι από το PgBouncer. Αυτό είναι το χαρακτηριστικό που θα ήθελα να δω στην Οδύσσεια.
. Τώρα μπορείτε να δημιουργήσετε μια προετοιμασμένη δήλωση με δύο τρόπους. Αρχικά, μπορείτε να εκτελέσετε μια εντολή SQL, δηλαδή "prepared". Για να κατανοήσουμε αυτήν την εντολή SQL, πρέπει να μάθουμε πώς να κατανοούμε την SQL στην πλευρά του Bouncer. Αυτό θα ήταν υπερβολικό γιατί είναι υπερβολικό αφού χρειαζόμαστε ολόκληρο τον αναλυτή. Δεν μπορούμε να αναλύσουμε κάθε εντολή SQL.
Αλλά υπάρχει μια προετοιμασμένη δήλωση σε επίπεδο πρωτοκόλλου μηνυμάτων στο proto3. Και αυτό είναι το μέρος όπου η πληροφορία ότι δημιουργείται η προετοιμασμένη δήλωση έρχεται σε δομημένη μορφή. Και θα μπορούσαμε να υποστηρίξουμε την κατανόηση ότι σε κάποια σύνδεση διακομιστή ο πελάτης ζήτησε να δημιουργήσει έτοιμες δηλώσεις. Και ακόμα κι αν η συναλλαγή είναι κλειστή, πρέπει να διατηρήσουμε τον διακομιστή και τον πελάτη συνδεδεμένο.
Αλλά εδώ προκύπτει μια ασυμφωνία στο διάλογο, επειδή κάποιος λέει ότι πρέπει να κατανοήσετε ποιες προετοιμασμένες δηλώσεις δημιούργησε ο πελάτης και να μοιραστείτε τη σύνδεση διακομιστή μεταξύ όλων των πελατών που δημιούργησαν αυτήν τη σύνδεση διακομιστή, δηλαδή ποιος δημιούργησε μια τέτοια έτοιμη δήλωση.
Ο Andres Freund είπε ότι αν έρθει σε εσάς ένας πελάτης που είχε ήδη δημιουργήσει μια τέτοια προετοιμασμένη δήλωση σε άλλη σύνδεση διακομιστή, τότε δημιουργήστε την για αυτόν. Αλλά φαίνεται να είναι λίγο λάθος να εκτελούνται ερωτήματα στη βάση δεδομένων αντί για τον πελάτη, αλλά από τη σκοπιά ενός προγραμματιστή που γράφει ένα πρωτόκολλο για αλληλεπίδραση με τη βάση δεδομένων, θα ήταν βολικό να του δοθεί απλώς μια σύνδεση δικτύου που έχει ένα τέτοιο προετοιμασμένο αίτημα.
Και ένα ακόμη χαρακτηριστικό που πρέπει να εφαρμόσουμε. Τώρα έχουμε παρακολούθηση συμβατή με το PgBouncer. Μπορούμε να επιστρέψουμε τον μέσο χρόνο εκτέλεσης του ερωτήματος. Αλλά ο μέσος χρόνος είναι η μέση θερμοκρασία στο νοσοκομείο: κάποιος είναι κρύος, κάποιος είναι ζεστός - κατά μέσο όρο όλοι είναι υγιείς. Δεν είναι αλήθεια.
Χρειάζεται να εφαρμόσουμε υποστήριξη για εκατοστημόρια, τα οποία θα έδειχναν ότι υπάρχουν αργά αιτήματα που καταναλώνουν πόρους και θα καθιστούσαν την παρακολούθηση πιο αποδεκτή.
Το πιο σημαντικό είναι ότι θέλω την έκδοση 1.0 (η έκδοση 1.1 έχει ήδη κυκλοφορήσει). Γεγονός είναι ότι τώρα το Odyssey βρίσκεται στην έκδοση 1.0rc, δηλαδή υποψήφια έκδοση. Και όλη η γκανιότα που ανέφερα διορθώθηκε ακριβώς με την ίδια έκδοση, εκτός από τη διαρροή μνήμης.
Τι θα σημαίνει για εμάς η έκδοση 1.0; Ξεδιπλώνουμε την Οδύσσεια στις βάσεις μας. Εκτελείται ήδη στις βάσεις δεδομένων μας, αλλά όταν φτάσει στο σημείο των 1 αιτημάτων ανά δευτερόλεπτο, τότε μπορούμε να πούμε ότι αυτή είναι μια έκδοση έκδοσης και αυτή είναι μια έκδοση που μπορεί να ονομαστεί 000.
Αρκετά άτομα στην κοινότητα έχουν ζητήσει περισσότερη παύση και SCRAM στην έκδοση 1.0. Αλλά αυτό θα σημαίνει ότι θα χρειαστεί να κυκλοφορήσουμε την επόμενη έκδοση στην παραγωγή, επειδή ούτε το SCRAM ούτε η παύση έχουν συγχωνευθεί ακόμη. Αλλά, πιθανότατα, αυτό το ζήτημα θα επιλυθεί αρκετά γρήγορα.
Περιμένω το αίτημα έλξης σου. Και θα ήθελα επίσης να ακούσω τι προβλήματα έχετε με το Bouncer. Ας τα συζητήσουμε. Ίσως μπορούμε να εφαρμόσουμε κάποιες λειτουργίες που χρειάζεστε.
Αυτό ολοκληρώνει το μέρος μου, θα ήθελα να ακούσω από εσάς. Ευχαριστώ!
ερωτήσεις
Αν βάλω το δικό μου application_name, θα πεταχτεί σωστά, συμπεριλαμβανομένης της συγκέντρωσης συναλλαγών στην Odyssey;
Οδύσσεια ή Bouncer;
Στην Οδύσσεια. Το Bouncer πετιέται.
Θα φτιάξουμε ένα σετ.
Και αν η πραγματική μου σύνδεση υπερπηδήσει σε άλλες συνδέσεις, θα μεταδοθεί;
Θα φτιάξουμε ένα σύνολο από όλες τις παραμέτρους που παρατίθενται. Δεν μπορώ να καταλάβω αν το application_name βρίσκεται σε αυτήν τη λίστα. Φαίνεται ότι τον είδε εκεί. Θα ορίσουμε όλες τις ίδιες παραμέτρους. Με ένα αίτημα, το σετ θα κάνει ό,τι εγκαταστάθηκε από τον πελάτη κατά την εκκίνηση.
Ευχαριστώ Andrey για την αναφορά! Καλή αναφορά! Χαίρομαι που η Odyssey εξελίσσεται ολοένα και πιο γρήγορα κάθε λεπτό. Θα ήθελα να συνεχίσω το ίδιο. Σας έχουμε ήδη ζητήσει να έχετε μια σύνδεση πολλαπλών πηγών δεδομένων, ώστε το Odyssey να μπορεί να συνδεθεί ταυτόχρονα σε διαφορετικές βάσεις δεδομένων, δηλαδή στο slave master, και στη συνέχεια να συνδεθεί αυτόματα με το νέο master μετά από μια ανακατεύθυνση.
Ναι, φαίνεται να θυμάμαι αυτή τη συζήτηση. Τώρα υπάρχουν αρκετές αποθήκες. Αλλά δεν υπάρχει εναλλαγή μεταξύ τους. Από την πλευρά μας, πρέπει να ρωτήσουμε τον διακομιστή ότι είναι ακόμα ζωντανός και να καταλάβουμε ότι έχει συμβεί ένα failover, ποιος θα καλέσει το pg_recovery. Έχω έναν τυπικό τρόπο να καταλάβω ότι δεν ήρθαμε στον κύριο. Και πρέπει να καταλάβουμε κάπως από τα λάθη ή πώς; Δηλαδή, η ιδέα είναι ενδιαφέρουσα, συζητείται. Γράψτε περισσότερα σχόλια. Εάν έχετε χέρια που εργάζονται που ξέρουν το C, τότε αυτό είναι γενικά υπέροχο.
Το θέμα της κλιμάκωσης μεταξύ των αντιγράφων είναι επίσης ενδιαφέρον για εμάς, επειδή θέλουμε να κάνουμε την υιοθέτηση αναπαραγόμενων συμπλεγμάτων όσο το δυνατόν πιο απλή για τους προγραμματιστές εφαρμογών. Εδώ όμως θα ήθελα περισσότερα σχόλια, δηλαδή πώς να το κάνουμε, πώς να το κάνουμε καλά.
Το ερώτημα αφορά επίσης τα αντίγραφα. Αποδεικνύεται ότι έχετε έναν κύριο και πολλά αντίγραφα. Και είναι ξεκάθαρο ότι πάνε στο replica λιγότερο συχνά παρά στον master για συνδέσεις, γιατί μπορεί να έχουν διαφορά. Είπατε ότι η διαφορά στα δεδομένα μπορεί να είναι τέτοια που η επιχείρησή σας δεν θα ικανοποιήσει και δεν θα πάτε εκεί μέχρι να αναπαραχθεί. Ταυτόχρονα, εάν δεν πήγατε εκεί για μεγάλο χρονικό διάστημα και μετά αρχίσατε να πηγαίνετε, τότε τα δεδομένα που χρειάζεστε δεν θα είναι άμεσα διαθέσιμα. Δηλαδή, αν πηγαίνουμε συνεχώς στον κύριο, τότε η κρυφή μνήμη ζεσταίνεται εκεί και η κρυφή μνήμη είναι λίγο πίσω στο αντίγραφο.
Ναι είναι αλήθεια. Δεν θα υπάρχουν μπλοκ δεδομένων στο pcache που θέλετε, στην πραγματική κρυφή μνήμη δεν θα υπάρχουν πληροφορίες για πίνακες που θέλετε, δεν θα υπάρχουν αναλυμένα ερωτήματα στα σχέδια, τίποτα απολύτως.
Και όταν έχετε κάποιο είδος συμπλέγματος και προσθέτετε ένα νέο αντίγραφο εκεί, τότε ενώ ξεκινά, όλα είναι κακά σε αυτό, δηλαδή μεγαλώνει την κρυφή μνήμη του.
Πήρα την ιδέα. Η σωστή προσέγγιση θα ήταν να εκτελέσετε πρώτα ένα μικρό ποσοστό ερωτημάτων στο αντίγραφο, το οποίο θα προθέρμανση της κρυφής μνήμης. Σε γενικές γραμμές, έχουμε μια προϋπόθεση ότι δεν πρέπει να είμαστε περισσότερο από 10 δευτερόλεπτα πίσω από τον κύριο. Και αυτή η συνθήκη δεν πρέπει να περιλαμβάνεται σε ένα κύμα, αλλά ομαλά για ορισμένους πελάτες.
Ναι, αυξήστε το βάρος.
Αυτή είναι μια καλή ιδέα. Αλλά πρώτα πρέπει να εφαρμόσετε αυτόν τον τερματισμό λειτουργίας. Πρώτα πρέπει να σβήσουμε και μετά θα σκεφτούμε πώς να το ενεργοποιήσουμε. Αυτή είναι μια εξαιρετική δυνατότητα για ομαλή ενεργοποίηση.
Το nginx έχει αυτήν την επιλογή slowly start στο σύμπλεγμα για τον διακομιστή. Και σταδιακά αυξάνει το φορτίο.
Ναι, υπέροχη ιδέα, θα το δοκιμάσουμε όταν φτάσουμε σε αυτό.
Πηγή: www.habr.com