Managed Redis, med automatisk failover og backups til din egen S3

Redis er let at køre — indtil det ikke er det. En enkelt node er et single point of failure; i det øjeblik den skal overleve et nedbrud, er du i gang med at sætte replikaer op, rejse Sentinel til at vælge en ny master og lære hver klient at finde den, der har ansvaret lige nu. Det er den samme pasningsopgave som enhver anden tilstandsfuld tjeneste — mange bevægelige dele for et enkelt resultat: når masteren dør, overtager en replika hurtigt, og din app mærker knap nok noget.

Suble tilbyder nu managed, højtilgængelig Redis som et database-cluster. Vælg Redis, vælg et antal noder, og du får replikering, automatisk failover med Redis Sentinel og et enkelt stabilt endpoint — passet for dig, på vores egen danske infrastruktur.

Sådan virker det

Et Redis-cluster er N medlems-VM'er, der hver kører deres egen redis-server med en fuld lokal kopi af data. Det er shared-nothing — ingen delt disk som alle afhænger af. Medlem et kommer op som master; resten tilslutter sig som replikaer og streamer hver skrivning.

• Sentinel styrer failover. Hvert medlem kører også en Sentinel ved siden af. Sentinellerne holder øje med masteren og hinanden; hvis masteren dør, bliver et flertal enige og forfremmer den sundeste replika på sekunder — ingen ekstern koordinator, du skal drifte.
• Et stabilt skrive-endpoint. Load balanceren i dit cluster udstiller et :6379-endpoint, der altid ruter til den *nuværende* master. Når Sentinel forfremmer en ny master, følger endpointet med automatisk — din connection string ændrer sig aldrig.
• Et load-balanceret læse-endpoint. Et andet :6380-endpoint spreder skrivebeskyttet trafik hen over replikaerne, så du kan flytte tunge GET/SCAN-arbejdsbyrder væk fra masteren uden at hardkode replika-adresser.
• En eller flere. Vælg en enkelt node til en simpel managed cache, eller tre-plus til høj tilgængelighed. (To noder kan ikke danne et sikkert Sentinel-flertal, så det tilbyder vi ikke — en eller tre-plus.)

Krypteret hele vejen, med brugere du kan afgrænse

Hver Redis-forbindelse taler TLS — der er ingen plaintext-port at glemme. Klientforbindelser, replikeringsstrømmen mellem medlemmer og Sentinellerne bruger alle et certifikat, der deles mellem alle medlemmerne (Redis verificerer masterens certifikat under replikering, så medlemmerne deler det). Din connection string er en rediss://-URL; download CA-certifikatet for dit cluster fra dashboardet for at fastgøre serveren, eller brug din klients skip-verify-mulighed. En plaintext-klient bliver simpelthen afvist ved handshaket.

Ud over den delte default-bruger kan du oprette navngivne ACL-brugere afgrænset læse-skrive eller skrivebeskyttet — en skrivebeskyttet bruger kan GET/SCAN, men nægtes skrivninger med en NOPERM-fejl. Redis-ACL'er er node-lokale, så Suble anvender hver bruger på *hvert* medlem af dit cluster; på den måde bliver en bruger ved med at virke efter en failover og på læse-endpointet, ikke kun mod den node der tilfældigvis var master, da du oprettede den. Hver brugers adgangskode vises en gang.

Opdateringer uden nedetid

Når OS- eller Redis-opdateringer kommer, giver cluster-siden dig et vink, og at anvende dem er en rullende operation. Suble opdaterer replikaerne først — en ad gangen, mens den venter på at hver gentilslutter — og fryser derefter skrivninger og laver en ren SENTINEL FAILOVER til en allerede opdateret replika, før den opdaterer den tidligere master til sidst. Din klient ser en enkelt afbrudt forbindelse ved skiftet og genopretter til det samme endpoint; ingen datatab, ingen værtsændring. Mellem opdateringer heler dit cluster sig selv: et medlem der stopper, tændes igen og tilslutter sig som replika, og enhver node der fejlagtigt tror den er master, degraderes til at følge den valgte.

