Warum funktionieren die Quellfilterbedingungen in meiner AWS DMS-Aufgabe nicht?

Kurzbeschreibung

Es gibt mehrere Gründe, warum Quellfilterbedingungen bei einer AWS DMS-Aufgabe möglicherweise nicht wie erwartet funktionieren. Beispielsweise unterstützt die Engine, die Sie verwenden, möglicherweise nicht die Verwendung von Quellfilterbedingungen. Oder Sie sind möglicherweise von einer oder mehreren Einschränkungen der Funktion betroffen.

Auflösung

Überprüfen Sie, ob Ihre Engine die Quellfilterfunktion unterstützt

Obwohl die meisten AWS DMS-Quellen Quellfilter unterstützen, unterstützen einige Quellen wie MongoDB oder Amazon DocumentDB diese Funktion nicht. Überprüfen Sie in der AWS DMS-Dokumentation zu Quellen für die Datenmigration, ob es Einschränkungen für die von Ihnen verwendete Quell-Engine gibt.

Überprüfen Sie die Einschränkungen der AWS DMS-Quellfilterung

Bei der Quellfilterung gibt es mehrere Einschränkungen. Überprüfen Sie die Einschränkungen, um zu überprüfen, ob Sie die Funktion ordnungsgemäß verwenden:

• Filter berechnen keine Spalten von Rechts-nach-Links-Sprachen.
• Filter können nicht auf große Objektspalten (LOB) angewendet werden.
• Filter können nur auf unveränderliche Spalten angewendet werden, die nach dem Erstellen nicht aktualisiert werden. Wenn Sie Quellfilter auf veränderbare Spalten anwenden, die nach der Erstellung aktualisiert werden können, funktionieren die Quellfilter möglicherweise nicht wie vorgesehen.

Problembehandlung bei Filtern, die bei voller Auslastung nicht mehr funktionieren

Wenn Ihr Problem weiterhin besteht, überprüfen Sie, in welcher Phase die Quellfilterung nicht mehr funktioniert.

Wenn die Filterung während der vollen Auslastung nicht funktioniert, gehen Sie wie folgt vor:

1.    Stellen Sie sicher, dass die Groß- und Kleinschreibung in den Zuordnungsregeln mit der Quell-Engine übereinstimmen. Beispielsweise werden Objektnamen in Oracle und DB2 standardmäßig in Großbuchstaben geschrieben. In ähnlicher Weise werden Objektnamen in PostgreSQL in Kleinbuchstaben geschrieben. Stellen Sie sicher, dass die Spalte, die Sie in Ihrer Filterbedingung verwenden, der von Ihrer Quell-Engine geforderten Groß-/Kleinschreibung entspricht.

2.    Wenn Sie mit Datums-Datentypen filtern, überprüfen Sie, ob Sie die für AWS DMS erforderlichen Formate verwenden. Beispielsweise verwendet AWS DMS das Datumsformat JJJJ-MM-TT und das Zeitformat JJJJ-MM-TT HH:MM:SS zum Filtern.

3.    Reproduzieren Sie das Problem mit der Debut-Protokollierungsebene auf SOURCE_UNLOAD. Erfassen Sie dann die Abfrage, die AWS DMS auf der Quelle ausführt, um die Daten zu entladen. Dies ist ein Beispiel für ein Filterproblem in einer Oracle-Quelltabelle.

Einzelheiten zur Tabelle:

CREATE TABLE DMS.FILTERS
( ID NUMBER(10) NOT NULL,
  ENTRY_DATE DATE,
  CONSTRAINT FILTERS_PK PRIMARY KEY (ID)
);

SQL> SELECT * FROM FILTERS;
  ID       ENTRY_DATE
---------- ---------
         1 01-JAN-22
         2 01-JUN-22
         3 01-JAN-21
         4 01-JUN-21
         5 01-JAN-20
         6 01-JUN-20

Eine AWS DMS-Aufgabe wird mit den Zuordnungsregeln erstellt, um nur Zeilen zu replizieren, bei denen ENTRY_DATE größer oder gleich 01/01/2022 ist:

