Hoe overleef je een SQL-database in de 21e eeuw: clouds, Kubernetes en PostgreSQL Multimaster

Hallo, bewoners van Habr. Vandaag beginnen de lessen voor de eerste groep van de cursus. "PostgreSQL"Wij willen u graag vertellen hoe het open webinar over deze cursus is verlopen.

В nog een open les We spraken over de uitdagingen waarmee SQL-databases worden geconfronteerd in het tijdperk van clouds en Kubernetes. Tegelijkertijd keken we naar hoe SQL-databases zich aanpassen en muteren onder invloed van deze uitdagingen.

Het webinar werd uitgevoerd door Valery Bezrukov, Google Cloud Practice Delivery Manager bij EPAM Systems.

Toen de bomen klein waren…

Laten we om te beginnen eens kijken hoe de keuze voor DBMS'en aan het einde van de vorige eeuw begon. Dit zal echter niet moeilijk zijn, want de keuze voor DBMS'en begon en eindigde in die tijd. Oracle.

Eind jaren 90 en begin jaren 2 was er vrijwel geen keuze als het ging om industriële, schaalbare databases. Ja, er waren IBM DBXNUMX, Sybase en een aantal andere databases die verschenen en weer verdwenen, maar over het algemeen waren ze minder opvallend tegen de achtergrond van Oracle. De vaardigheden van ingenieurs in die tijd waren dan ook op de een of andere manier verbonden met de enige keuze die er bestond.

Een Oracle DBA moet in staat zijn om:

• Oracle Server installeren vanuit de distributie;
• Oracle Server configureren:

• init.ora;
• luisteraar.ora;

- creëren:

• tabellenruimten;
• regeling;
• gebruikers;

- back-up en herstel uitvoeren;
— monitoring uitvoeren;
— suboptimale zoekopdrachten bestrijden.

Tegelijkertijd was het van Oracle DBA niet per se vereist om:

• in staat zijn om de optimale DBMS of andere technologie te selecteren voor het opslaan en verwerken van gegevens;
• zorgen voor een hoge beschikbaarheid en horizontale schaalbaarheid (dit was niet altijd een DBA-probleem);
• goede kennis hebben van het vakgebied, infrastructuur, applicatiearchitectuur en besturingssysteem;
• het laden en ontladen van gegevens en de migratie van gegevens tussen verschillende DBMS'en.

Over het algemeen, als we praten over de keuze in die tijd, lijkt het op de keuze in een Sovjetwinkel aan het eind van de jaren 80:

Onze tijd

Sindsdien zijn de bomen natuurlijk gegroeid, is de wereld veranderd en is de wereld ongeveer zo geworden:

Ook de DBMS-markt is veranderd, wat duidelijk blijkt uit het laatste rapport van Gartner:

En hier is het onmogelijk om niet op te merken dat de cloud zijn niche heeft ingenomen, waarvan de populariteit groeit. Als we hetzelfde rapport van Gartner lezen, zien we de volgende conclusies:

1. Veel klanten zijn bezig hun applicaties naar de cloud te migreren.
2. Nieuwe technologieën verschijnen voor het eerst in de cloud en het is niet zo dat ze ooit naar een niet-cloudinfrastructuur zullen verhuizen.
3. Het pay-as-you-go-prijsmodel is gemeengoed geworden. Iedereen wil alleen betalen voor wat hij of zij gebruikt, en dit is niet eens meer een trend, maar gewoon een vaststaand feit.

Wat nu?

Tegenwoordig zitten we allemaal in de cloud. En de vragen die bij ons opkomen, zijn vragen over keuze. En die is enorm, zelfs als we het alleen hebben over de keuze voor DBMS-technologieën in on-premises formaat. En we hebben ook managed services en SaaS. De keuze wordt dus elk jaar complexer.

Naast de kwesties van keuze zijn er ook beperkende factoren:

• prijsVeel technologieën kosten nog steeds geld;
• vaardighedenAls we het over vrije software hebben, dan rijst de vraag naar vaardigheden. Vrije software vereist immers voldoende competentie van de mensen die het implementeren en gebruiken;
• functioneelNiet alle services die beschikbaar zijn in de cloud en bijvoorbeeld zelfs op dezelfde Postgres-basis zijn gebouwd, hebben dezelfde functionaliteiten als Postgres On-premises. Dit is een belangrijke factor die u moet kennen en begrijpen. Bovendien wordt deze factor steeds belangrijker dan kennis van enkele verborgen mogelijkheden van een specifiek DBMS.

