maxscale

Table of contents

• Overview
• Preparations
• Activate MaxScale configuration synchronisation
• Change MaxScale parameters
• Add new slave and make MaxScale known
• Remove old slave and make MaxScale known
• How is the configuration synchronised?

Inhaltsverzeichnis

• Übersicht
• Vorbereitungen
• MaxScale Konfigurations-Synchronisation aktivieren
• MaxScale Parameter ändern
• Neuer Slave hinzufügen und MaxScale bekannt machen
• Alter Slave entfernen und MaxScale bekannt machen

Table of contents

• Overview
• Preparation of the shards (MariaDB database instances)
• Create test data
• Creating roles and users
• MaxScale Monitor User
• MaxScale Admin User
• Create application role and accounts

Inhaltsverzeichnis

• Übersicht
• Vorbereitung der Shards (MariaDB Datenbank Instanzen)
• Testdaten erstellen
• Rollen und User erstellen
• MaxScale Monitor User
• MaxScale Admin User
• Applikationsrolle und Accounts erstellen

For this how-to we were working with a MariaDB 10.6.5 database server and the newest MariaDB MaxScale 6.3.0 (aka 2.6) load balancer/proxy.

As a starting point we had a working MariaDB Master/Master replication with one active Master (M_a) and one passive Master (M_p). Whereas the passive Master was set to read_only. As a replication user we used the user replication.

Recently we had the case that a customer claimed that MariaDB 10.3 Binary Log is using 150% more space on disk than MySQL 5.7 Binary Log. Because I never observed something similar, but to be honest, I did not look to intensively for this situation, we had to do some clarifications.

First we checked the usual variables which could be candidates for such a behaviour: