Warum funktionieren die Quellfilterbedingungen bei meiner AWS-DMS-Aufgabe nicht mehr?

Behebung

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

Die meisten AWS-DMS-Quellen unterstützen die Quellfilterung. MongoDB oder Amazon DocumentDB mit MongoDB-Kompatibilität unterstützen die Quellfilterfunktion jedoch nicht. Weitere Informationen finden Sie unter Quellen für die Datenmigration.

Die folgenden Einschränkungen können sich auf die Quellfilterung auswirken:

• Filter berechnen keine Spalten von Sprachen mit Schreibrichtung von rechts nach links.
• Sie können keine Filter auf LOB-Spalten (Large Object) anwenden.
• Sie können Filter nur auf feste Spalten anwenden, die Sie nach ihrer Erstellung nicht mehr aktualisieren können. Wenn Sie Quellfilter auf feste Spalten anwenden, die Sie nach ihrer Erstellung aktualisieren können, funktionieren die Quellfilter möglicherweise nicht.

Fehler bei Filtern beheben, die bei Volllast nicht funktionieren

Ermitteln Sie die Phase, in der die Quellfilterung nicht funktioniert.

Wenn die Quellfilterung bei Volllast nicht funktioniert, gehen Sie wie folgt vor:

• Stellen Sie sicher, dass die Berücksichtigung der Groß- und Kleinschreibung in den Zuordnungsregeln mit der Quell-Engine übereinstimmt.
• Verwenden Sie beim Filtern von Datumsdatentypen die Formate, die AWS DMS benötigt.
• Führen Sie die Debug-Protokollebene auf SOURCE_UNLOAD aus, um das Problem zu reproduzieren. Erfassen Sie dann die Abfrage, die AWS DMS auf der Quelle ausführt, um die Daten zu entladen.

Beispiel für ein Filterproblem in einer Oracle-Quelltabelle:

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

Erstellen Sie eine AWS-DMS-Aufgabe mit Zuordnungsregeln, die Sie so konfigurieren, dass nur Zeilen repliziert werden, deren ENTRY_DATE größer oder gleich 01/01/2022 ist.

Beispielaufgabe:

{    
 "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"  
            }  
          ]  
        }  
      ]  
    }  
  ]  
}

Um sicherzustellen, dass keine Datensätze repliziert werden und die Fehler in den Aufgabenprotokollen erscheinen, führen Sie die folgende Abfrage aus:

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.

Beispielabfrage:

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 folgenden Protokollausgabe führt AWS DMS die Abfrage in der Quelldatenbank aus:

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

AWS DMS erkennt das Datum in den Zuordnungsregeln nicht. Das Datum entspricht also nicht dem Datumsformat, das AWS DMS erwartet.

Führen Sie die folgende Abfrage aus, um die Zuordnungsregeln so zu ändern, dass sie dem erwarteten Datumsformat entsprechen:

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

Problembehandlung bei Filtern, die während der Change Data Capture (CDC) nicht funktionieren

Wenn Sie feste Spalten filtern, treten die Filterprobleme nur während der CDC-Phase auf. Die Probleme treten möglicherweise nur bei bestimmten Data Manipulation Language (DML)-Anweisungen auf, z. B. UPDATES oder DELETES. Stellen Sie sicher, dass Sie die ausreichende Protokollierung für die Quelltabelle aktivieren.

Um zusätzliche Protokollierung zuzuweisen, verwenden Sie entweder einen Oracle, PostgreSQL oder Microsoft SQL Server.

Oracle

Oracle verwendet zusätzliche Protokollierung, um zusätzliche Protokolle zu Tabellenspalten hinzuzufügen. Wenn die Spalte, die Sie filtern, keine Primärschlüsselspalte ist, aktivieren Sie die zusätzliche Protokollierung für die Spalte und Primärschlüsselspalten.

Das folgende Beispiel repliziert eine Tabelle mit dem Namen TEST.LOGGING, die eine Primärschlüssel-ID und einen Filter für die Spalte NAME hat. Führen Sie den folgenden Befehl 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 bereits zusätzliche Protokollierung für alle Spalten in der Tabelle hinzugefügt wurde, fügen Sie keine weitere Protokollierung hinzu.

Beispiel mit bereits hinzugefügter zusätzlicher Protokollierung:

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

PostgreSQL

PostgreSQL verwendet die Eigenschaft REPLICA IDENTITY, um die Protokollierungsebene für eine Tabelle zu konfigurieren. Wenn Sie REPLICA IDENTITY auf DEFAULT setzen, zeichnet PostgreSQL die alten Werte der Spalten des Primärschlüssels in Write-Ahead-Logs (WAL) auf. Wenn Sie jedoch eine Spalte verwenden, die keine Primärschlüsselspalte ist, reicht die Standardprotokollierungsebene für Löschungen möglicherweise nicht aus.

Stellen Sie sicher, dass die AWS-DMS-Aufgabe das Plugin verwendet, das auf eine der folgenden Eigenschaften eingestellt ist:

Wenn Sie test_decoding verwenden, setzen Sie REPLICA IDENTITY auf FULL:

ALTER TABLE tablename REPLICA IDENTITY FULL;

Hinweis: Wenn Sie REPLICA IDENTITY nicht auf FULL setzen, sendet AWS DMS möglicherweise alle Löschungen an die Zieltabelle.

Wenn Sie pglogical verwenden, setzen Sie REPLICA IDENTITY auf FULL, nachdem Sie die Tabelle zum Replikationssatz hinzugefügt haben:

ALTER TABLE tablename REPLICA IDENTITY FULL;

Hinweis: Wenn Sie REPLICA IDENTITY auf FULL setzen, enthält pglogical eine Einschränkung, sodass Sie einem Replikationssatz keine Tabelle hinzufügen können. Sie erhöhen auch die Anzahl der WAL-Protokolle, die in der Quelldatenbank generiert werden. Wenn die Anzahl der WAL-Protokolle zunimmt, werden alle Spalten bei WAL protokolliert.

Microsoft SQL Server

Stellen Sie sicher, dass Sie alle folgenden AWS-DMS-CDC-Protokollierungsanforderungen erfüllen, um MS-CDC zu aktivieren.

Führen Sie für jede Tabelle, die einen Primärschlüssel hat, die folgende Abfrage aus:

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

Hinweis: Die vorhergehende Abfrage ist für cloudbasierte Quellen erforderlich.

Führen Sie für jede Tabelle, die eindeutige Schlüssel, aber keinen Primärschlüssel hat, die folgende Abfrage aus:

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

Hinweis: Die vorhergehende Abfrage ist sowohl für lokale als auch für cloudbasierte Quellen erforderlich. Wenn Sie MS-Replication für lokale Quellen verwenden, müssen Sie die vorherige Abfrage nicht ausführen.

Führen Sie für jede Tabelle, die keine Primär- oder eindeutigen Schlüssel hat, die folgende Abfrage aus:

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

Hinweis: Für die vorhergehende Abfrage sind sowohl lokale als auch cloudbasierte Quellen erforderlich.

MySQL

In MySQL steuert die Systemvariable binlog_row_image die Zeilen-Images in Binlogs. Weitere Informationen finden Sie unter binlog_row_image auf der MySQL Website. AWS DMS erfordert, dass Sie binlog_row_image auf FULL und binlog_format auf ROW setzen.

MySQL protokolliert alle Spalten sowohl im Vorher-Image als auch im Nachher-Image. Um die maximale Protokollierungsebene in den Binlogs zu bestätigen, müssen Sie binlog_row_image FULL für die Quelldatenbank festlegen.

Ähnliche Informationen

Wie verwende ich Quellfilter in meinen AWS-DMS-Aufgaben?

Tabellenzuordnungen zur Angabe von Aufgabeneinstellungen verwenden

Quellfilter verwenden