Wat wordt er nu van DA/DE verwacht:

• goed begrip van het vakgebied en de applicatiearchitectuur;
• het vermogen om de juiste DBMS-technologie te selecteren rekening houdend met de taak die voorhanden is;
• het vermogen om de optimale methode te selecteren voor het implementeren van de gekozen technologie binnen de context van bestaande beperkingen;
• vaardigheden om gegevensoverdracht en -migratie uit te voeren;
• vaardigheden om de geselecteerde oplossingen te implementeren en te bedienen.

Het volgende voorbeeld gebaseerd op GCP laat zien hoe de keuze voor de ene of de andere technologie voor het werken met data gestructureerd is, afhankelijk van hun structuur:

Merk op dat PostgreSQL ontbreekt in het diagram, omdat het verborgen zit onder de terminologie. Cloud SQLEn als we bij Cloud SQL aankomen, moeten we opnieuw een keuze maken:

Opgemerkt dient te worden dat deze keuze niet altijd even duidelijk is en dat applicatieontwikkelaars vaak op hun intuïtie vertrouwen.

Totaal:

1. Hoe verder je komt, hoe dringender de keuzevraag wordt. En zelfs als je alleen naar GCP, managed services en SaaS kijkt, wordt RDBMS pas bij de vierde stap genoemd (en Spanner staat er vlakbij). Bovendien wordt PostgreSQL helemaal niet genoemd bij de vijfde stap, en daarnaast zijn er nog MySQL en SQL Server, dat wil zeggen. er is veel van alles, maar je moet kiezen.
2. We mogen de beperkingen van verleidingen niet vergeten. Eigenlijk wil iedereen Spanner, maar het is duur. Een typisch verzoek ziet er dan ook ongeveer zo uit: "Maak ons ​​alsjeblieft Spanner, maar voor de prijs van Cloud SQL zijn jullie professionals!"

Wat moeten we dan doen?

Zonder te beweren dat wij de ultieme waarheid in pacht hebben, zeggen wij het volgende:

We moeten onze aanpak van leren veranderen:

• er is geen zin meer om DBA's les te geven op de manier waarop dat vroeger gebeurde;
• kennis van één product is niet langer voldoende;
• en tientallen kennen op het niveau van één is onmogelijk.

Het is niet alleen belangrijk om het product te kennen, maar ook:

• gebruiksscenario van de toepassing;
• verschillende implementatiemethoden;
• voor- en nadelen van elke methode;
• vergelijkbare en alternatieve producten om een ​​weloverwogen en optimale keuze te kunnen maken, waarbij de voorkeur niet altijd uitgaat naar een bekend product.

Daarnaast moet u gegevens kunnen migreren en de basisprincipes van integratie met ETL begrijpen.

Echte zaak

In het recente verleden moest ik een backend maken voor een mobiele applicatie. Tegen de tijd dat ik eraan begon, was de backend al ontwikkeld en klaar voor implementatie, en het ontwikkelteam had ongeveer twee jaar aan dit project gewerkt. De volgende taken waren vastgesteld:

• CI/CD bouwen;
• een architectuurbeoordeling maken;
• dit alles in werking stellen.

De applicatie zelf was een microservice en de Python/Django-code werd vanaf nul en rechtstreeks in GCP ontwikkeld. Wat de doelgroep betreft, werd ervan uitgegaan dat er twee regio's zouden zijn - de VS en de EU - en dat het verkeer via de Global Load Balancer zou worden verdeeld. Alle workloads en rekenkracht draaiden in Google Kubernetes Engine.

De gegevens waren in 3 structuren verdeeld:

• Cloudopslag;
• Gegevensopslag;
• Cloud SQL (PostgreSQL).

Je zou je kunnen afvragen waarom er voor Cloud SQL is gekozen? Eerlijk gezegd heeft deze vraag de afgelopen jaren voor wat ongemakkelijke stiltes gezorgd - het lijkt erop dat mensen zich schamen voor relationele databases, maar ze blijven ze desondanks actief gebruiken ;-)

In ons geval hebben we om de volgende redenen voor Cloud SQL gekozen:

1. Zoals gezegd is de applicatie ontwikkeld met Django en beschikt deze over een model voor het toewijzen van persistente gegevens uit een SQL-database aan Python-objecten (Django ORM).
2. Het framework zelf ondersteunde een vrij beperkte lijst van DBMS:

• PostgreSQL;
• MariaDB;
• MySQL;
• Orakel;
• SQLite.

Daarom werd PostgreSQL op een vrij intuïtieve manier uit deze lijst gekozen (nou ja, het is niet zo dat we voor Oracle kozen).

Wat ontbrak:

• de applicatie is slechts in twee regio's geïmplementeerd, en een derde regio (Azië) is gepland;
• De database bevond zich in de regio Noord-Amerika (Iowa);
• Er waren zorgen van de kant van de klant over mogelijke toegangsvertragingen uit Europa en Azië en onderbrekingen in dienst in geval van DBMS-uitval.

Aangezien Django zelf met meerdere databases parallel kan werken en deze kan verdelen door lezen en schrijven, waren er niet zoveel records in de applicatie (meer dan 90% - lezen). En in het algemeen, en in het algemeen, als het mogelijk was om leesreplica van de hoofdbasis in Europa en Azië, dit zou een compromisoplossing zijn. Nou, wat is daar zo moeilijk aan?

Het probleem was dat de klant niet wilde afzien van het gebruik van managed services en Cloud SQL. Bovendien zijn de mogelijkheden van Cloud SQL momenteel beperkt. Cloud SQL ondersteunt High Availability (HA) en Read Replica (RR), maar dezelfde RR wordt slechts in één regio ondersteund. Na het aanmaken van een database in de Amerikaanse regio is het onmogelijk om met Cloud SQL een read replica in de Europese regio aan te maken, hoewel Postgres dit zelf niet verbiedt. Correspondentie met Google-medewerkers leverde niets op en eindigde met beloftes in de trant van "we kennen het probleem en werken eraan, het probleem zal ooit worden opgelost."

Als we de mogelijkheden van Cloud SQL kort samenvatten, ziet het er ongeveer zo uit:

1. Hoge beschikbaarheid (HA):

• binnen één regio;
• via schijfreplicatie;
• PostgreSQL-mechanismen worden niet gebruikt;
• automatische en handmatige besturing is mogelijk - failover/failback;
• Tijdens het overschakelen is het DBMS enkele minuten niet beschikbaar.

2. Leesreplica (RR):

• binnen één regio;
• hete stand-by;
• PostgreSQL streaming-replicatie.

Bovendien kom je, zoals gebruikelijk, bij het kiezen van een technologie altijd wel een aantal beperkingen:

• de klant wilde geen entiteiten spawnen en IaaS gebruiken behalve via GKE;
• de klant wil geen selfservice PostgreSQL/MySQL implementeren;
• Nou ja, over het algemeen zou Google Spanner best geschikt zijn als het niet zo duur was, hoewel Django ORM er niet mee overweg kan, maar verder is het een goede zaak.

Gezien de situatie stelde de klant een lastige vraag: "Kun je iets soortgelijks maken, zodat het op Google Spanner lijkt, maar ook met Django ORM werkt?"

Oplossingsoptie #0

Het eerste wat in me opkwam:

• blijf binnen CloudSQL;
• er zal geen enkele vorm van ingebouwde replicatie tussen regio's plaatsvinden;
• probeer een replica te koppelen aan een bestaande Cloud SQL van PostgreSQL;
• ergens en start op de een of andere manier een PostgreSQL-exemplaar, maar raak in ieder geval de master niet aan.

Helaas blijkt dit niet te kunnen, omdat er geen toegang is tot de host (deze bevindt zich in een heel ander project) - pg_hba enzovoorts. Ook is er geen toegang onder de superuser.

Oplossingsoptie #1

Na verder nadenken en rekening houdend met de eerdere omstandigheden, veranderde de gedachtegang enigszins:

• We proberen nog steeds binnen het raamwerk van CloudSQL te blijven, maar we stappen over op MySQL, omdat Cloud SQL van MySQL een externe master heeft, die:

— is een proxy voor externe MySQL;
- lijkt op een MySQL-exemplaar;
— ontworpen voor gegevensmigratie van andere clouds of on-premises.

Omdat de MySQL-replicatie geen toegang tot de host vereist, werkte alles in principe, maar het was erg instabiel en onhandig. En toen we verder gingen, werd het ronduit eng, want toen we de hele structuur met Terraform hadden geïmplementeerd, bleek plotseling dat de externe master niet door Terraform werd ondersteund. Ja, Google heeft een CLI, maar om de een of andere reden werkte alles hier met tussenpozen - soms werd hij aangemaakt, soms niet. Misschien omdat de CLI is uitgevonden voor externe datamigratie, en niet voor replica's.