{
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "893662253",
      "rule-name": "893662253",
      "object-locator": {
        "schema-name": "DMS",
        "table-name": "FILTERS"
      },
      "rule-action": "include",
      "filters": [
        {
          "filter-type": "source",
          "column-name": "ENTRY_DATE",
          "filter-conditions": [
            {
              "filter-operator": "gte",
              "value": "01/01/2022"
            }
          ]
        }
      ]
    }
  ]
}

Es werden also keine Datensätze repliziert, und die Aufgabenprotokolle zeigen folgende Fehler an:

01786264: 2022-06-22T10:36:53 [SOURCE_UNLOAD   ]E:  ORA-01843: not a valid month  [1020417]  (oracle_endpoint_unload.c:171)

Da Debug-Protokolle für SOURCE_UNLOAD aktiviert sind, zeigen die Aufgabenprotokolle genau die Abfrage an, die AWS DMS in der Quelldatenbank ausführt:

1786264: 2022-06-22T10:36:53 [SOURCE_UNLOAD   ]D:  Select statement for UNLOAD is 'SELECT "ID","ENTRY_DATE"  FROM "DMS"."FILTERS" WHERE ((("ENTRY_DATE" >= TO_DATE('0000-00-00','YYYY-MM-DD'))))'  (oracle_endpoint_utils.c:1979)

In der Protokollausgabe können Sie sehen, dass AWS DMS diese Abfrage in der Quelldatenbank ausführt:

SELECT "ID","ENTRY_DATE"  FROM "DMS"."FILTERS" WHERE ((("ENTRY_DATE" >= TO_DATE('0000-00-00','YYYY-MM-DD'))));

AWS DMS erkennt das in den Zuordnungsregeln angegebene Datum nicht, da es nicht mit dem von AWS DMS erwarteten Datumsformat übereinstimmt. Ändern Sie also die Zuordnungsregeln so, dass sie dem erwarteten Datumsformat entsprechen:

{
                            "filter-operator": "gte",
                            "value": "2022-01-01"
                        }

Fehlersuche bei Filtern, die während der CDC nicht mehr funktionieren

Hinweis: Wenden Sie Filter nur auf unveränderliche Spalten an, die nach der Erstellung nicht aktualisiert werden. Das Hinzufügen von Filtern zu veränderbaren Spalten kann zu unerwarteten Ergebnissen führen.

Wenn es sich bei den Spalten, die Sie beim Filtern verwenden, um unveränderliche Spalten handelt, stellen Sie möglicherweise fest, dass Filterprobleme nur während der CDC-Phase auftreten. Außerdem können diese Probleme nur bei bestimmten DML-Anweisungen wie UPDATES oder DELETES auftreten. Stellen Sie in diesem Szenario sicher, dass Sie eine ausreichende Protokollierung für die Quelltabelle aktiviert haben. Führen Sie die folgenden Schritte aus, um je nach verwendetem Modul zusätzliche Protokollierung zuzuweisen:

Oracle

Oracle verwendet zusätzliche Protokollierung, um zusätzliche Protokolle zu Tabellenspalten hinzuzufügen. Wenn es sich bei der zu filternden Spalte nicht um eine Primärschlüsselspalte handelt, stellen Sie sicher, dass die zusätzliche Protokollierung für diese Spalte und Primärschlüsselspalten aktiviert ist.

In diesem Beispiel wird eine Tabelle namens TEST.LOGGING mit einer Primärschlüssel-ID und einem Filter für die Spalte NAME repliziert. Führen Sie einen Befehl ähnlich dem folgenden aus, um die zusätzliche Protokollierung der Protokollgruppe zu erstellen:

ALTER TABLE TEST.LOGGING ADD SUPPLEMENTAL LOG GROUP TEST_LOG_GROUP (ID, NAME) ALWAYS;

