Replikationsfilter gezielt einsetzen: nur relevante Daten replizieren

1. Warum Replikationsfilter: Reporting-Replicas und Multi-Store-Setups

Ein vollständiger Replica repliziert per Voreinstellung jede Datenbank und jede Tabelle des Sources, unabhängig davon, ob dieser Datenbestand am Zielsystem überhaupt benötigt wird. Für ein Reporting-System, das nur auf aggregierte Bestell- und Produktdaten zugreift, bedeutet das unnötig übertragenes Datenvolumen und, deutlich kritischer, eine unnötige Kopie sensibler Tabellen wie Kundenadressen oder Zahlungsdaten an einem Ort, der eigentlich keinen Zugriff darauf benötigt.

Replikationsfilter setzen genau hier an: Sie erlauben, auf Datenbank- oder Tabellenebene festzulegen, welche Teile des Binlogs überhaupt auf einem bestimmten Replica angewendet werden. Für Multi-Store-Umgebungen mit einer separaten Datenbank je Mandant ergibt sich daraus ein zweiter, ebenso praktischer Anwendungsfall: Ein Replica kann gezielt nur die Datenbank eines einzelnen Mandanten führen, etwa für einen dedizierten, mandantenspezifischen Analyse- oder Support-Server.

2. Statement-basierte Filter auf Instanzebene: replicate-do-db und replicate-ignore-db

Die einfachste Filterebene wirkt auf ganze Datenbanken: replicate-do-db beschränkt die Replikation auf explizit genannte Datenbanken, replicate-ignore-db schließt genannte Datenbanken aus und repliziert alles Übrige. Bei statement-basierter Replikation wertet der Server dabei die aktuell über USE gesetzte Datenbank aus, nicht die tatsächlich betroffenen Tabellen innerhalb des Statements.

Genau diese Auswertungslogik ist eine häufige Fehlerquelle bei Cross-Database-Statements: Ein UPDATE reporting_db.summary SET ... WHERE EXISTS (SELECT 1 FROM shop_db.orders ...) wird ausschließlich anhand der über USE aktiven Datenbank gefiltert, selbst wenn das Statement inhaltlich auf eine andere, eigentlich ausgeschlossene Datenbank zugreift. Wer mit solchen datenbankübergreifenden Abfragen arbeitet, sollte Datenbank-Level-Filter mit besonderer Vorsicht einsetzen oder auf tabellenbasierte Filter ausweichen.

# In der Konfigurationsdatei des Replicas (mysqld-Sektion)
replicate-do-db = shop_db
replicate-ignore-db = shop_db_reporting_intern

3. Tabellenebene: replicate-do-table und Wildcard-Filter

Deutlich präziser arbeiten Filter auf Tabellenebene: replicate-do-table und replicate-ignore-table nehmen einzelne, vollständig benannte Tabellen ins Visier, während replicate-wild-do-table und replicate-wild-ignore-table Wildcard-Muster mit % und _ erlauben, etwa um alle Tabellen eines bestimmten Präfixes gezielt auszuschließen. Für ein Reporting-Replica lassen sich damit gezielt einzelne sensible Tabellen ausschließen, ohne gleich die gesamte Datenbank vom Datenbank-Level-Filter betroffen zu machen.

Ein typisches Muster für einen Magento-nahen Reporting-Replica schließt Tabellen mit personenbezogenen oder zahlungsbezogenen Daten explizit aus, während der überwiegende Teil des Schemas für Auswertungen erhalten bleibt. Wichtig dabei: Die Filterung erfolgt weiterhin auf Ebene ganzer Tabellen, eine spaltenweise Filterung, etwa um nur bestimmte Felder einer Kundentabelle auszuschließen, unterstützt die native MySQL-Replikationsfilterung nicht.

replicate-wild-ignore-table = shop_db.customer_entity%
replicate-wild-ignore-table = shop_db.sales_order_payment%
replicate-wild-ignore-table = shop_db.customer_address_entity%

4. Wie MySQL die Filter-Reihenfolge auswertet

Sind sowohl Do- als auch Ignore-Regeln gleichzeitig aktiv, wertet der Server die Do-Regeln zuerst aus: Existiert mindestens eine replicate-do-table- oder replicate-wild-do-table-Regel, wird ein Event nur repliziert, wenn es explizit von einer dieser Regeln erfasst wird, unabhängig davon, ob zusätzlich Ignore-Regeln definiert sind. Erst wenn keine Do-Regel greift, aber auch keine passt, kommen die Ignore-Regeln zum Tragen und schließen explizit genannte Muster aus einer ansonsten vollständigen Replikation aus.

Diese Reihenfolge widerspricht oft der intuitiven Erwartung, dass Do- und Ignore-Regeln gleichrangig zusammenwirken. In der Praxis bedeutet das: Wer versehentlich sowohl eine Do-Regel für shop_db als auch eine Ignore-Regel für eine einzelne Tabelle innerhalb dieser Datenbank setzt, muss genau verstehen, dass die Do-Regel Vorrang hat und die Ignore-Regel in diesem Fall wirkungslos bleibt, sofern sie nicht ebenfalls über eine passende Do-Regel abgedeckt ist.

5. Besonderheiten row-basierter Filter

Bei row-basierter Replikation, dem Standard-Binlog-Format seit MySQL 5.7 in den meisten produktiven Umgebungen, werden Events nicht anhand des SQL-Texts gefiltert, sondern anhand der Zieltabelle, die in jedem Row-Event explizit kodiert ist. Das macht die Filterung deutlich robuster gegenüber Cross-Database-Statements, weil die tatsächlich betroffene Tabelle unabhängig vom aufrufenden SQL-Kontext bekannt ist, im Gegensatz zur statement-basierten Auswertung über die aktive USE-Datenbank.

