Alta Disponibilità e Resilienza nei Database con MaxScale

Le applicazioni a missione critica richiedono alta disponibilità. L’obiettivo dell’alta disponibilità è fornire agli utenti un accesso costante ai servizi o alle risorse, minimizzando le possibilità di interruzione. Failover automatico è un meccanismo specifico utilizzato per raggiungere l’alta disponibilità. Esso prevede la rilevazione automatica di un guasto di un componente del sistema (come un server, una rete o un database) e il passaggio immediato delle operazioni a un componente di riserva senza intervento umano. Ciò aumenta la resilienza.

MariaDB MaxScale è un proxy per database che include funzionalità per l’alta disponibilità. In questo articolo, ti mostrerò come poterlo provare con un’applicazione simulatore di negozio online implementata in Java e Svelte.

Architettura

Il seguente diagramma mostra l’architettura dell’applicazione dimostrativa:

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.

Il backend è implementato con Spring Boot e si connette a un cluster di MariaDB utilizzando R2DBC (reattivo). La logica backend è, in breve, una simulazione di letture e scritture a un database di negozi online. La simulazione è parametrizzata e l’utente può regolare:

• Visite prodotto al minuto: Quante letture al database al minuto.
• Ordini al minuto: Quante scritture al database al minuto.
• Prodotti per ordine: Aumento della scrittura.
• Timeout in millisecondi: Quanti secondi prima che una richiesta al database sia considerata fallita.

Il cluster del database è front-ended da un proxy del database chiamato MaxScale. Questo proxy fa apparire il cluster come un singolo database logico al backend Java. MaxScale esegue anche lo splitting di lettura/scrittura (inviando scritture al server primario MariaDB e letture alle repliche), nonché il bilanciamento del carico delle letture tra i server replica utilizzando un algoritmo configurabile. I dati vengono automaticamente replicati dal primario ai server di database replica.

Creazione delle immagini Docker a partire dalle sorgenti

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:

• Distribuzioni MariaDB: Immagini personalizzate per facilitare la distribuzione di topologie MariaDB replicate con MaxScale. NON USARE QUESTE IMMAGINI IN PRODUZIONE! Queste immagini sono adatte solo per applicazioni dimostrative. Utilizza le immagini Docker ufficiali di MariaDB per le distribuzioni in produzione.
• Applicazione backend: L’applicazione backend che si connette al cluster di database.
• Applicazione frontend: L’applicazione frontend che invia richieste di configurazione della simulazione al backend e riceve eventi per mostrare il risultato della simulazione.

Ogni repository contiene Dockerfiles che puoi utilizzare per costruire le tue immagini Docker. Ad esempio, per costruire l’immagine dell’applicazione backend, esegui:

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

Esecuzione della Simulazione

