Master-slave databasereplicatie

Naast het Percona databasecluster met Galera replicatie heeft Secure Webhosting ook een MariaDB Databasecluster, bestaande uit één Master node en één Slave node.

De Master-slave replicatiemethode komt veel voor bij MySQL databases. De methode gaat uit van één Master server (node) die data leest én schrijft, en één of meer Slave servers (nodes) die uitsluitend data lezen. Data van de Master node wordt asynchroon (na voltooiing van een databasetransactie) gerepliceerd naar de Slave nodes, zodat de dataconsistentie hoger is. Vervolgens bevestigen de Slave nodes de verwerking van de gerepliceerde data aan de Master node, voordat de Master node nieuwe data wegschrijft.

Voordelen van Master-slave replicatie t.o.v. Galera replicatie

  1. Breder inzetbaar door minder restricties op de communicatiewijze tussen applicatie en database (zie verderop in dit artikel).
  2. Eenvoudiger en daardoor beter te onderhouden.
  3. Back-ups van een database kunnen worden gemaakt zonder belasting van de Master node.
  4. Er is geen quorum nodig (een minimaal aantal nodes). Master-slave replicatie werkt al met 2 nodes in plaats van minimaal 3 bij Galera replicatie.
  5. Netwerkstoringen hebben vrijwel geen effect op het herstel van een Master-Slave opzet. 

Nadelen van Master-slave replicatie t.o.v. Galera replicatie

  1. Mogelijk dataverlies bij een crash van de Master node, omdat er gebruik wordt gemaakt van een asynchrone replicatiemethode. 
  2. Minder schaalbaar, omdat uitsluitend de leesverzoeken kunnen worden verdeeld over meerdere nodes. Bij Galera replicatie is het mogelijk om lees- en schrijfverzoeken te verdelen.
  3. In het geval van een storing van de Master node moet een Slave node de Master taak overnemen. Dit proces is geautomatiseerd, maar het kost een aantal seconden. In de tussentijd kunnen storingen op de website zichtbaar zijn.
  4. Iedere extra Slave node leidt tot extra belasting van de Master node, omdat de data op de Master node naar iedere Slave node gekopieerd moet worden. 

Waarom maakt Secure Webhosting gebruik van twee typen Databaseclusters?

Percona clustering met Galera replicatie werkt voor sommige applicaties niet naar behoren, vanwege limitaties.

Zogenaamde DDL Statements (CREATE, ALTER en DROP) zorgen namelijk voor een stop in datareplicatie totdat zijn uitgevoerd op de Master node.

Voor veel applicaties is dat geen probleem. Echter is het zo dat (bijvoorbeeld) Magento deze DDL Statements intensief gebruikt. 

Om die reden is er naast het Percona databasecluster ook een MariaDB databasecluster met Master-Slave replicatie beschikbaar.

Back-ups

Van applicaties worden in alle omgevingen back-ups gemaakt van de databases en mediafile folders. Het is niet nodig om back-ups van de webservers te maken, omdat deze automatisch opnieuw kunnen worden gedeployed en geen persistente gegevens bevatten. De databases en media files zijn op seperate clusters opgeslagen.

  • Back-ups hebben betrekking op de databases en mediafile folders van projecten.
  • Back-ups hebben betrekkingen op alle omgevingen.
  • Back-ups worden twee keer per etmaal gemaakt in de context van Disaster Recovery, betekent dit een Recovery Point Objective (RPO) van 12 uur. Deze back-ups zijn opgeslagen op een aparte server in hetzelfde datacenter en worden 2 dagen bewaard.
  • Eén keer per dag wordt een ander type back-up gemaakt. Deze back-ups worden in twee datacenters opgeslagen (één kopie bevindt zich dus op een andere locatie). Voor het maken van deze back-ups wordt een schema gevolgd van zeven dagen, vier weken en twaalf maanden. Dit wil zeggen dat de dagelijkse back-up zeven dagen wordt bewaard. Vervolgens wordt de back-up van de achtste dag verwijderd. Uitzondering hierop vormen de back-ups van zondagen. Hiervan worden vier exemplaren bewaard. Ook wordt de back-up van de laatste dag van de maand bewaard. Hiervan worden twaalf exemplaren bewaard.
  • Op werkdagen wordt gecontroleerd of het back-up proces goed is verlopen. Indien dit niet het geval is, wordt dit als PRIO2 storing gemeld. Er wordt naar gestreefd om het probleem nog diezelfde dag te verhelpen, zodat de volgende back-up zonder problemen kan verlopen.