Ein wichtiger Unterschied bleibt dennoch bestehen: replicate-do-db und replicate-ignore-db werten bei row-basierten Events weiterhin die Datenbank aus, in der die Zieltabelle liegt, nicht die zum Zeitpunkt der Ausführung aktive Session-Datenbank. Für Umgebungen mit Row-Format ist dieses Verhalten in der Praxis intuitiver und vorhersehbarer als das statement-basierte Pendant, weshalb sich Row-Format auch aus Filterungssicht als robusteste Wahl empfiehlt.

6. CHANGE REPLICATION FILTER als moderne, dynamische Alternative

Neben der statischen Konfiguration über die Server-Konfigurationsdatei bietet CHANGE REPLICATION FILTER die Möglichkeit, Filterregeln zur Laufzeit zu setzen, ohne den Server neu zu starten. Der Replikations-Thread muss dafür angehalten werden, ein vollständiger Neustart des mysqld-Prozesses ist aber nicht nötig, was besonders in Umgebungen mit hohen Verfügbarkeitsanforderungen einen deutlichen operativen Vorteil bringt.

Diese dynamische Variante eignet sich gut für temporäre Anpassungen, etwa um während einer Migration kurzfristig eine zusätzliche Tabelle vom Filter auszunehmen. Für dauerhafte Filterregeln bleibt die statische Konfigurationsdatei die robustere Wahl, da CHANGE REPLICATION FILTER bei einem Neustart des Servers ohne PERSIST-Option wieder auf die in der Konfigurationsdatei hinterlegten Werte zurückfällt.

STOP REPLICA;
CHANGE REPLICATION FILTER
  REPLICATE_WILD_IGNORE_TABLE = ('shop_db.customer_entity%', 'shop_db.sales_order_payment%');
START REPLICA;

SHOW REPLICA STATUS\G

7. Fallstricke bei nachträglicher Filteränderung

Der größte praktische Fallstrick entsteht, wenn ein Filter geändert wird, nachdem der Replica bereits über einen längeren Zeitraum mit dem alten Filter gelaufen ist. Wird beispielsweise eine bislang ausgeschlossene Tabelle nachträglich in die Replikation aufgenommen, enthält der Replica für diese Tabelle keine historischen Daten, sondern nur die Änderungen ab dem Zeitpunkt der Filteränderung, was zu einem inkonsistenten, teilweise leeren Datenbestand führt, der auf den ersten Blick unauffällig wirkt.

Die einzige zuverlässige Lösung in diesem Fall ist eine vollständige Neusynchronisation des Replicas für die betroffene Tabelle, üblicherweise über einen gezielten Datenexport aus dem Source oder einen kompletten Rebuild des Replicas aus einem aktuellen Backup. Bei GTID-basierter Replikation kommt erschwerend hinzu, dass gtid_purged und der bereits bekannte GTID-Set des Replicas nicht automatisch zur neuen Filterkonfiguration passen, sodass eine saubere Neusynchronisation meist der einzige gangbare Weg bleibt, statt zu versuchen, die Lücke inkrementell zu schließen.

8. Anwendungsfall Multi-Store: getrennte Datenbanken pro Mandant

In Multi-Store-Architekturen mit einer eigenen Datenbank pro Mandant lassen sich Replikationsfilter nutzen, um dedizierte Replicas aufzubauen, die ausschließlich die Daten eines einzelnen Mandanten enthalten, etwa für einen mandantenspezifischen Support-Zugang oder eine isolierte Testumgebung mit produktionsnahen, aber datenschutzkonform eingeschränkten Daten. Über replicate-do-db beschränkt auf die jeweilige Mandanten-Datenbank lässt sich dieses Szenario ohne zusätzliche Infrastruktur wie separate ETL-Pipelines umsetzen.

Wichtig ist dabei, dass gemeinsame, mandantenübergreifende Referenzdaten, sofern vorhanden, entweder ebenfalls in die Filterregel aufgenommen oder bewusst als bekannte Einschränkung dokumentiert werden, da ein zu eng gefasster Datenbank-Filter sonst Funktionalität bricht, die auf diese gemeinsamen Daten angewiesen ist, ohne dass der Fehler auf den ersten Blick mit der Replikationsfilterung in Verbindung gebracht wird.

9. Anwendungsfall Reporting-Replica: sensible Tabellen gezielt ausschließen

Für ein Reporting-Replica, das Business-Intelligence-Werkzeugen oder Data-Warehouse-Ladeprozessen zur Verfügung steht, ist der DSGVO-Aspekt der zentrale Treiber für Replikationsfilter: Tabellen mit direkten Personenbezug wie Kundenadressen, Zahlungstoken oder Kontaktverläufe sollten dort erst gar nicht physisch vorliegen, statt nachträglich über Zugriffsrechte abgesichert zu werden. Ein konsequent gefilterter Replica reduziert damit die Angriffsfläche und die Reichweite eines möglichen Datenlecks strukturell, unabhängig von der Sorgfalt der Zugriffskontrolle am Zielsystem.

In der Praxis empfiehlt sich, die Filterliste sensibler Tabellen zentral zu dokumentieren und bei jeder neuen Magento-Modulinstallation aktiv zu prüfen, ob neue, potenziell sensible Tabellen hinzugekommen sind, die in die bestehende Filterkonfiguration aufgenommen werden müssen. Diese Pflege ist ein wiederkehrender, aber notwendiger Aufwand, der ohne festen Prozess leicht in Vergessenheit gerät, bis eine neue Tabelle unbemerkt auf dem Reporting-Replica landet.

10. Zusammenfassung

11. FAQ: Replikationsfilter: Das Wichtigste auf einen Blick