Lesen lernen: Der MySQL InnoDB Cluster & Read Replicas

Mit dem brandneuen Innovation Release 8.1.0 hat Oracle dem MySQL InnoDB Cluster wieder ein neues „Feature“ spendiert: „Read Replicas“. Darüber lässt sich ein InnoDB Cluster um weitere, reinlesenden Instanzen ergänzen. Wie dies funktioniert und warum dies Sinn ergeben kann, erfahren Sie in diesem Beitrag. 

A, B, C

Ein InnoDB Cluster besteht in der Regel aus drei Knoten, welche in einer „shared nothing“-Architektur Daten hochverfügbar bereitstellen. Der Ausfall eines Knotens stellt so z. B. für den Betrieb einer Anwendung, aus Datenbank-Perspektive, kein Problem dar. Der Preis für dieser Art der Verfügbarkeit wird über Latenzen eingekauft. Da Transaktionen in einem Cluster immer von allen beteiligten Knoten verarbeitet werden müssen, kann es zu längeren Laufzeiten kommen. Wir haben bereits umfangreich über den InnoDB Cluster an dieser Stelle berichtet.

Dies ist z. B. dann problematisch, wenn die Knoten eines Clusters geografisch weit auseinanderliegen und damit naturgemäß die Latenzen höher werden. In solchen Fällen kann es hilfreich sein, einen Cluster eher aus lokal nah zusammenliegenden Knoten aufzubauen und auf ein geografisch entfernteres System zu replizieren. Dies war bis dato nicht einfach möglich, da die replizierenden Systeme Kenntnis vom Cluster haben müssen. Im Fall des Ausfalls eines Knotens im Cluster soll das Replikat „einfach“ von einem anderen Knoten weiter replizieren. Dies ist nun möglich.

Die richtigen Worte finden

Zur Demonstration setzen wir mittels der MySQL Shell einen „europäischen“ InnoDB Cluster aus den Systemen „frankfurt“, „hamburg“ und „berlin“ auf. Unser Cluster trägt den Namen „ordix“. Aus Gründen der Übersichtlichkeit haben wir die Ausgaben der Kommandos gekürzt. Die Kommandos an sich wurden jedoch fett hervorgehoben: 

MySQL  frankfurt:3306 ssl  JS > dba.createCluster('ordix')

A new InnoDB Cluster will be created on instance 'frankfurt:3306'.
Validating instance configuration at frankfurt:3306...
...
MySQL  frankfurt:3306 ssl  JS > var clu = dba.getCluster('ordix')
MySQL  frankfurt:3306 ssl  JS > clu.addInstance('root:root@berlin:3306')
...
Adding instance to the cluster...
...
The instance 'berlin:3306' was successfully added to the cluster.

MySQL  frankfurt:3306 ssl  JS > clu.addInstance('root:root@hamburg:3306')
...
The instance 'hamburg:3306' was successfully added to the cluster. 

Lesen lernen

Um den Cluster um ein „Read Replica“ zu erweitern, nutzen wir wieder den Komfort der MySQL Shell. Der grundlegende Aufruf besteht nur aus einem Kommando.

Bei Bedarf können aber sehr fein granular Parameter genutzt werden, um den Aufbau des „Replicas“ zu manipulieren. So kann neben dem Namen des Replikats, die Quelle des Klonprozesses bestimmt werden, auf welchen Systemen ein „Failover“ stattfinden und von welchem System die Replikation generell Daten lesen soll.

clu.addReplicaInstance('newyork:3306', {label: 'ReplicateUSA', replicationSources: ['hamburg:3306','Berlin:3306'], recoveryMethod: 'clone', cloneDonor: 'hamburg:3306'});
…
* Configuring Read-Replica managed replication channel...
** Changing replication source of newyork:3306 to hamburg:3306

* Waiting for Read-Replica 'newyork:3306' to synchronize with Cluster...
** Transactions replicated  ############################################################  100%

'newyork:3306' successfully added as a Read-Replica of Cluster 'ordix'. 

Das Ergebnis unserer Bemühungen können wir, wie gewohnt, mit dem Cluster Status überprüfen: 

MySQL  frankfurt:3306 ssl  JS > clu.status()
{
    "clusterName": "ordix",
    "defaultReplicaSet": {
        "name": "default",
        "primary": "frankfurt:3306",
        "ssl": "REQUIRED",
        "status": "OK",
        "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
        "topology": {
            "berlin:3306": {
                "address": "berlin:3306",
                "memberRole": "SECONDARY",
                "mode": "R/O",
                "readReplicas": {},
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE",
                "version": "8.1.0"
            },
            "frankfurt:3306": {
                "address": "frankfurt:3306",
                "memberRole": "PRIMARY",
                "mode": "R/W",
                "readReplicas": {},
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE",
                "version": "8.1.0"
            },
            "hamburg:3306": {
                "address": "hamburg:3306",
                "memberRole": "SECONDARY",
                "mode": "R/O",
                "readReplicas": {
                    "ReplicateUSA": {
                        "address": "newyork:3306",
                        "role": "READ_REPLICA",
                        "status": "ONLINE",
                        "version": "8.1.0"
                    }
                },
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE",
                "version": "8.1.0"
            }
        },
        "topologyMode": "Single-Primary"
    },
    "groupInformationSourceMember": "frankfurt:3306"
}
 

Zusammenfassung

Oracle entwickelt den MySQL InnoDB Cluster immer weiter. Nach dem vor Kurzem eingeführten „Replica Sets“ folgen nun konsequenterweise die „Read Replicas“. Sie verbinden den Cluster mit den Vorteilen einer „normalen“ Replikation. Wir selbst haben bereits den ersten Kunden, der sehnsüchtig auf dieses „Feature“ wartet, um seine Umgebung sicherer zu gestalten.

Sie haben Fragen rund um den Betrieb von MySQL? Sprechen Sie mit uns.

Seminarempfehlung