Wenn für alle Spalten in einer Tabelle bereits eine zusätzliche Protokollierung hinzugefügt wurde, wie in diesem Beispiel, müssen Sie keine weitere Protokollierung hinzufügen.

ALTER TABLE TableName ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

PostgreSQL

PostgreSQL verwendet die REPLICA IDENTITY-Eigenschaft, um die Protokollierungsebene für eine Tabelle zu konfigurieren. Wenn REPLICA IDENTITY auf Standard gesetzt ist, zeichnet PostgreSQL die alten Werte der Spalten des Primärschlüssels in WAL-Protokollen auf. Die standardmäßige Protokollierungsebene reicht jedoch möglicherweise nicht für DELETES aus, wenn Sie beim Filtern eine Nicht-Primärschlüsselspalte verwenden. Führen Sie in diesem Szenario je nach dem von der AWS DMS-Aufgabe verwendeten Plugin die folgenden Schritte aus: Wenn test_decoding verwendet wird:

Setzen Sie REPLICA IDENTITY in der Tabelle auf „voll“. Wenn Sie diesen Schritt nicht ausführen, sendet AWS DMS möglicherweise alle Löschungen an die Zieltabelle:

ALTER TABLE tablename REPLICA IDENTITY FULL;

Wenn pglogical verwendet wird:

Setzen Sie REPLICA IDENTITY auf „voll“, nachdem die Tabelle zur Replikationsgruppe hinzugefügt wurde. Dies liegt daran, dass pglogical eine Einschränkung hat, die verhindert, dass die Tabelle zu einer Replikationsgruppe hinzugefügt wird, wenn REPLICA IDENTITY voll ist.

ALTER TABLE tablename REPLICA IDENTITY FULL;

Hinweis: Wenn REPLICA IDENTITY für eine Tabelle auf „voll“ gesetzt wird, wird die Anzahl der WAL-Protokolle erhöht, die in der Quelldatenbank generiert werden. Dies geschieht, weil dann alle Spalten in WAL angemeldet werden.

SQL Server

Wenn Sie SQL Server verwenden, überprüfen Sie, ob alle Voraussetzungen für AWS DMS CDC erfüllt sind, insbesondere die folgenden Protokollierungsanforderungen:

• Führen Sie für jede Tabelle mit einem Primärschlüssel die folgende Abfrage aus, um MS-CDC zu aktivieren: Hinweis: Wenn MS-Replikation bereits für lokale Quellen verwendet wird, überspringen Sie diesen Schritt. Dieser Schritt ist für Cloud-basierte Quellen erforderlich.

exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL,
@supports_net_changes = 1
GO

• Führen Sie diese Abfrage aus, um MS-CDC für jede Tabelle mit eindeutigen Schlüsseln, aber ohne Primärschlüssel zu aktivieren. Hinweis: Dieser Schritt ist sowohl für lokale als auch für Cloud-basierte Quellen erforderlich.

exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@index_name = N'unique_index_name',
@role_name = NULL,
@supports_net_changes = 1
GO

• Führen Sie diese Abfrage aus, um MS-CDC für jede Tabelle ohne primäre oder eindeutige Schlüssel zu aktivieren/ Hinweis: Dieser Schritt ist sowohl für lokale als auch für Cloud-basierte Quellen erforderlich.

exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO

MySQL

In MySQL werden Zeilenbilder in Bin-Protokollen von der Systemvariablen binlog_row_image gesteuert. AWS DMS erfordert, dass binlog_row_image auf voll und binlog_format auf ROW gesetzt ist. Das bedeutet, dass MySQL alle Spalten sowohl im Vorher- als auch im Nachher-Bild protokolliert. Stellen Sie daher sicher, dass binlog_row_image in der Quelldatenbank auf voll gesetzt ist, um die maximale Protokollierungsstufe in den Bin-Protokollen zu bestätigen.

---

Relevante Informationen

Wie benutze ich Quellfilter in meinen AWS DMS-Aufgaben?

Verwenden der Tabellenzuordnung zur Angabe von Aufgabeneinstellungen

Quellfilter verwenden