Eigenlijk werd al snel duidelijk dat Cloud SQL helemaal niet geschikt was. Zoals ze zeggen, we hebben er alles aan gedaan.

Oplossingsoptie #2

Omdat het niet mogelijk was om binnen het kader van Cloud SQL te blijven, hebben we geprobeerd eisen te formuleren voor een compromisoplossing. De eisen waren als volgt:

• werken in Kubernetes, het maximaliseren van het gebruik van Kubernetes-bronnen en -mogelijkheden (DCS, …) en GCP (LB, …);
• afwezigheid van ballast van een hoop onnodige dingen in de cloud, zoals HA-proxy;
• de mogelijkheid om PostgreSQL of MySQL uit te voeren in de hoofd HA-regio; in andere regio's - HA van de RR van de hoofdregio plus de bijbehorende kopie (voor betrouwbaarheid);
• multi master (ik wilde hem niet contacteren, maar het was niet erg belangrijk)

.
Als gevolg van deze eisen zijn er eindelijk nieuwe kansen ontstaan.Geschikte DBMS- en bindingsopties:

• MySQL Galerij;
• KakkerlakDB;
• PostgreSQL-hulpmiddelen

:
— pgpool-II;
- Beschermheren.

MySQL-galerij

MySQL Galera-technologie is ontwikkeld door Codership en is een plugin voor InnoDB. Kenmerken:

• meerdere masters;
• synchrone replicatie;
• lezen van elk knooppunt;
• schrijf naar elk knooppunt;
• ingebouwd HA-mechanisme;
• Er is een Helm-kaart van Bitnami.

Kakkerlak DB

Volgens de beschrijving is het ding ronduit bombastisch en is het een open-sourceproject geschreven in Go. De belangrijkste deelnemer is Cockroach Labs (opgericht door voormalige Google-medewerkers). Dit relationele DBMS was oorspronkelijk ontwikkeld om te worden gedistribueerd (met horizontale schaalbaarheid "out of the box") en fouttolerant te zijn. De makers van het bedrijf schetsten het doel om "de rijkdom aan SQL-functionaliteit te combineren met de horizontale beschikbaarheid die bekend is bij NoSQL-oplossingen."

Een leuke bonus is de ondersteuning voor het PostgreSQL-verbindingsprotocol.

Pgpool

Dit is een add-on voor PostgreSQL, in feite een nieuwe entiteit die alle verbindingen overneemt en verwerkt. Het heeft een eigen load balancer en parser en valt onder de BSD-licentie. Het biedt uitgebreide mogelijkheden, maar ziet er wat eng uit, aangezien de aanwezigheid van een nieuwe entiteit een bron van extra avonturen zou kunnen worden.

patroon

Dit was het laatste wat me opviel, en terecht, zo bleek. Patroni is een open-sourceprogramma dat in wezen een Python-daemon is waarmee je automatisch PostgreSQL-clusters kunt onderhouden met verschillende typen replicatie en automatische rolwisseling. Het bleek erg interessant, omdat het goed integreert met Kubernetes en geen nieuwe entiteiten bevat.

Wat heb je uiteindelijk gekozen?

De keuze was niet eenvoudig:

1. Kakkerlak DB - vuur, maar eng;
2. MySQL-galerij — ook niet slecht, op veel plaatsen gebruikt, maar MySQL;
3. Pgpool — veel onnodige entiteiten, matige integratie met de cloud en K8s;
4. patroon - uitstekende integratie met K8s, geen extra entiteiten, goede integratie met GCP LB.

De keuze viel dus op Patroni.

Bevindingen

Het is tijd om het kort samen te vatten. Ja, de wereld van IT-infrastructuur is aanzienlijk veranderd, en dit is nog maar het begin. En waar clouds vroeger slechts een ander type infrastructuur waren, is nu alles anders. Bovendien verschijnen er voortdurend innovaties in de cloud, en die zullen er nog wel komen, en misschien verschijnen ze alleen in de cloud en pas daarna, met behulp van startups, worden ze overgezet naar on-premises.

Wat SQL betreft, SQL zal blijven bestaan. Dit betekent dat PostgreSQL en MySQL bekend moeten zijn en ermee gewerkt moeten worden, maar het is nog belangrijker om ze correct te kunnen gebruiken.

Bron: www.habr.com