Hoge Beschikbaarheid en Veerkracht in Databases met MaxScale

Mission-critical applicaties vereisen hoge beschikbaarheid. Het doel van hoge beschikbaarheid is om gebruikers consistent toegang te bieden tot diensten of middelen, waarbij de kans op onderbrekingen wordt geminimaliseerd. Automatische failover is een specifiek mechanisme dat wordt gebruikt om hoge beschikbaarheid te bereiken. Het omvat het automatisch detecteren van het falen van een systeemcomponent (zoals een server, netwerk of database) en onmiddellijk over te schakelen naar een reservecomponent zonder tussenkomst van mensen. Dit verhoogt de betrouwbaarheid.

MariaDB MaxScale is een database proxy die functies voor hoge beschikbaarheid bevat. In dit artikel zal ik laten zien hoe je dit kunt uitproberen met een online winkelsimulator applicatie die is geïmplementeerd in Java en Svelte.

Architectuur

Het volgende diagram toont de architectuur van de demo-applicatie:

A web application developed with JavaScript and the Svelte framework makes HTTP requests to a Java backend. The backend answers with server-sent events that the frontend uses to update the user interface on the browser.

De backend is geïmplementeerd met Spring Boot en verbindt zich met een MariaDB databasecluster via R2DBC (reactiv). De backendlogica is in korte termijn een simulatie van lees- en schrijfbewerkingen naar een online winkeldatabase. De simulatie is geparametriseerd en de gebruiker kan aanpassen:

• Productbezoeken per minuut: Hoeveel leesbewerkingen naar de database per minuut.
• Bestellingen per minuut: Hoeveel schrijfbewerkingen naar de database per minuut.
• Producten per bestelling: Schrijfversterking.
• Time-out in milliseconden: Hoeveel seconden tot een aanvraag bij de database als mislukt wordt beschouwd.

De databasecluster wordt voorafgegaan door een databaseproxy genaamd MaxScale. Deze proxy laat de cluster eruit zien als een enkele logische database voor de Java backend. MaxScale voert ook lezen/schrijven splitsing uit (het sturen van schrijfbewerkingen naar de primaire MariaDB-server en leesbewerkingen naar replica’s), evenals load balancing van leesbewerkingen onder replica-servers met behulp van een configureerbaar algoritme. Gegevens worden automatisch gedupliceerd van de primaire naar de replica-databaseservers.

Bouwen van de Docker-afbeeldingen uit bron

I have prepared custom Docker images for every component in the simulator. You can either build the images from the source (optional) or use the already built and published images from Docker Hub. If you decide to build the images yourself, you can find the source code on GitHub:

• MariaDB-implementaties: Aangepaste afbeeldingen voor eenvoudige implementatie van gerepliceerde MariaDB-topologieën met MaxScale. GEBRUIK DEZE IN PRODUCTIE NIET! Deze afbeeldingen zijn alleen geschikt voor demo-toepassingen. Gebruik de officiële MariaDB Docker-afbeeldingen voor productie-implementaties.
• Backend-toepassing: De backend-toepassing die verbinding maakt met de databasecluster.
• Frontend-toepassing: De frontend-toepassing die simulatieconfiguratieaanvragen stuurt naar de backend en gebeurtenissen ontvangt om het simulatieresultaat te laten zien.

Elke repository bevat Dockerfiles die u kunt gebruiken om uw eigen Docker-afbeeldingen te bouwen. Om bijvoorbeeld de afbeelding van de backend-toepassing te bouwen, voer uit:

docker build --tag alejandrodu/online-store-simulator-java-backend .

Het uitvoeren van de Simulatie

Alle services kunnen worden gestart met behulp van het volgende Docker Compose-bestand (docker-compose.yml):

version: "3.9"
services:
  server-1:
    container_name: server-1
    image: alejandrodu/mariadb
    ports:
      - "3306:3306"
    environment:
      - MARIADB_CREATE_DATABASE=demo
      - MARIADB_CREATE_USER=user:Password123!
      - MARIADB_CREATE_REPLICATION_USER=replication_user:ReplicationPassword123!
      - MARIADB_CREATE_MAXSCALE_USER=maxscale_user:MaxScalePassword123!

  server-2:
    container_name: server-2
    image: alejandrodu/mariadb
    ports:
      - "3307:3306"
    environment:
      - MARIADB_REPLICATE_FROM=replication_user:ReplicationPassword123!@server-1:3306

  server-3:
    container_name: server-3
    image: alejandrodu/mariadb
    ports:
      - "3308:3306"
    environment:
      - MARIADB_REPLICATE_FROM=replication_user:ReplicationPassword123!@server-1:3306

  maxscale:
    container_name: maxscale
    image: alejandrodu/mariadb-maxscale
    command: --admin_host 0.0.0.0 --admin_secure_gui false
    ports:
      - "4000:4000"
      - "8989:8989"
      - "27017:27017"
    environment:
      - MAXSCALE_USER=maxscale_user:MaxScalePassword123!
      - MARIADB_HOST_1=server-1 3306
      - MARIADB_HOST_2=server-2 3306
      - MARIADB_HOST_3=server-3 3306
    healthcheck:
      test: ["CMD", "maxctrl", "list", "servers"]
      interval: 5s
      timeout: 10s
      retries: 5

  java-backend:
    container_name: java-backend
    image: alejandrodu/online-store-simulator-java-backend
    ports:
      - "8080:8080"
    environment:
    - spring.r2dbc.url=r2dbc:mariadb://maxscale:4000/demo
    - spring.r2dbc.username=user
    - spring.r2dbc.password=Password123!
    - spring.liquibase.url=jdbc:mariadb://maxscale:4000/demo
    - spring.liquibase.user=user
    - spring.liquibase.password=Password123!
    depends_on:
      maxscale:
        condition: service_healthy

  svelte-frontend:
    container_name: svelte-fronted
    image: alejandrodu/online-store-simulator-svelte-frontend
    ports:
      - "5173:80"
    environment:
      - BACKEND_URL=http://java-backend:8080

