Terug naar overzicht
Techblogs

Wat is MariaDB? MariaDB-as-a-service hosting in PaaS+

Wat is MariaDB? In dit techblog bespreken we wat MariaDB is en verkennen we specifiek de implementatie van MariaDB-as-a-Service voor PaaS+. We gaan in op de voordelen, uitdagingen en oplossingen die MariaDB biedt, waaronder geautomatiseerde installatie, betrouwbare clusterconfiguraties, optimalisatie, en zowel verticale als horizontale schaalbaarheid.
Door: Peter Bult

Wat is MariaDB?

MariaDB is een open-source relationeel databasebeheersysteem (RDBMS) en een fork van MySQL. Het werd gecreëerd door de oorspronkelijke ontwikkelaars van MySQL nadat ze bezorgd waren over de overname van MySQL door Oracle Corporation. MariaDB is ontworpen als een krachtig alternatief en heeft vergelijkbare kenmerken en functionaliteiten als MySQL, maar het streeft naar meer openheid en samenwerking met de community.

Het systeem is bedoeld voor gebruik in verschillende toepassingen, variërend van kleine databases voor individuele projecten tot grote, complexe databases voor bedrijfstoepassingen. MariaDB ondersteunt meerdere opslagengines, biedt geavanceerde beveiligingsfuncties en wordt geleverd met tools voor databasebeheer en -optimalisatie.

Een belangrijk kenmerk van MariaDB is dat het de MySQL-databasesyntax en API's behoudt, waardoor het voor gebruikers eenvoudig is om over te stappen van MySQL naar MariaDB zonder veel aanpassingen. MariaDB wordt veel gebruikt in webtoepassingen en servers en heeft een actieve gemeenschap van ontwikkelaars die bijdragen aan de verdere ontwikkeling en verbetering van het systeem.

Wat is MariaDB-as-a-service?

MariaDB-as-a-service is het resultaat van onze jarenlange ervaring met MariaDB-hosting en de analyse van de beste praktijken op het platform. Het is een geautomatiseerde oplossing die al het "zware" werk achter de schermen doet en je in enkele minuten een kant-en-klare oplossing biedt.

MariaDB-as-a-Service, aangedreven door PaaS+, biedt een tal van voordelen, waaronder:

  • Aanzienlijk vereenvoudigde installatie.
  • Geen diepgaande kennis is vereist, de installatie is volledig geautomatiseerd betrouwbaarheid van de cluster.
  • De databasestructuur met meerdere instanties (gebaseerd op verschillende schema's) elimineert het risico op downtime standaardoptimalisatie.
  • Configuraties worden automatisch aangepast aan jouw specifieke omgeving om de beste prestaties te garanderen minimale time-to-market.
  • Je bent op elk gewenste moment slechts enkele klikken verwijderd van een volledig functionele MariaDB-database.

Hieronder zullen we deze en andere voordelen van MariaDB-as-a-Service in detail bespreken.

Uitdagingen in MariaDB Clustering

Een van de belangrijkste uitdagingen voor ontwikkelaars is het vermijden van downtime. Het kan een van de grootste rampen voor jouw applicatie zijn. Hieronder kun jede kosten van downtime zien voor een aantal grote Amerikaanse e-commerce sites:

Waarom MariaDB as a service

Bovendien loop je naast omzetverlies ook reputatieschade op. Je kunt bestaande en potentiële klanten verliezen aan concurrenten, wat resulteert in een nog groter omzetverlies. Het is dus van belang om downtime te vermijden met alle mogelijke middelen.

Het is natuurlijk onmogelijk om uptime te garanderen op een op zichzelf staande topologie, aangezien je dan altijd een single-point of failure zult hebben. Om hoge beschikbaarheid te waarborgen, moeten geclusterde oplossingen worden gebruikt. Zo'n benadering zorgt echter voor de complexiteit van de initiële configuratie en toekomstig onderhoud. In het geval van MariaDB zou de takenlijst ongeveer bestaan uit de volgende lijst:

  1. Maak het vereiste aantal nodes aan.
  2. Voeg MariaDB-repositories toe aan alle nodes.
  3. Installeer MariaDB op alle nodes.
  4. Configureer elke server in het cluster.
  5. Open de firewall op elke server voor inter-node communicatie.
  6. Installeer en configureer de SQL Load Balancer.
  7. Start het cluster en initieer het.
  8. Controleer de nodes en de operationele status van het cluster.
  9. Beheer en voer tijdig updates uit voor de databasesoftware.

Voor onervaren gebruikers is dit een behoorlijk uitdagende en tijdrovende taak. Veel bedrijven lossen dit probleem op door over te stappen naar de richting van Databases-as-a-Service met eenvoudig te implementeren oplossingen.

MariaDB on premise
  • On-premises: biedt geen automatisering; je moet alle aspecten van de hosting handmatig beheren.
  • Infrastructure-as-a-Service (IaaS): biedt alleen automatisering met betrekking tot het besturingssysteem en hardwareonderhoud.
  • Platform-as-a-Service (PaaS): verzorgt de installatie en algemene onderhoudstaken, terwijl het beheer van de database zelf aan jou wordt overgelaten (bijv. Previder zelfbeheerde MariaDB-hosting).

MariaDB-as-a-service van Previder PaaS+

Paas+ biedt je directe clusterisatie voor de MariaDB-database, beschikbaar met een enkele beweging van een schakelaar in de topologie-wizard.

Database Replicatieschema

Het platform biedt drie verschillende MariaDB-replicatieschema's, SQL-load balancing en eenvoudige schaalbaarheid. Alle instellingen zijn verpakt in de intuïtieve GUI voor eenvoudig beheer.

Primaire-Secundaire replicatie

Wanneer je de Auto-Clustering schakelaar inschakelt, wordt het standaard Primaire-Secundaire schema van MariaDB geselecteerd. Dit schema past het beste wanneer de belangrijkste belasting leesbewerkingen zijn.

Voor de Primaire-Secundaire topologie voorzien we twee nodes, waarvan er één primair is en de andere secundair. De proxy SQL-servers worden voorzien voor het balanceren van SQL-query's. Hier is de lijst met automatisch geconfigureerde parameters inherent aan dit schema:

Server-id = {nodeId}
binlog_format = mixed
log-bin = mysql-bin
log-slave-updates = ON
expire_logs_days = 7
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replicate-wild-ignore-table = performance_schema.%
replicate-wild-ignore-table = information_schema.%
replicate-wild-ignore-table = mysql.%

Primaire-Primaire replicatie

Voor de Primaire-Primaire replicatietopologie creëren we twee databaseknooppunten die in de primaire modus werken en twee ProxySQL-load balancers voor het cluster. Overweeg dit schema wanneer de toepassing actief schrijft naar en leest uit de databases.

De lijst met automatisch geconfigureerde parameters voor deze topologie ziet er als volgt uit:

plaintextCopy code<code>server-id = {nodeId}
binlog_format = mixed
auto-increment-increment = 2
Auto-increment-offset = {1 or 2}
log-bin = mysql-bin
log-slave-updates
expire_logs_days = 7
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replicate-wild-ignore-table = performance_schema.%
replicate-wild-ignore-table = information_schema.%
replicate-wild-ignore-table = mysql.%
</code>

Galera-Cluster replicatie

Voor de Galera Cluster replicatie worden standaard drie MariaDB- en twee proxy-SQL-knooppunten toegevoegd. Als het nodig is om een gedistribueerd high-availability databasecluster over geografisch verre regio's te creëren, is de Galera-cluster de beste keuze. Houd er rekening mee dat alleen een oneven aantal knooppunten een quorum kan handhaven dat nodig is om split-brain problemen te voorkomen die kunnen optreden als gevolg van netwerkstoringen.

De automatisch geconfigureerde parameters voor deze topologie zijn als volgt:

plaintextCopy code<code>server-id = {nodeId}
binlog_format = ROW
# Galera Provider Configuration
wsrep_on = ON
wsrep_provider = /usr/lib64/galera/libgalera_smm.so
# Galera Cluster Configuration
wsrep_cluster_name = cluster
wsrep_cluster_address = gcomm://{node1},{node2},{node3}
wsrep-replicate-myisam = 1
# Galera Node Configuration
Wsrep_node_address = {node.ip}
Wsrep_node_name = {node.name}
</code>

Automatische verticale schaling

We draaien MariaDB-instanties binnen geïsoleerde systeemcontainers, die dynamisch de hoeveelheid toegewezen middelen (RAM en CPU) veranderen op basis van de huidige vraag. Geef gewoon het bovenste limiet op; het is niet nodig om je container te migreren of opnieuw te starten.

Het platform herconfigureert automatisch databaseparameters op basis van het schaalbereik om ervoor te zorgen dat nieuwe middelen kunnen worden benut:

key_buffer_size = ¼ of available RAM if total >200MB, ⅛ if <200MB
table_open_cache = 64 if total >200MB, 256 if <200MB
myisam_sort_buffer_size = ⅓ of available RAM
innodb_buffer_pool_size = ½ of available RAM


Tip: Het is mogelijk om de met het geheugen verband houdende parameters van MariaDB handmatig te configureren als dit vereist is door uw toepassing. U kunt ze wijzigen in /etc/my.cnf.

Automatic Horizontal Scaling

Je kunt eenvoudig instanties toevoegen of verwijderen met de "+" en "-" bedieningselementen in de topologie-assistent. Op basis van de vooraf geselecteerde schalingsmodus worden knooppunten toegevoegd als een lege nieuwe instantie (Stateless) of als een kloon van de primaire laag (Stateful).

Aangepaste triggers kunnen worden ingesteld om knooppunten automatisch te schalen op basis van CPU, RAM, netwerk- of schijfgebruik.

Als auto-clusterisatie is ingeschakeld, worden nieuwe knooppunten toegevoegd in overeenstemming met het clusterschema:

Primaire-Secundaire Schaling

Bij het toevoegen van een nieuw databaseknooppunt worden onderstaande stappen doorlopen door de logica voor schalen van primair naar secundair:

  1. Definieer een secundair knooppunt in de topologie
  2. Verwijder het secundaire knooppunt uit de ProxySQL-balancer-verdelingslijst
  3. Stop het secundaire knooppunt. De binlog-positie van een primaire knooppunt wordt automatisch vastgezet
  4. Kloon het secundaire knooppunt (stateful horizontaal schalen)
  5. Start het oorspronkelijke secundaire knooppunt en voeg het toe aan de ProxySQL-verdelingslijst
  6. Herconfigureer server-id en report_host op het nieuwe secundaire knooppunt
  7. Start het nieuwe secundaire knooppunt en voeg het toe aan ProxySQL
  8. Zodra alle overgeslagen transacties zijn toegepast op het nieuwe secundaire knooppunt en deze is ingehaald door het primaire knooppunt, zal ProxySQL het nieuwe secundaire knooppunt aan de verdeling toevoegen

Primair-Primair Schalen

In deze topologie gebruiken we altijd het primaire knooppunt om nieuwe secundaire knooppunten te maken. Maar al met al is het proces vergelijkbaar met het schalen van primair naar secundair en wordt het beschreven in het betreffende manifest:

  1. Definieer een tweede primair knooppunt in de topologie
  2. Verwijder het tweede primaire knooppunt uit de ProxySQL-verdelingslijst
  3. Stop het tweede primaire knooppunt, de binlog-positie wordt automatisch vastgezet
  4. Kloon het tweede primaire knooppunt (stateful horizontaal schalen)
  5. Start het tweede primaire knooppunt en voeg het toe aan de ProxySQL-verdelingslijst
  6. Herconfigureer het gekloonde knooppunt als een nieuw secundair knooppunt. (Schakel de primaire configuratie uit)
  7. Start een nieuw secundair knooppunt en voeg het toe aan ProxySQL
  8. Het eerste primaire knooppunt wordt gekozen voor verdere schaling
  9. Sequentiële keuze van primairen als verdere secundaire knooppunten zorgt voor een gelijkmatige verdeling van secundaire knooppunten tussen primairen

Galera Cluster Schaling

Voor de Galera-cluster is de situatie anders dan bij de Primaire-Primaire topologie. Hier gebruiken we een stateless schaalmodus en een andere techniek om bij te blijven met de huidige databasestatus, zie de algoritmestappen hieronder:

  1. Voeg een nieuwe node toe (stateless horizontale schaling)
  2. Configureer wsrep_cluster_name, wsrep_cluster_address, wsrep_node_address en wsrep_node_name vooraf op de nieuwe node voordat u deze aan de cluster toevoegt
  3. Voeg de nieuwe node toe aan de cluster
  4. Voeg de nieuwe node toe aan ProxySQL (niet voor distributie)
  5. De cluster wijst automatisch een donor toe uit bestaande nodes en voert de State Snapshot Transfer uit vanaf die donor naar de nieuwe node
  6. Zodra de synchronisatie is voltooid, neemt ProxySQL de node op in de distributie van de verzoeken.

Standaard en custom waarschuwingen

Previder PaaS+ biedt een reeks waarschuwingen om automatisch hoge (d.w.z. dicht bij de limiet) resource-gebruik te detecteren en u hiervan op de hoogte te stellen. Je kunt de standaardwaarschuwingen aanpassen aan jouw behoeften en aanvullende voorwaarden toevoegen om te volgen of het gebruik van een bepaald type resource boven/onder de opgegeven waarde (%) ligt gedurende de juiste periode.


Als een waarschuwing wordt geactiveerd, ontvangt u een e-mailmelding over de wijziging in de belasting van uw applicatie.


Anti-Affiniteitsregels

Om extra hoge beschikbaarheid en failover-bescherming te garanderen, worden alle nieuw toegevoegde containers van dezelfde laag gemaakt op verschillende fysieke hosts.

Als de replicatietopologie bijvoorbeeld bestaat uit twee knooppunten, zullen ze worden ingezet op verschillende hosts, zoals getoond in de bovenstaande afbeelding. In zo'n geval, als één fysiek knooppunt uitvalt, zal je database nog steeds werken op de andere hosts.

Automatische afhandeling van OOM Killer-gebeurtenissen

Wanneer een toepassing geen geheugen meer heeft, biedt het besturingssysteem twee manieren om dit probleem op te lossen: het hele systeem laten crashen of het proces (de toepassing) beëindigen dat geheugen gebruikt. Natuurlijk is het beter om het proces te beëindigen en het besturingssysteem te redden van een crash. Kort gezegd is de Out-Of-Memory Killer het proces dat de toepassing beëindigt om de kernel te redden van een crash. Het offert de toepassing op om het besturingssysteem draaiende te houden.

In Jelastic speelt het Out-of-Memory (OOM) Killer-proces een belangrijke rol in dit scenario en voorkomt het dat de kernel in paniek raakt. Wanneer het MariaDB-proces gedwongen wordt beëindigd, verschijnt er een bericht in het logbestand /var/log/messages om informatie te geven dat de OOM Killer is geactiveerd.

Als de OOM Killer het MariaDB-proces beëindigt, past Jelastic automatisch de databaseconfiguraties aan door de innodb_buffer_pool_size parameter met 10% te verminderen. Vervolgens wordt de container opnieuw opgestart om de werking te herstellen. In het geval dat de situatie zich opnieuw voordoet, wordt de genoemde autoconfiguratiecyclus herhaald.

Je kunt de omgevingsvariabelen aanpassen om het systeemgedrag met betrekking tot het OOM-killprobleem aan te passen:

  • JELASTIC_AUTOCONFIG - schakelt Jelastic-autoconfiguratie in/uit (true/false)
  • OOM_DETECTION_DELTA - stelt het tijdsinterval in (standaard twee seconden) voor Jelastic waarin het /var/log/messages-logbestand kan analyseren na elke serviceherstart om te bepalen of de OOM Killer hiervoor verantwoordelijk was
  • OOM_ADJUSTMENT - definieert een waarde in %, MB, GB (standaard 10%) die de huidige innodb_buffer_pool_size-parameter na elke door OOM veroorzaakte herstart moet verminderen
  • MAX_OOM_REDUCE_CYCLES - configureert het maximale aantal cycli voor het verminderen van innodb_buffer_pool_size (standaard 5 keer)

Nu ben je op de hoogte van de belangrijkste kenmerken die zijn geïmplementeerd voor MariaDB-hosting in Previder PaaS+. Probeer het zelf uit op een van de beschikbare platforms over de hele wereld.