Σας προτείνω να διαβάσετε τη μεταγραφή της αναφοράς από τις αρχές του 2019 από τον Andrey Borodin "Αντίγραφα ασφαλείας με το WAL-G. Τι υπάρχει το 2019;"
Γεια σε όλους! Το όνομά μου είναι Andrey Borodin. Είμαι προγραμματιστής στο Yandex. Με ενδιαφέρει η PostgreSQL από το 2016, αφού μίλησα με τους προγραμματιστές και μου είπαν ότι όλα είναι απλά - παίρνετε τον πηγαίο κώδικα και τον δημιουργείτε και όλα θα πάνε καλά. Και από τότε δεν μπορώ να σταματήσω - γράφω κάθε λογής διαφορετικά πράγματα.
Ένα από τα πράγματα που εργάζομαι είναι ένα εφεδρικό σύστημα. . Γενικά, στη Yandex εργαζόμαστε για συστήματα δημιουργίας αντιγράφων ασφαλείας στη PostgreSQL εδώ και πολύ καιρό. Και μπορείτε να βρείτε στο Διαδίκτυο μια σειρά από έξι αναφορές σχετικά με τον τρόπο δημιουργίας εφεδρικών συστημάτων. Και κάθε χρόνο εξελίσσονται λίγο, αναπτύσσονται λίγο και γίνονται πιο αξιόπιστα.
Αλλά σήμερα η έκθεση δεν αφορά μόνο το τι κάναμε, αλλά και το πόσο απλό είναι και τι είναι. Πόσοι από εσάς έχετε ήδη παρακολουθήσει τις αναφορές μου για το WAL-G; Είναι καλό που δεν παρακολούθησαν αρκετοί, γιατί θα ξεκινήσω από το πιο απλό.
Εάν ξαφνικά έχετε ένα σύμπλεγμα PostgreSQL και νομίζω ότι όλοι έχουν μαζί τους μερικά από αυτά, και ξαφνικά δεν υπάρχει ακόμα εφεδρικό σύστημα, τότε πρέπει να αποκτήσετε οποιονδήποτε αποθηκευτικό χώρο S3 ή συμβατό με το Google Cloud αποθηκευτικό χώρο.
Για παράδειγμα, μπορείτε να έρθετε στο περίπτερό μας και να πάρετε έναν κωδικό προσφοράς για το Yandex Object Storage, το οποίο είναι συμβατό με το S3.
Στη συνέχεια δημιουργήστε έναν κάδο. Είναι απλώς ένα δοχείο για πληροφορίες.
Δημιουργήστε έναν χρήστη υπηρεσίας.
Δημιουργήστε ένα κλειδί πρόσβασης για τον χρήστη της υπηρεσίας: aws-s3-key.
Κατεβάστε την πιο πρόσφατη σταθερή έκδοση του WAL-G.
Σε τι διαφέρουν οι προ-κυκλοφορίες μας από τις κυκλοφορίες; Μου ζητείται συχνά να απελευθερωθώ νωρίς. Και αν δεν υπάρχει σφάλμα στην έκδοση για αρκετό χρόνο, για παράδειγμα, ένα μήνα, τότε το απελευθερώνω. Εδώ είναι αυτή η κυκλοφορία από τον Νοέμβριο. Και αυτό σημαίνει ότι κάθε μήνα βρίσκαμε κάποιο είδος σφάλματος, συνήθως σε μη κρίσιμη λειτουργικότητα, αλλά δεν έχουμε κυκλοφορήσει ακόμα κάποια έκδοση. Η προηγούμενη έκδοση είναι μόλις τον Νοέμβριο. Δεν υπάρχουν γνωστά σφάλματα σε αυτό, δηλαδή σφάλματα προστέθηκαν καθώς προχωρούσε το έργο.
Αφού κατεβάσετε το WAL-G, μπορείτε να εκτελέσετε μια απλή εντολή "backup list", μεταβιβάζοντας τις μεταβλητές περιβάλλοντος. Και θα συνδεθεί στο Object Storage και θα σας πει τι αντίγραφα ασφαλείας έχετε. Στην αρχή, φυσικά, δεν πρέπει να έχετε αντίγραφα ασφαλείας. Το θέμα αυτής της διαφάνειας είναι να δείξει ότι όλα είναι αρκετά απλά. Αυτή είναι μια εντολή κονσόλας που δέχεται μεταβλητές περιβάλλοντος και εκτελεί υποεντολές.
Μετά από αυτό, μπορείτε να δημιουργήσετε το πρώτο σας αντίγραφο ασφαλείας. Πείτε "backup-push" στο WAL-G και καθορίστε στο WAL-G τη θέση pgdata του συμπλέγματός σας. Και πιθανότατα, η PostgreSQL θα σας πει, εάν δεν έχετε ήδη ένα εφεδρικό σύστημα, ότι πρέπει να ενεργοποιήσετε τη "λειτουργία αρχειοθέτησης".
Αυτό σημαίνει ότι πρέπει να μεταβείτε στις ρυθμίσεις και να ενεργοποιήσετε το "archive_mode = on" και να προσθέσετε το "archive_command", το οποίο είναι επίσης μια υποεντολή στο WAL-G. Αλλά για κάποιο λόγο οι άνθρωποι χρησιμοποιούν συχνά σενάρια γραμμής για αυτό το θέμα και το τυλίγουν γύρω από το WAL-G. Παρακαλώ μην το κάνετε αυτό. Χρησιμοποιήστε τη λειτουργικότητα που βρίσκεται στο WAL-G. Αν σας λείπει κάτι, γράψτε στο . Το WAL-G υποθέτει ότι είναι το μόνο πρόγραμμα που εκτελείται στο archive_command.
Χρησιμοποιούμε το WAL-G κυρίως για τη δημιουργία ενός συμπλέγματος Υψηλής Διαθεσιμότητας στη διαχείριση Βάσης Δεδομένων Yandex.
Και συνήθως χρησιμοποιείται σε μια τοπολογία ενός Master και πολλών επαναλήψεων. Ταυτόχρονα, δημιουργεί ένα αντίγραφο ασφαλείας στο Yandex Object Storage.
Τα πιο συνηθισμένα σενάρια είναι η δημιουργία αντιγράφων ενός συμπλέγματος χρησιμοποιώντας την ανάκτηση σημείου χρόνου. Αλλά σε αυτήν την περίπτωση, η απόδοση του εφεδρικού συστήματος δεν είναι τόσο σημαντική για εμάς. Απλώς πρέπει να ανεβάσουμε ένα νέο σύμπλεγμα από το αντίγραφο ασφαλείας.
Συνήθως, χρειαζόμαστε εφεδρική απόδοση συστήματος όταν προσθέτουμε έναν νέο κόμβο. Γιατί είναι σημαντικό? Συνήθως οι άνθρωποι προσθέτουν έναν νέο κόμβο σε ένα σύμπλεγμα επειδή το υπάρχον σύμπλεγμα δεν μπορεί να χειριστεί το φορτίο ανάγνωσης. Πρέπει να προσθέσουν ένα νέο αντίγραφο. Εάν προσθέσουμε το φορτίο από το pg_basebackup στο Master, τότε το Master ενδέχεται να καταρρεύσει. Επομένως, ήταν πολύ σημαντικό για εμάς να μπορέσουμε να ανεβάσουμε γρήγορα έναν νέο κόμβο από το αρχείο, δημιουργώντας ελάχιστο φορτίο στο Master.
Και μια άλλη παρόμοια κατάσταση. Αυτή είναι η ανάγκη επανεκκίνησης του παλιού Master μετά την εναλλαγή του Cluster Master από το Data Center με το οποίο χάθηκε η συνδεσιμότητα.
- Ως αποτέλεσμα, κατά τη διαμόρφωση των απαιτήσεων για το σύστημα αντιγραφής, συνειδητοποιήσαμε ότι το pg_basebackup δεν είναι κατάλληλο για εμάς όταν λειτουργούμε στο cloud.
- Θέλαμε να μπορούμε να συμπιέσουμε τα δεδομένα μας. Αλλά σχεδόν οποιοδήποτε εφεδρικό σύστημα εκτός από αυτό που περιλαμβάνεται στο κουτί θα παρέχει συμπίεση δεδομένων.
- Θέλαμε να παραλληλίσουμε τα πάντα επειδή ένας χρήστης στο cloud αγοράζει μεγάλο αριθμό πυρήνων επεξεργαστή. Αν όμως δεν έχουμε παραλληλισμό σε κάποια λειτουργία, τότε ένας μεγάλος αριθμός πυρήνων γίνεται άχρηστος.
- Χρειαζόμαστε κρυπτογράφηση γιατί συχνά τα δεδομένα δεν είναι δικά μας και δεν μπορούν να αποθηκευτούν σε καθαρό κείμενο. Παρεμπιπτόντως, η συνεισφορά μας στο WAL-G ξεκίνησε με την κρυπτογράφηση. Ολοκληρώσαμε την κρυπτογράφηση στο WAL-G και μετά μας ρωτήθηκε: "Ίσως κάποιος από εμάς θα αναπτύξει το έργο;" Και από τότε δουλεύω με την WAL-G για περισσότερο από ένα χρόνο.
- Χρειαζόμασταν επίσης περιορισμό των πόρων, επειδή με την πάροδο του χρόνου χρησιμοποιώντας το σύννεφο, ανακαλύψαμε ότι μερικές φορές οι άνθρωποι έχουν ένα σημαντικό φορτίο παντοπωλείου τη νύχτα και αυτό το φορτίο δεν μπορεί να παρέμβει. Γι' αυτό προσθέσαμε περιορισμό πόρων.
- Καθώς και καταχώριση και διαχείριση.
- Και επαλήθευση.
Εξετάσαμε πολλά διαφορετικά εργαλεία. Ευτυχώς, έχουμε μια τεράστια επιλογή στο PostgreSQL. Και παντού κάτι μας έλειπε, από κάποιο μια μικρή λειτουργία, από κάποια ένα μικρό χαρακτηριστικό.
Και αφού εξετάσαμε τα υπάρχοντα συστήματα, καταλήξαμε στο συμπέρασμα ότι θα αναπτύξουμε το WAL-G. Τότε ήταν ένα νέο έργο. Ήταν πολύ εύκολο να επηρεαστεί η ανάπτυξη προς την υποδομή cloud του εφεδρικού συστήματος.
Η κύρια ιδεολογία στην οποία τηρούμε είναι ότι το WAL-G πρέπει να είναι τόσο απλό όσο μια μπαλαλάικα.
Το WAL-G έχει 4 εντολές. Αυτό:
WAL-PUSH – αρχειοθετήστε τον άξονα.
WAL-FETCH - αποκτήστε έναν άξονα.
BACKUP-PUSH – δημιουργήστε αντίγραφο ασφαλείας.
BACKUP-FETCH – λάβετε αντίγραφο ασφαλείας από το σύστημα δημιουργίας αντιγράφων ασφαλείας.
Στην πραγματικότητα, το WAL-G έχει επίσης τη διαχείριση αυτών των αντιγράφων ασφαλείας, δηλαδή την καταχώριση και τη διαγραφή εγγραφών και αντιγράφων ασφαλείας στο ιστορικό που δεν χρειάζονται πλέον αυτή τη στιγμή.
Μία από τις σημαντικές λειτουργίες για εμάς είναι η λειτουργία δημιουργίας αντιγράφων δέλτα.
Τα αντίγραφα Delta σημαίνουν ότι δεν δημιουργούμε πλήρες αντίγραφο ασφαλείας ολόκληρου του συμπλέγματος, αλλά μόνο των αλλαγμένων σελίδων των αλλαγμένων αρχείων στο σύμπλεγμα. Φαίνεται ότι λειτουργικά αυτό μοιάζει πολύ με την ικανότητα ανάκτησης χρησιμοποιώντας το WAL. Μπορούμε όμως να δημιουργήσουμε παράλληλα ένα αντίγραφο ασφαλείας δέλτα με ένα νήμα WAL. Αντίστοιχα, όταν έχουμε ένα βασικό αντίγραφο ασφαλείας το Σάββατο, το delta backup καθημερινά και την Πέμπτη αποτυγχάνουμε, τότε πρέπει να δημιουργήσουμε 4 αντίγραφα ασφαλείας delta και 10 ώρες WAL. Θα χρειαστεί περίπου τον ίδιο χρόνο, επειδή τα αντίγραφα ασφαλείας delta κυλίονται παράλληλα.
Δέλτα που βασίζονται σε LSN - αυτό σημαίνει ότι κατά τη δημιουργία ενός αντιγράφου ασφαλείας, θα χρειαστεί να συνδυάσουμε κάθε σελίδα και να ελέγξουμε το LSN της με το LSN του προηγούμενου αντιγράφου ασφαλείας για να καταλάβουμε ότι έχει αλλάξει. Οποιαδήποτε σελίδα θα μπορούσε ενδεχομένως να περιέχει αλλαγμένα δεδομένα θα πρέπει να υπάρχει στο αντίγραφο ασφαλείας delta.
Όπως είπα, δόθηκε μεγάλη προσοχή στον παραλληλισμό.
Αλλά το API αρχειοθέτησης στο PostgreSQL είναι συνεπές. Η PostgreSQL αρχειοθετεί ένα αρχείο WAL και κατά την επαναφορά ζητά ένα αρχείο WAL. Αλλά όταν η βάση δεδομένων ζητά ένα αρχείο WAL χρησιμοποιώντας την εντολή "WAL-FETCH", καλούμε την εντολή "WAL-PREFETCH", η οποία προετοιμάζει τα επόμενα 8 αρχεία για να ανακτήσουν δεδομένα από την αποθήκευση αντικειμένων παράλληλα.
Και όταν η βάση δεδομένων μας ζητά να αρχειοθετήσουμε ένα αρχείο, κοιτάμε το archive_status και βλέπουμε αν υπάρχουν άλλα αρχεία WAL. Και προσπαθούμε επίσης να κατεβάσουμε το WAL παράλληλα. Αυτό παρέχει σημαντικό κέρδος απόδοσης και μειώνει σημαντικά την απόσταση στον αριθμό των μη αρχειοθετημένων WAL. Πολλοί προγραμματιστές συστημάτων αντιγράφων ασφαλείας πιστεύουν ότι αυτό είναι ένα τόσο επικίνδυνο σύστημα επειδή βασιζόμαστε στις γνώσεις μας για τα εσωτερικά του κώδικα που δεν είναι το PostgreSQL API. Η PostgreSQL δεν εγγυάται την παρουσία του φακέλου archive_status για εμάς και δεν εγγυάται τη σημασιολογία, την παρουσία σημάτων ετοιμότητας για αρχεία WAL εκεί. Παρόλα αυτά, μελετάμε τον πηγαίο κώδικα, βλέπουμε ότι είναι έτσι και προσπαθούμε να τον εκμεταλλευτούμε. Και ελέγχουμε την κατεύθυνση στην οποία αναπτύσσεται η PostgreSQL· εάν ξαφνικά σπάσει αυτός ο μηχανισμός, θα σταματήσουμε να τον χρησιμοποιούμε.
Στην καθαρή του μορφή, το WAL delta που βασίζεται σε LSN απαιτεί την ανάγνωση οποιουδήποτε αρχείου συμπλέγματος του οποίου ο χρόνος λειτουργίας στο σύστημα αρχείων έχει αλλάξει από το προηγούμενο αντίγραφο ασφαλείας. Ζήσαμε με αυτό για πολύ καιρό, σχεδόν ένα χρόνο. Και στο τέλος καταλήξαμε στο συμπέρασμα ότι έχουμε δέλτα WAL.
Αυτό σημαίνει ότι κάθε φορά που αρχειοθετούμε το WAL στο Master, όχι μόνο το συμπιέζουμε, το κρυπτογραφούμε και το στέλνουμε στο δίκτυο, αλλά το διαβάζουμε και ταυτόχρονα. Αναλύουμε και διαβάζουμε τα αρχεία σε αυτό. Καταλαβαίνουμε ποια μπλοκ έχουν αλλάξει και συλλέγουμε αρχεία delta.
Ένα αρχείο delta περιγράφει ένα συγκεκριμένο εύρος αρχείων WAL, περιγράφει πληροφορίες σχετικά με τα μπλοκ που άλλαξαν σε αυτό το εύρος του WAL. Και στη συνέχεια αυτά τα αρχεία δέλτα αρχειοθετούνται επίσης.
Εδώ βρισκόμαστε αντιμέτωποι με το γεγονός ότι παραλληλίσαμε τα πάντα αρκετά γρήγορα, αλλά δεν μπορούμε να διαβάσουμε παράλληλα μια διαδοχική ιστορία, γιατί σε ένα συγκεκριμένο τμήμα μπορεί να συναντήσουμε το τέλος του προηγούμενου δίσκου WAL, με το οποίο δεν έχουμε να συνδέσουμε ακόμα τίποτα, γιατί Η παράλληλη ανάγνωση οδήγησε στο ότι πρώτα αναλύουμε το μέλλον, το οποίο δεν έχει ακόμη παρελθόν.
Ως αποτέλεσμα, έπρεπε να βάλουμε ακατανόητα κομμάτια σε αρχεία _delta_partial. Ως αποτέλεσμα, όταν επιστρέψουμε στο παρελθόν, θα κολλήσουμε τα κομμάτια του δίσκου WAL σε ένα, μετά θα τον αναλύσουμε και θα καταλάβουμε τι άλλαξε σε αυτόν.
Εάν στην ιστορία της ανάλυσης του άξονα υπάρχει τουλάχιστον ένα σημείο όπου δεν καταλαβαίνουμε τι συμβαίνει, τότε, κατά συνέπεια, κατά την επόμενη δημιουργία αντιγράφων ασφαλείας θα αναγκαστούμε να διαβάσουμε ξανά ολόκληρο το σύμπλεγμα, όπως κάναμε με ένα κανονικό LSN -με βάση το δέλτα.
Ως αποτέλεσμα, όλα τα βάσανά μας οδήγησαν στο γεγονός ότι δημιουργήσαμε ανοιχτό κώδικα τη βιβλιοθήκη ανάλυσης WAL-G. Από όσο γνωρίζω, κανείς δεν το χρησιμοποιεί ακόμα, αλλά αν κάποιος θέλει, γράψτε το και χρησιμοποιήστε το, είναι στο δημόσιο τομέα. (Ενημερώθηκε ο σύνδεσμος )
Ως αποτέλεσμα, όλες οι ροές πληροφοριών φαίνονται αρκετά περίπλοκες. Το Master μας αρχειοθετεί τον άξονα και αρχειοθετεί αρχεία δέλτα. Και το αντίγραφο που δημιουργεί το αντίγραφο ασφαλείας πρέπει να λαμβάνει αρχεία δέλτα κατά τη διάρκεια του χρόνου που έχει περάσει μεταξύ των αντιγράφων ασφαλείας. Σε αυτήν την περίπτωση, μέρη του ιστορικού θα πρέπει να προστεθούν μαζικά και να αναλυθούν, επειδή δεν χωράει ολόκληρο το ιστορικό σε μεγάλα τμήματα. Και μόνο μετά από αυτό το αντίγραφο μπορεί να αρχειοθετήσει ένα πλήρες αντίγραφο ασφαλείας delta.
Στα γραφήματα όλα φαίνονται πολύ πιο απλά. Αυτή είναι μια λήψη από ένα από τα πραγματικά μας συμπλέγματα. Έχουμε βασισμένο σε LSN, κατασκευασμένο σε μια μέρα. Και βλέπουμε ότι το αντίγραφο ασφαλείας delta που βασίζεται στο LSN λειτουργούσε από τις τρεις το πρωί έως τις πέντε το πρωί. Αυτό είναι το φορτίο στον αριθμό των πυρήνων του επεξεργαστή. Το WAL-delta μας πήρε περίπου 20 λεπτά εδώ, δηλαδή έγινε σημαντικά πιο γρήγορο, αλλά ταυτόχρονα υπήρχε και πιο έντονη ανταλλαγή μέσω του δικτύου.
Επειδή έχουμε πληροφορίες σχετικά με το ποια μπλοκ άλλαξαν και σε ποια χρονική στιγμή στο ιστορικό της βάσης δεδομένων, προχωρήσαμε περισσότερο και αποφασίσαμε να ενσωματώσουμε τη λειτουργικότητα - μια επέκταση PostgreSQL που ονομάζεται "pg_prefaulter"
Αυτό σημαίνει ότι όταν η βάση αναμονής εκτελεί την εντολή επαναφοράς, λέει στο WAL-G να ανακτήσει το επόμενο αρχείο WAL. Κατανοούμε περίπου ποια μπλοκ δεδομένων θα έχει πρόσβαση η διαδικασία ανάκτησης WAL στο εγγύς μέλλον και ξεκινά μια λειτουργία ανάγνωσης σε αυτά τα μπλοκ. Αυτό έγινε για να αυξηθεί η απόδοση των ελεγκτών SSD. Επειδή το ρολό WAL θα φτάσει στη σελίδα που πρέπει να αλλάξει. Αυτή η σελίδα βρίσκεται στο δίσκο και δεν βρίσκεται στην προσωρινή μνήμη σελίδων. Και θα περιμένει συγχρονισμένα να φτάσει αυτή η σελίδα. Αλλά κοντά είναι το WAL-G, το οποίο γνωρίζει ότι στα επόμενα εκατοντάδες megabyte του WAL θα χρειαστούμε ορισμένες σελίδες και ταυτόχρονα αρχίζει να τις ζεσταίνει. Εκκινεί πολλαπλές προσβάσεις στο δίσκο έτσι ώστε να εκτελούνται παράλληλα. Αυτό λειτουργεί καλά σε μονάδες SSD, αλλά, δυστυχώς, δεν είναι απολύτως εφαρμόσιμο για σκληρό δίσκο, επειδή παρεμβαίνουμε σε αυτό μόνο με τις προτροπές μας.
Αυτό είναι τώρα στον κώδικα.
Υπάρχουν χαρακτηριστικά που θα θέλαμε να προσθέσουμε.
Αυτή η εικόνα δείχνει ότι το WAL-delta διαρκεί σχετικά μικρό χρόνο. Και αυτό είναι η ανάγνωση των αλλαγών που συνέβησαν στη βάση δεδομένων κατά τη διάρκεια της ημέρας. Θα μπορούσαμε να κάνουμε WAL-delta όχι μόνο τη νύχτα, γιατί δεν είναι πλέον σημαντική πηγή φορτίου. Μπορούμε να διαβάζουμε WAL-delta κάθε λεπτό γιατί είναι φθηνό. Σε ένα λεπτό μπορούμε να σαρώσουμε όλες τις αλλαγές που έχουν συμβεί στο σύμπλεγμα. Και αυτό θα μπορούσε να ονομαστεί "instant WAL-delta".
Το θέμα είναι ότι όταν επαναφέρουμε το σύμπλεγμα, μειώνουμε τον αριθμό των ιστοριών που πρέπει να κυκλώνουμε διαδοχικά. Δηλαδή, η ποσότητα του WAL που κυλά η PostgreSQL θα πρέπει να μειωθεί, γιατί χρειάζεται σημαντικός χρόνος.
Αλλά δεν είναι μόνο αυτό. Εάν ξέρουμε ότι κάποιο μπλοκ θα αλλάξει σε σημείο εφεδρικής συνέπειας, δεν μπορούμε να το αλλάξουμε στο παρελθόν. Δηλαδή, τώρα έχουμε βελτιστοποίηση αρχείου προς αρχείο της προώθησης WAL-delta. Αυτό σημαίνει ότι εάν, για παράδειγμα, την Τρίτη κάποιος πίνακας διαγράφηκε εντελώς ή ορισμένα αρχεία διαγράφηκαν εξ ολοκλήρου από τον πίνακα, τότε όταν το delta ανακυκλωθεί τη Δευτέρα και αποκατασταθεί το pg_basebackup του Σαββάτου, δεν θα δημιουργήσουμε καν αυτά τα δεδομένα.
Θέλουμε να επεκτείνουμε αυτήν την τεχνολογία στο επίπεδο σελίδας. Δηλαδή, εάν κάποιο μέρος του αρχείου αλλάξει τη Δευτέρα, αλλά θα αντικατασταθεί την Τετάρτη, τότε κατά την επαναφορά σε ένα σημείο την Πέμπτη, δεν χρειάζεται να γράψουμε τις πρώτες εκδόσεις των σελίδων στο δίσκο.
Αλλά αυτή είναι ακόμα μια ιδέα που συζητείται ενεργά μέσα μας, αλλά δεν έχει φτάσει ακόμα στον κώδικα.
Θέλουμε να δημιουργήσουμε ένα ακόμη χαρακτηριστικό στο WAL-G. Θέλουμε να το κάνουμε επεκτάσιμο γιατί πρέπει να υποστηρίζουμε διαφορετικές βάσεις δεδομένων και θα θέλαμε να μπορούμε να προσεγγίζουμε τη διαχείριση αντιγράφων ασφαλείας με τον ίδιο τρόπο. Αλλά το πρόβλημα είναι ότι τα MySQL API είναι ριζικά διαφορετικά. Στη MySQL, το PITR δεν βασίζεται στο φυσικό αρχείο καταγραφής WAL, αλλά στο binlog. Και δεν έχουμε σύστημα αρχειοθέτησης στη MySQL που θα έλεγε σε κάποιο εξωτερικό σύστημα ότι αυτό το binlog έχει ολοκληρωθεί και πρέπει να αρχειοθετηθεί. Πρέπει να σταθούμε κάπου στο cron με τη βάση δεδομένων και να ελέγξουμε αν υπάρχει κάτι έτοιμο;
Και με τον ίδιο τρόπο, κατά τη διάρκεια μιας επαναφοράς MySQL, δεν υπάρχει καμία εντολή επαναφοράς που θα μπορούσε να πει στο σύστημα ότι χρειάζομαι τέτοια αρχεία. Πριν ξεκινήσετε την ανακατασκευή του συμπλέγματός σας, πρέπει να γνωρίζετε ποια αρχεία θα χρειαστείτε. Εσείς οι ίδιοι πρέπει να μαντέψετε ποια αρχεία θα χρειαστείτε. Αλλά αυτά τα προβλήματα μπορεί να παρακαμφθούν με κάποιο τρόπο. (Διευκρίνιση: Η MySQL υποστηρίζεται ήδη)
Στην έκθεση, ήθελα επίσης να μιλήσω για εκείνες τις περιπτώσεις όπου το WAL-G δεν είναι κατάλληλο για εσάς.
Εάν δεν έχετε ένα σύγχρονο αντίγραφο, το WAL-G δεν εγγυάται ότι το τελευταίο τμήμα θα διατηρηθεί. Και αν η αρχειοθέτηση υστερεί σε σχέση με τα τελευταία τμήματα της ιστορίας, αυτό είναι ένας κίνδυνος. Εάν δεν υπάρχει σύγχρονο αντίγραφο, δεν θα συνιστούσα τη χρήση του WAL-G. Ωστόσο, έχει σχεδιαστεί κυρίως για μια εγκατάσταση cloud, η οποία συνεπάγεται μια λύση Υψηλής Διαθεσιμότητας με ένα σύγχρονο αντίγραφο, το οποίο είναι υπεύθυνο για την ασφάλεια των τελευταίων byte που δεσμεύτηκαν.
Συχνά βλέπω ανθρώπους που προσπαθούν να τρέξουν και το WAL-G και το WAL-E ταυτόχρονα. Υποστηρίζουμε τη συμβατότητα προς τα πίσω με την έννοια ότι το WAL-G μπορεί να επαναφέρει ένα αρχείο από το WAL-E και μπορεί να επαναφέρει ένα αντίγραφο ασφαλείας που δημιουργήθηκε στο WAL-E. Επειδή όμως και τα δύο αυτά συστήματα χρησιμοποιούν παράλληλο wal-push, αρχίζουν να κλέβουν αρχεία το ένα από το άλλο. Αν το διορθώσουμε στο WAL-G, θα παραμείνει στο WAL-E. Στο WAL-E, κοιτάζει την κατάσταση αρχειοθέτησης, βλέπει τα ολοκληρωμένα αρχεία και τα αρχειοθετεί, ενώ άλλα συστήματα απλά δεν θα γνωρίζουν ότι αυτό το αρχείο WAL υπήρχε, επειδή η PostgreSQL δεν θα προσπαθήσει να το αρχειοθετήσει δεύτερη φορά.
Τι θα διορθώσουμε εδώ στην πλευρά WAL-G; Δεν θα ενημερώσουμε την PostgreSQL ότι αυτό το αρχείο μεταφέρθηκε παράλληλα, και όταν η PostgreSQL μας ζητήσει να το αρχειοθετήσουμε, θα γνωρίζουμε ήδη ότι ένα τέτοιο αρχείο με αυτόν τον χρόνο λειτουργίας και με αυτό το md5 έχει ήδη αρχειοθετηθεί και θα πούμε απλώς PostgreSQL - ΟΚ, όλα είναι έτοιμα χωρίς ουσιαστικά να κάνουμε τίποτα.
Αλλά αυτό το πρόβλημα είναι απίθανο να επιλυθεί στην πλευρά WAL-E, επομένως είναι αδύνατο να δημιουργηθεί μια εντολή αρχειοθέτησης που θα αρχειοθετεί το αρχείο τόσο στο WAL-G όσο και στο WAL-E.
Επιπλέον, υπάρχουν περιπτώσεις που το WAL-G δεν είναι κατάλληλο για εσάς τώρα, αλλά σίγουρα θα το φτιάξουμε.
Πρώτον, προς το παρόν δεν έχουμε ενσωματωμένη επαλήθευση αντιγράφων ασφαλείας. Δεν έχουμε επαλήθευση ούτε κατά τη δημιουργία αντιγράφων ασφαλείας ούτε κατά την ανάκτηση. Φυσικά, αυτό υλοποιείται στο cloud. Αλλά αυτό υλοποιείται απλώς με προ-έλεγχο, απλά με επαναφορά του συμπλέγματος. Θα ήθελα να δώσω αυτή τη λειτουργία στους χρήστες. Αλλά με την επαλήθευση, υποθέτω ότι στο WAL-G θα είναι δυνατή η επαναφορά του συμπλέγματος και η εκκίνηση του και η εκτέλεση δοκιμών καπνού: pg_dumpall σε /dev/null και η επαλήθευση ευρετηρίου amcheck.
Αυτήν τη στιγμή στο WAL-G δεν υπάρχει τρόπος να αναβληθεί ένα αντίγραφο ασφαλείας από το WAL. Δηλαδή υποστηρίζουμε κάποιο παράθυρο. Για παράδειγμα, αποθήκευση των τελευταίων επτά ημερών, αποθήκευση των τελευταίων δέκα αντιγράφων ασφαλείας, αποθήκευση των τελευταίων τριών πλήρους αντιγράφων ασφαλείας. Πολύ συχνά οι άνθρωποι έρχονται και λένε: «Χρειαζόμαστε ένα αντίγραφο ασφαλείας του τι συνέβη την Πρωτοχρονιά και θέλουμε να το κρατήσουμε για πάντα». Το WAL-G δεν μπορεί να το κάνει ακόμα. (Σημείωση - Αυτό έχει ήδη διορθωθεί. Διαβάστε περισσότερα - Επιλογή δημιουργίας αντιγράφων ασφαλείας σε )
Και δεν έχουμε αθροίσματα ελέγχου σελίδας και ελέγχους ακεραιότητας για όλα τα τμήματα άξονα κατά την επικύρωση του PITR.
Από όλα αυτά έφτιαξα ένα έργο για το Google Summer of Code. Εάν γνωρίζετε έξυπνους μαθητές που θα ήθελαν να γράψουν κάτι στο Go και να λάβουν αρκετές χιλιάδες δολάρια από μια εταιρεία με το γράμμα "G", τότε προτείνετε το έργο μας σε αυτούς. Θα λειτουργήσω ως μέντορας για αυτό το έργο, μπορούν να το κάνουν. Αν δεν υπάρχουν μαθητές, τότε θα το πάρω και θα το κάνω μόνος μου το καλοκαίρι.
Και έχουμε πολλά άλλα μικρά προβλήματα που σταδιακά επεξεργαζόμαστε. Και συμβαίνουν αρκετά περίεργα πράγματα.
Για παράδειγμα, εάν δώσετε στο WAL-G ένα κενό αντίγραφο ασφαλείας, απλά θα πέσει. Για παράδειγμα, αν του πείτε ότι πρέπει να δημιουργήσει αντίγραφο ασφαλείας ενός κενού φακέλου. Το αρχείο pg_control δεν θα υπάρχει. Και θα νομίζει ότι κάτι δεν καταλαβαίνει. Θεωρητικά, σε αυτήν την περίπτωση πρέπει να γράψετε ένα κανονικό μήνυμα στον χρήστη για να του εξηγήσετε πώς να χρησιμοποιεί το εργαλείο. Αλλά αυτό δεν είναι καν χαρακτηριστικό του προγραμματισμού, αλλά χαρακτηριστικό μιας καλής, κατανοητής γλώσσας.
Δεν ξέρουμε πώς να κάνουμε backup εκτός σύνδεσης. Εάν η βάση δεδομένων είναι ψέματα, δεν μπορούμε να δημιουργήσουμε αντίγραφα ασφαλείας. Αλλά όλα είναι πολύ απλά εδώ. Καλούμε αντίγραφα ασφαλείας από το LSN όταν ξεκίνησε. Το LSN της υποκείμενης βάσης πρέπει να διαβαστεί από το αρχείο ελέγχου. Και αυτό είναι ένα τόσο απραγματοποίητο χαρακτηριστικό. Πολλά συστήματα δημιουργίας αντιγράφων ασφαλείας μπορούν να δημιουργήσουν αντίγραφα ασφαλείας μιας υποκείμενης βάσης δεδομένων. Και είναι βολικό.
Προς το παρόν δεν μπορούμε να χειριστούμε σωστά την έλλειψη εφεδρικού χώρου. Γιατί συνήθως δουλεύουμε με μεγάλα αντίγραφα ασφαλείας στο σπίτι. Και δεν το κατάφεραν. Αλλά αν κάποιος θέλει να προγραμματίσει στο Go αυτή τη στιγμή, προσθέστε χειρισμό για σφάλματα εκτός χώρου στον κάδο. Σίγουρα θα εξετάσω το αίτημα έλξης.
Και το κύριο πράγμα που μας ανησυχεί είναι ότι θέλουμε όσο το δυνατόν περισσότερες δοκιμές ενσωμάτωσης docker που ελέγχουν διάφορα σενάρια. Αυτή τη στιγμή δοκιμάζουμε μόνο βασικά σενάρια. Σε κάθε δέσμευση, αλλά θέλουμε να ελέγξουμε δέσμευση προς δέσμευση όλη τη λειτουργικότητα που υποστηρίζουμε. Συγκεκριμένα, για παράδειγμα, θα έχουμε αρκετή υποστήριξη για το PostgreSQL 9.4-9.5. Τους υποστηρίζουμε επειδή η κοινότητα υποστηρίζει την PostgreSQL, αλλά δεν ελέγχουμε δέσμευση προς δέσμευση για να βεβαιωθούμε ότι όλα δεν έχουν χαλάσει. Και μου φαίνεται ότι αυτός είναι ένας μάλλον σοβαρός κίνδυνος.
Έχουμε το WAL-G που εκτελείται σε περισσότερα από χίλια συμπλέγματα στη διαχείριση βάσης δεδομένων Yandex. Και δημιουργεί αντίγραφα ασφαλείας πολλών εκατοντάδων terabyte δεδομένων κάθε μέρα.
Έχουμε πολλά TODO στον κώδικά μας. Αν θέλετε να προγραμματίσετε, ελάτε, περιμένουμε αιτήματα έλξης, περιμένουμε ερωτήσεις.
ερωτήσεις
Καλό απόγευμα! Ευχαριστώ! Η εικασία μου είναι ότι εάν χρησιμοποιείτε το WAL-delta, πιθανότατα βασίζεστε σε μεγάλο βαθμό στις ολοσέλιδες γραφές. Και αν ναι, κάνατε δοκιμές; Έδειξες ένα όμορφο γράφημα. Πόσο πιο όμορφο γίνεται αν το FPW είναι απενεργοποιημένο;
Η εγγραφή πλήρους σελίδας είναι ενεργοποιημένη για εμάς, δεν προσπαθήσαμε να την απενεργοποιήσουμε. Δηλαδή εγώ ως προγραμματιστής δεν έχω προσπαθήσει να το απενεργοποιήσω. Οι διαχειριστές συστήματος που έχουν κάνει έρευνα έχουν πιθανώς ερευνήσει αυτό το ζήτημα. Αλλά χρειαζόμαστε FPW. Σχεδόν κανείς δεν το απενεργοποιεί, γιατί διαφορετικά είναι αδύνατο να ληφθεί αντίγραφο ασφαλείας από ένα αντίγραφο.
Ευχαριστώ για την αναφορά! Έχω δύο ερωτήσεις. Το πρώτο ερώτημα είναι τι θα γίνει με τα tablespace;
Περιμένουμε αίτημα έλξης. Οι βάσεις δεδομένων μας ζουν σε δίσκους SSD και NMVE και δεν χρειαζόμαστε πραγματικά αυτό το χαρακτηριστικό. Δεν είμαι έτοιμος να περάσω σοβαρό χρόνο αυτή τη στιγμή για να το κάνω καλά. Υποστηρίζω ολόψυχα ότι το υποστηρίζουμε. Υπάρχουν άνθρωποι που το στήριξαν, αλλά το στήριξαν με τρόπο που τους ταιριάζει. Έκαναν ένα πιρούνι, αλλά δεν κάνουν αιτήματα έλξης. (Προστέθηκε στην έκδοση 0.2.13)
Και η δεύτερη ερώτηση. Είπατε από την αρχή ότι το WAL-G υποθέτει ότι λειτουργεί μόνο του και δεν χρειάζονται περιτυλίγματα. Εγώ ο ίδιος χρησιμοποιώ περιτυλίγματα. Γιατί να μην χρησιμοποιούνται;
Θέλουμε να είναι τόσο απλό όσο μια μπαλαλάικα. Αυτό σημαίνει ότι δεν χρειάζεστε τίποτα απολύτως εκτός από μια μπαλαλάικα. Θέλουμε το σύστημα να είναι απλό. Εάν έχετε λειτουργίες που πρέπει να κάνετε σε ένα σενάριο, τότε ελάτε να μας πείτε - θα το κάνουμε στο Go.
Καλό απόγευμα! Ευχαριστώ για την αναφορά! Δεν μπορέσαμε να κάνουμε το WAL-G να λειτουργήσει με την αποκρυπτογράφηση GPG. Κρυπτογραφεί κανονικά, αλλά δεν θέλει να αποκρυπτογραφήσει. Είναι κάτι που δεν μας βγήκε; Η κατάσταση είναι καταθλιπτική.
Δημιουργήστε ένα πρόβλημα στο GitHub και ας το λύσουμε.
Δηλαδή δεν το έχεις συναντήσει αυτό;
Υπάρχει ένα χαρακτηριστικό της αναφοράς σφάλματος ότι όταν το WAL-G δεν κατανοεί τι είδους αρχείο είναι, ρωτά: "Ίσως είναι κρυπτογραφημένο;" Ίσως το πρόβλημα να μην είναι καθόλου η κρυπτογράφηση. Θέλω να βελτιώσω την καταγραφή σε αυτό το θέμα. Πρέπει να το αποκρυπτογραφήσει. Αυτήν τη στιγμή εργαζόμαστε πάνω σε αυτό το θέμα με την έννοια ότι δεν μας αρέσει πολύ ο τρόπος με τον οποίο είναι οργανωμένο το σύστημα απόκτησης δημόσιων και ιδιωτικών κλειδιών. Γιατί λέμε εξωτερικό GPG για να μας δώσει τα κλειδιά του. Και μετά παίρνουμε αυτά τα κλειδιά και τα μεταφέρουμε στο εσωτερικό GPG, το οποίο είναι ανοιχτό PGP, το οποίο έχει μεταγλωττιστεί για εμάς μέσα στο WAL-G, και εκεί ονομάζουμε κρυπτογράφηση. Από αυτή την άποψη, θέλουμε να βελτιώσουμε το σύστημα και θέλουμε να υποστηρίξουμε την κρυπτογράφηση Libsodium (Προστέθηκε στην έκδοση 0.2.15). Φυσικά, η αποκωδικοποίηση θα πρέπει να λειτουργεί, ας το καταλάβουμε - χρειάζεστε περισσότερο ένα σύμπτωμα παρά μερικές λέξεις. Μπορείτε να συγκεντρωθείτε στο δωμάτιο του ομιλητή κάποια στιγμή και να κοιτάξετε το σύστημα. (Κρυπτογράφηση PGP χωρίς εξωτερικό GPG - έκδοση 0.2.9)
Γειά σου! Ευχαριστώ για την αναφορά! Έχω δύο ερωτήσεις. Έχω μια περίεργη επιθυμία να κάνω το pg_basebackup και το WAL να συνδεθώ σε δύο παρόχους, δηλαδή θέλω να κάνω το ένα σύννεφο και το άλλο. Υπάρχει κάποιος τρόπος να γίνει αυτό;
Αυτό δεν υπάρχει τώρα, αλλά είναι μια ενδιαφέρουσα ιδέα.
Απλώς δεν εμπιστεύομαι έναν πάροχο, θέλω να έχω το ίδιο σε έναν άλλο, για κάθε ενδεχόμενο.
Η ιδέα είναι ενδιαφέρουσα. Τεχνικά, αυτό δεν είναι καθόλου δύσκολο να εφαρμοστεί. Για να μην χαθεί η ιδέα, μπορώ να σας ζητήσω να δημιουργήσετε ένα πρόβλημα στο GitHub;
Ναι, φυσικά.
Και στη συνέχεια, όταν οι μαθητές έρθουν στο Google Summer of Code, θα τους προσθέσουμε στο έργο, ώστε να υπάρχει περισσότερη δουλειά για να αξιοποιήσουμε περισσότερο από αυτούς.
Και η δεύτερη ερώτηση. Υπάρχει ένα πρόβλημα στο GitHub. Νομίζω ότι έχει ήδη κλείσει. Υπάρχει πανικός κατά την επαναφορά. Και για να το νικήσεις, έκανες ξεχωριστή συναρμολόγηση. Είναι σωστό σε θέματα. Και υπάρχει μια επιλογή να κάνετε ένα μεταβλητό περιβάλλον σε ένα νήμα. Και γι' αυτό λειτουργεί πολύ αργά. Και αντιμετωπίσαμε αυτό το πρόβλημα, και δεν έχει επιδιορθωθεί ακόμα.
Το πρόβλημα είναι ότι για κάποιο λόγο ο χώρος αποθήκευσης (CEPH) επαναφέρει τη σύνδεση όταν ερχόμαστε σε αυτό με υψηλή ταυτόχρονη. Τι μπορεί να γίνει για αυτό; Η λογική επανάληψης μοιάζει με αυτό. Προσπαθούμε να κατεβάσουμε ξανά το αρχείο. Σε ένα πέρασμα, είχαμε πολλά αρχεία που δεν κατέβασαν, θα κάνουμε ένα δεύτερο για όλους όσους δεν μπήκαν. Και εφόσον φορτώνεται τουλάχιστον ένα αρχείο ανά επανάληψη, επαναλαμβάνουμε και επαναλαμβάνουμε και επαναλαμβάνουμε. Βελτιώσαμε τη λογική της επανάληψης - εκθετικής υποχώρησης. Αλλά δεν είναι απολύτως σαφές τι να κάνετε με το γεγονός ότι η σύνδεση απλώς διακόπτεται από την πλευρά του συστήματος αποθήκευσης. Δηλαδή, όταν ανεβάζουμε σε μια ροή, δεν διακόπτει αυτές τις συνδέσεις. Τι μπορούμε να βελτιώσουμε εδώ; Έχουμε περιορισμό δικτύου, μπορούμε να περιορίσουμε κάθε σύνδεση με τον αριθμό των byte που στέλνει. Διαφορετικά, δεν ξέρω πώς να αντιμετωπίσω το γεγονός ότι η αποθήκευση αντικειμένων δεν μας επιτρέπει να κάνουμε λήψη ή λήψη από αυτό παράλληλα.
Δεν υπάρχει SLA; Δεν είναι γραμμένο για αυτούς πώς αφήνουν τον εαυτό τους να βασανίζεται;
Το θέμα είναι ότι οι άνθρωποι που σκέφτονται αυτή την ερώτηση έχουν συνήθως το δικό τους θησαυροφυλάκιο. Δηλαδή, κανείς δεν προέρχεται από το Amazon ή το Google Cloud ή το Yandex Object Storage.
Ίσως η ερώτηση δεν είναι πλέον για εσάς;
Το ερώτημα εδώ σε αυτή την περίπτωση δεν έχει σημασία για ποιον. Εάν υπάρχουν ιδέες για το πώς να το αντιμετωπίσετε, ας το κάνουμε στο WAL-G. Αλλά μέχρι στιγμής δεν έχω καλές ιδέες για το πώς να το αντιμετωπίσω αυτό. Υπάρχουν ορισμένα αντικείμενα αποθήκευσης που υποστηρίζουν διαφορετικά αντίγραφα ασφαλείας καταχώρισης. Τους ζητάτε να παραθέσουν αντικείμενα και προσθέτουν φάκελο εκεί. Το WAL-G φοβάται με αυτό - υπάρχει κάτι εδώ που δεν είναι αρχείο, δεν μπορώ να το επαναφέρω, πράγμα που σημαίνει ότι το αντίγραφο ασφαλείας δεν αποκαταστάθηκε. Δηλαδή, στην πραγματικότητα, έχετε ένα πλήρως αποκατεστημένο σύμπλεγμα, αλλά σας επιστρέφει μια εσφαλμένη κατάσταση επειδή το Object Storage επέστρεψε κάποιες περίεργες πληροφορίες που δεν κατανοούσε πλήρως.
Αυτό είναι κάτι που συμβαίνει στο σύννεφο αλληλογραφίας.
Αν μπορείτε να δημιουργήσετε μια αναπαραγωγή...
Αναπαράγεται με συνέπεια...
Εάν υπάρξει αναπαραγωγή, τότε νομίζω ότι θα πειραματιστούμε με στρατηγικές επανάληψης δοκιμής και θα καταλάβουμε πώς να προσπαθήσουμε ξανά και να καταλάβουμε τι απαιτεί το σύννεφο από εμάς. Ίσως θα είναι σταθερό για εμάς σε τρεις συνδέσεις και δεν θα σπάσει τη σύνδεση, τότε θα φτάσουμε προσεκτικά στις τρεις. Επειδή τώρα εγκαταλείπουμε τη σύνδεση πολύ γρήγορα, δηλαδή αν ξεκινήσαμε μια ανάκτηση με 16 νήματα, τότε μετά την πρώτη επανάληψη θα υπάρχουν 8 νήματα, 4 νήματα, 2 νήματα και ένα. Και μετά θα τραβήξει το αρχείο σε μία ροή. Εάν υπάρχουν κάποιες μαγικές τιμές, όπως τα 7,5 νήματα είναι τα καλύτερα για άντληση, τότε θα σταθούμε σε αυτά και θα προσπαθήσουμε να φτιάξουμε άλλα 7,5 νήματα. Εδώ είναι μια ιδέα.
Ευχαριστώ για την αναφορά! Πώς μοιάζει μια πλήρης ροή εργασίας για εργασία με το WAL-G; Για παράδειγμα, στην ηλίθια περίπτωση που δεν υπάρχει δέλτα στις σελίδες. Και παίρνουμε και αφαιρούμε το αρχικό αντίγραφο ασφαλείας και, στη συνέχεια, αρχειοθετούμε τον άξονα μέχρι να είμαστε μπλε στο πρόσωπο. Εδώ, όπως καταλαβαίνω, υπάρχει μια κατάρρευση. Κάποια στιγμή πρέπει να δημιουργήσετε ένα δέλτα αντίγραφο ασφαλείας των σελίδων, δηλαδή κάποια εξωτερική διαδικασία οδηγεί σε αυτό ή πώς συμβαίνει αυτό;
Το delta backup API είναι αρκετά απλό. Υπάρχει ένας αριθμός εκεί - μέγιστο δέλτα βήματα, έτσι λέγεται. Από προεπιλογή είναι μηδέν. Αυτό σημαίνει ότι κάθε φορά που κάνετε backup-push, κατεβάζει ένα πλήρες αντίγραφο ασφαλείας. Εάν το αλλάξετε σε οποιονδήποτε θετικό αριθμό, για παράδειγμα, 3, τότε την επόμενη φορά που θα κάνετε backup-push, θα κοιτάξει το ιστορικό των προηγούμενων αντιγράφων ασφαλείας. Βλέπει ότι δεν ξεπερνάς την αλυσίδα των 3 δέλτα και κάνει ένα δέλτα.
Δηλαδή, κάθε φορά που εκκινούμε το WAL-G, προσπαθεί να κάνει ένα πλήρες αντίγραφο ασφαλείας;
Όχι, εκτελούμε το WAL-G και προσπαθεί να δημιουργήσει δέλτα εάν το επιτρέπουν οι πολιτικές σας.
Σε γενικές γραμμές, αν το τρέχεις με μηδέν κάθε φορά, θα συμπεριφέρεται σαν pg_basebackup;
Όχι, θα συνεχίσει να τρέχει πιο γρήγορα γιατί χρησιμοποιεί συμπίεση και παραλληλισμό. Το Pg_basebackup θα βάλει τον άξονα δίπλα σας. Το WAL-G υποθέτει ότι έχετε διαμορφώσει τις παραμέτρους της αρχειοθέτησης. Και θα εκδώσει μια προειδοποίηση εάν δεν έχει ρυθμιστεί.
Το Pg_basebackup μπορεί να εκτελεστεί χωρίς άξονες.
Ναι, τότε θα συμπεριφέρονται σχεδόν το ίδιο. Το Pg_basebackup αντιγράφει στο σύστημα αρχείων. Παρεμπιπτόντως, έχουμε ένα νέο χαρακτηριστικό που ξέχασα να αναφέρω. Μπορούμε τώρα να δημιουργήσουμε αντίγραφα ασφαλείας στο σύστημα αρχείων από το pg_basebackup. Δεν ξέρω γιατί χρειάζεται, αλλά υπάρχει.
Για παράδειγμα, στο CephFS. Δεν θέλουν όλοι να ρυθμίσουν το Object Storage.
Ναι, πιθανώς γι' αυτό έκαναν μια ερώτηση σχετικά με αυτήν τη δυνατότητα, ώστε να μπορέσουμε να το κάνουμε. Και το κάναμε.
Ευχαριστώ για την αναφορά! Υπάρχει απλώς μια ερώτηση σχετικά με την αντιγραφή στο σύστημα αρχείων. Εκτός συσκευασίας, υποστηρίζετε τώρα την αντιγραφή σε απομακρυσμένο χώρο αποθήκευσης, για παράδειγμα, εάν υπάρχει κάποιο ράφι στο κέντρο δεδομένων ή κάτι άλλο;
Σε αυτή τη διατύπωση, αυτή είναι μια δύσκολη ερώτηση. Ναι, υποστηρίζουμε, αλλά αυτή η λειτουργία δεν περιλαμβάνεται ακόμη σε καμία έκδοση. Δηλαδή, όλες οι προεκδόσεις το υποστηρίζουν αυτό, αλλά οι εκδόσεις έκδοσης όχι. Αυτή η λειτουργία προστέθηκε στην έκδοση 0.2. Σίγουρα θα κυκλοφορήσει σύντομα, μόλις διορθώσουμε όλα τα γνωστά σφάλματα. Αλλά αυτή τη στιγμή αυτό μπορεί να γίνει μόνο στην προέκδοση. Υπάρχουν δύο σφάλματα στην προέκδοση. Πρόβλημα με την ανάκτηση WAL-E, δεν το έχουμε επιλύσει. Και στην τελευταία προέκδοση προστέθηκε ένα σφάλμα σχετικά με το delta-backup. Επομένως, συνιστούμε σε όλους να χρησιμοποιούν τις εκδόσεις έκδοσης. Από τη στιγμή που δεν υπάρχουν άλλα σφάλματα στην προέκδοση, μπορούμε να πούμε ότι υποστηρίζουμε το Google Cloud, πράγματα συμβατά με S3 και αποθήκευση αρχείων.
Γεια σας, ευχαριστώ για την αναφορά. Όπως καταλαβαίνω, το WAL-G δεν είναι κάποιου είδους κεντρικό σύστημα όπως οι μπάρμαν; Σκοπεύετε να κινηθείτε προς αυτή την κατεύθυνση;
Το πρόβλημα είναι ότι έχουμε απομακρυνθεί από αυτήν την κατεύθυνση. Το WAL-G ζει στον βασικό κεντρικό υπολογιστή, στον κεντρικό υπολογιστή και σε όλους τους κεντρικούς υπολογιστές του συμπλέγματος. Όταν μετακομίσαμε σε πολλές χιλιάδες ομάδες, είχαμε πολλές εγκαταστάσεις μπάρμαν. Και κάθε φορά που κάτι καταρρέει μέσα τους, είναι μεγάλο πρόβλημα. Επειδή πρέπει να επισκευαστούν, πρέπει να καταλάβετε ποια συμπλέγματα δεν έχουν αντίγραφα ασφαλείας. Δεν σκοπεύω να αναπτύξω το WAL-G προς την κατεύθυνση του φυσικού υλικού για εφεδρικά συστήματα. Αν η κοινότητα θέλει κάποια λειτουργικότητα εδώ, δεν με πειράζει καθόλου.
Έχουμε ομάδες που είναι υπεύθυνες για την αποθήκευση. Και αισθανόμαστε τόσο καλά που δεν είμαστε εμείς, που υπάρχουν ειδικοί άνθρωποι που βάζουν τα αρχεία μας εκεί που τα αρχεία είναι ασφαλή. Κάνουν κάθε είδους έξυπνη κωδικοποίηση εκεί για να αντέξουν την απώλεια ενός συγκεκριμένου αριθμού αρχείων. Είναι υπεύθυνοι για το εύρος ζώνης του δικτύου. Όταν έχετε έναν μπάρμαν, μπορεί ξαφνικά να ανακαλύψετε ότι στον ίδιο διακομιστή έχουν συγκεντρωθεί μικρές βάσεις δεδομένων με μεγάλη κίνηση. Φαίνεται ότι έχετε πολύ χώρο σε αυτό, αλλά για κάποιο λόγο δεν ταιριάζουν όλα στο δίκτυο. Μπορεί να αποδειχθεί το αντίστροφο. Υπάρχουν πολλά δίκτυα εκεί, υπάρχουν πυρήνες επεξεργαστών, αλλά δεν υπάρχουν δίσκοι εδώ. Και βαρεθήκαμε αυτή την ανάγκη να κάνουμε ταχυδακτυλουργικά κάτι και προχωρήσαμε στο γεγονός ότι η αποθήκευση δεδομένων είναι μια ξεχωριστή υπηρεσία, για την οποία είναι υπεύθυνοι ξεχωριστοί ειδικοί άνθρωποι.
Υ.Γ Κυκλοφόρησε νέα έκδοση , στο οποίο μπορείτε να χρησιμοποιήσετε το αρχείο διαμόρφωσης .walg.json, το οποίο βρίσκεται στον αρχικό κατάλογο postgres από προεπιλογή. Μπορείτε να εγκαταλείψετε τα σενάρια bash. Το παράδειγμα .walg.json βρίσκεται σε αυτό το τεύχος
Βίντεο:
Πηγή: www.habr.com