Ga naar de map waarin het Docker Compose-bestand zich bevindt, en start de services in gedetacheerde modus als volgt:

docker compose up -d

MaxScale configureren

Voordat u de simulatie start, configureer MaxScale voor transactieherhaling. Pas bovendien time-outs aan om de simulatie interessanter te maken.

Navigeer naar http://localhost:8989/ en log in op de UI met:

• Gebruikersnaam:admin
• Wachtwoord:mariadb

Je zult een dashboard zien met de status van de MariaDB-cluster.

Er is een primair server (server-1), en twee replica’s (server-2 en server-3). De replicatie is al geconfigureerd van server-1 (primaire) naar server-2 en server-3 (replica’s). Alle servers moeten actief en draaien.

Klik op mdb_monitor en vervolgens op het potlood pictogram om parameters aanpassen te kunnen. Stel de volgende parameters in:

• auto_failover (true): Dit activeert automatische failover. Wanneer een MariaDB-server uitvalt, selecteert MaxScale een replica-server en configureert deze als de nieuwe primaire zodat schrijfbewerkingen kunnen doorgaan.
• auto_rejoin (true): Dit activeert automatische hertoevoeging van herstelde servers. Wanneer een mislukte server weer actief is, detecteert MaxScale deze en configureert deze als een beschikbare replica-server.
• failcount (1): Stelt het aantal monitor-iteraties (een component in MaxScale dat de serverstatus controleert) in dat nodig is voor een server om uit te vallen om het failoverproces te activeren. We stellen een waarde van 1 in om ervoor te zorgen dat de failover onmiddellijk na mislukking start.
• backend_connect_timeout (1000): Verbindings time-out voor monitorverbindingen. We stellen een lage waarde (één seconde) in om snel failover voor deze demo te activeren.
• backend_read_timeout (1000): Lees time-out voor monitorverbindingen.
• backend_write_timeout (1000): Schrijf time-out voor monitorverbindingen.
• master_failure_timeout (1000): Primaire fout time-out.
• monitor_interval (1000): Hoe vaak de servers worden gecontroleerd.

WAARSCHUWING: Deze waarden zijn geschikt voor deze demo, maar zeer waarschijnlijk niet de beste voor productieomgevingen!

Zodra de parameters zijn ingesteld, klik op Klaar met bewerken en Bevestigen.

Je moet ook transactie replay inschakelen, die mislukte in-flight transacties automatisch opnieuw uitvoert op servers die net na een SQL-statement zijn neergedraaid. Dit is een handige functie voor softwareontwikkelaars, aangezien het de noodzaak om foutgevallen en transactie-herproef te coderen voorkomt.

Klik op het hoofdmenu op Dashboard en vervolgens op een van de query_router_service links in de lijst met servers. Pas de parameters als volgt aan:

• transaction_replay (true): Activeert automatische herproef van mislukte transacties.
• transaction_replay_retry_on_deadlock (true): Gelijk aan het vorige wanneer een deadlock optreedt.
• transaction_replay_retry_on_mismatch (true): Gelijk aan het vorige wanneer een controlesommismatch optreedt.

Zodra de parameters zijn ingesteld, klik op Klaar met bewerken en Bevestigen.

Start de simulatie

Met alles geconfigureerd, kun je de simulatie starten. Navigeer naar http://localhost:5173/ en configureer de volgende parameters (de namen zijn, hopelijk, zelfverklarend):

• Productbezoeken per minuut:6000
• Bestellingen per minuut:60
• Time-out in milliseconden:8000

Maar voordat je de simulatie start, moet je de producten voor de webwinkel aanmaken. Klik op Data | Producten aanmaken…. Laat de standaardwaarden staan en klik op Aanmaken. Je zou de UI moeten zien updaten terwijl producten in de database worden aangemaakt.

Nu kun je eindelijk klikken op Start en de simulatie in actie zien.

Simuleren van een Serverstoring

Op dit punt verwerkt de primaire server schrijfbewerkingen (bestellingen). Wat gebeurt er als je die server stopt? Voer in de command line uit:

docker stop server-1

Afhankelijk van meerdere factoren krijg je misschien wat “teleurgestelde bezoekers” of zelfs een paar “gemiste kansen” in de simulator. Of misschien krijg je er helemaal geen! Productbezoeken (lezen) en bestellingen (schrijven) gaan door dankzij MaxScale. Zonder automatische failover moet je alles handmatig herconfigureren, wat resulteert in meer offline tijd en in veel teleurgestelde bezoekers en gemiste kansen!

Start de gestoorde server:

docker start server-1

Ga naar het MaxScale Dashboard (http://localhost:8989/) en controleer of server-1 nu een functionerende replica is.

U kunt een handmatige switchover uitvoeren om server-1 weer de primaire server te maken. Klik op mdb_monitor en hover vervolgens met de muis over het MASTER gedeelte. Klik op het potlood pictogram en selecteer server-1. Klik op Swap en controleer opnieuw in het Dashboard of de nieuwe primaire server server-1 is.

Conclusie

Automatische failover is slechts één van de componenten in zeer beschikbare systemen. U kunt een database proxy zoals MaxScale gebruiken om automatische failover in te stellen, maar ook andere componenten zoals load balancing, query routing, transactie herhaling, topologie-isolatie, en meer. Bekijk de documentatie hier.