Tutti i servizi possono essere avviati utilizzando il seguente file Docker Compose (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

Spostati nella directory in cui si trova il file Docker Compose e avvia i servizi in modalità separata come segue:

docker compose up -d

Configurazione di MaxScale

Prima di avviare la simulazione, configura MaxScale per il replay delle transazioni. Inoltre, regola i timeout per rendere la simulazione più interessante.

Vai su http://localhost:8989/ e accedi all’interfaccia utente utilizzando:

• Nome utente:admin
• Password:mariadb

Vedrai un dashboard con lo stato del cluster MariaDB.

C’è un server primario (server-1), e due repliche (server-2 e server-3). La replica è già configurata da server-1 (primario) a server-2 e server-3 (repliche). Tutti i server dovrebbero essere in esecuzione.

Fai clic su mdb_monitor e poi sull’icona della matita per abilitare la modifica dei parametri. Imposta i seguenti parametri:

• auto_failover (true): Questo abilita il failover automatico. Quando un server MariaDB è spento, MaxScale seleziona un server replica e lo riconfigura come nuovo primario in modo che le scritture possano continuare a verificarsi.
• auto_rejoin (true): Questo abilita il reinserimento automatico dei server recuperati. Quando un server guasto è di nuovo attivo, MaxScale lo rileva e lo configura come server replica disponibile.
• failcount (1): Imposta il numero di iterazioni del monitor (un componente in MaxScale che controlla lo stato del server) richiesto affinché un server sia spento per attivare il processo di failover. Impostiamo un valore di 1 per assicurarci che il failover inizi immediatamente dopo il fallimento.
• backend_connect_timeout (1000): Timeout di connessione per le connessioni del monitor. Impostiamo un valore basso (un secondo) per attivare rapidamente il failover per questa demo.
• backend_read_timeout (1000): Timeout di lettura per le connessioni di monitoraggio.
• backend_write_timeout (1000): Timeout di scrittura per le connessioni di monitoraggio.
• master_failure_timeout (1000): Timeout di fallimento primario.
• monitor_interval (1000): Frequenza con cui i server vengono monitorati.

AVVERTENZA: Questi valori sono appropriati per questa demo, ma molto probabilmente non sono i migliori per ambienti di produzione!

Una volta impostati i parametri, cliccare su Fine Modifica e Conferma.

È inoltre necessario abilitare il replay delle transazioni che ri-esegue automaticamente le transazioni in corso fallite sui server che sono andati giù subito dopo che una dichiarazione SQL è stata instradata. Questa è una caratteristica utile per i programmatori in quanto evita la necessità di codificare casi di fallimento e ripetizione delle transazioni.

Nel menu principale, cliccare su Dashboard e poi su uno qualsiasi dei link query_router_service nell’elenco dei server. Modificare i parametri come segue:

• transaction_replay (true): Attiva il retry automatico delle transazioni fallite.
• transaction_replay_retry_on_deadlock (true): Come il precedente in caso di deadlock.
• transaction_replay_retry_on_mismatch (true): Come il precedente in caso di mismatch di checksum.

Una volta impostati i parametri, cliccare su Fine Modifica e Conferma.

Avvio della Simulazione

Con tutto configurato, puoi iniziare la simulazione. Naviga su http://localhost:5173/ e configura i seguenti parametri (i nomi, spero, sono auto-esplicativi):

• Visite prodotti al minuto:6000
• Ordini al minuto:60
• Timeout in millisecondi:8000

Ma prima di avviare la simulazione, devi creare i prodotti per il negozio online. Clicca su Dati | Crea prodotti…. Lascia i valori predefiniti e clicca su Crea. Dovresti vedere l’interfaccia utente aggiornarsi mentre i prodotti vengono creati nel database.

Ora puoi finalmente cliccare su Avvia e vedere la simulazione in azione.

Simulazione di un Fallimento del Server

A questo punto, il server primario gestisce le scritture (ordini). Cosa succede se fermi quel server? Nella riga di comando esegui:

docker stop server-1

A seconda di diversi fattori potresti avere alcuni “visitatori delusi” o addirittura alcune “occasioni mancate” nel simulatore. O forse non ne ottieni affatto! Le visite ai prodotti (letture) e gli ordini (scritture) continuano grazie a MaxScale. Senza failover automatico, devi riconfigurare tutto manualmente, il che si traduce in più tempo offline e in molti visitatori delusi e occasioni mancate!

Avvia il server guasto:

docker start server-1

Vai alla Dashboard di MaxScale (Dashboard http://localhost:8989/) e verifica che server-1 sia ora una replica funzionante.

Puoi eseguire una commutazione manuale per rendere server-1 il server principale di nuovo. Fai clic su mdb_monitor e poi passa il mouse sul MASTER sezione. Fai clic sull’icona della matita e seleziona server-1. Clicca su Scambia e controlla di nuovo nel Dashboard che il nuovo server principale è server-1.

Conclusione

La failover automatica è solo uno dei componenti nei sistemi ad alta disponibilità. Puoi utilizzare un proxy di database come MaxScale per impostare la failover automatica, ma anche altri componenti come il bilanciamento del carico, la routing delle query, il retry delle transazioni, l’isolamento topologico e altro ancora. Dai un’occhiata alla documentazione qui.