Replikering er ikke en backup

Høj tilgængelighed holder Redis *online* gennem et nodenedbrud. Den gør intet ved en forkert FLUSHALL, et nøglemønster slettet af et buggy job eller en værdi overskrevet for en time siden. Hver replika kopierer trofast, hvad masteren gør — inklusive fejlen. Når problemet er en time gammelt, vil du ikke have en trofast kopi af det; du vil tilbage til før det skete.

Det er det, Backups-fanen på et managed Redis-cluster er til. Suble tager punkt-i-tid RDB-snapshots af dine data og uploader dem til din egen S3-bucket — planlagt og efter behov — så du kan gendanne til et helt nyt cluster, der aldrig rører originalen.

Medbring din egen S3-bucket

Backups går til lager, du selv ejer og styrer — enhver S3-kompatibel udbyder virker: AWS S3, Cloudflare R2, Backblaze B2, MinIO eller et andet objektlager. Dine snapshots ligger på din konto, under dine livscyklusregler, prissat af din udbyder. Suble beholder aldrig en ekstra kopi.

I Console → Clusters → dit Redis-cluster → Backups peger du Suble mod bucketten:

S3 endpoint:   https://<accountid>.r2.cloudflarestorage.com
Region:        auto            (standard — de fleste S3-kompatible lagre accepterer det)
Bucket:        my-suble-backups
Path:          /               (standard — et præfiks inde i bucketten)
Access key:    <dit access key id>
Secret key:    <din secret access key>

Før noget gemmes, verificerer Suble legitimationsoplysningerne live — den laver et rigtigt skriv-og-slet testobjekt mod bucketten og afviser konfigurationen, hvis det fejler, så en tastefejl dukker op med det samme i stedet for kl. 3 om natten, når det første snapshot ikke kan uploades. Snapshots for hvert cluster gemmes under sit eget …/redis/<cluster-id>/-præfiks, så en bucket, du allerede bruger til Postgres-backups, ikke kolliderer.

Sådan tages et snapshot

Når en backup kører — planlagt eller når du klikker Backup nu — beder Suble den nuværende master om at skrive en frisk RDB med BGSAVE, venter på at den gemning bliver færdig rent, og uploader den resulterende dump.rdb til din bucket. BGSAVE forker i baggrunden, så din arbejdsbyrde bliver ved med at betjene, mens snapshottet skrives. Hver backup dukker op i listen med størrelse og tidsstempel; snapshots ud over dit opbevaringsantal beskæres fra S3 automatisk.

Gendan til et nyt cluster

Gendannelse rører aldrig det kørende cluster. Du vælger et snapshot, giver gendannelsen et navn, og Suble provisionerer et helt nyt Redis-cluster, hvis første medlem indlæser den RDB, før Redis overhovedet starter — så det kommer op med dine data allerede på plads, og eventuelle replikaer laver fuld resync fra det. Du får et frisk, uafhængigt cluster, du kan inspicere og skifte over til, når det passer dig.

Fordi en RDB allerede er et punkt-i-tid snapshot, er en Redis-gendannelse altid "gendan *dette* snapshot" — du vælger hvilket fra listen. (Postgres, med sin løbende write-ahead-log, tilbyder derudover gendannelse til ethvert sekund; Redis gendanner de diskrete snapshots, du tog.)

Opret en på et minut

I dashboardet: Clusters → New cluster → Database → Redis, vælg en node eller tre-plus, vælg en størrelse, og opret. Få minutter senere har du et kørende cluster med en master, replikaer og automatisk failover. Afslør adgangskoden og download CA-certifikatet på cluster-siden, peg din app mod rediss:// :6379 (skrivninger) og :6380 (læsninger), tilføj læse-skrive / skrivebeskyttede brugere hvis du har brug for dem, og slå backups til, når du er klar.

Høj tilgængelighed holder dig online. Backups til din egen S3 lader dig fortryde en fejl. Sammen gør de "kør Redis i produktion" fra et projekt til en checkbox.