}
```
Im folgenden Beispiel werden die für den Bedingungsausdruck verwendeten Abschnitte hervorgehoben.
![\[Fangen Sie an mit AWS DMS\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-Tasks-conditional1.png)
### Verwenden der Attributzuweisung mit Objektzuweisung
Mit Attributzuweisungen können Sie eine Vorlagenzeichenfolge festlegen, indem Sie anhand von Quellspaltennamen Daten auf dem Ziel umstrukturieren. Es wird keine Formatierung vorgenommen, außer den Angaben, die der Benutzer für die Vorlage festlegt.
Das folgende Beispiel zeigt die Struktur der Quelldatenbank und die gewünschte Struktur des DynamoDB-Ziels. Zuerst wird die Struktur der Quelle dargestellt, in diesem Fall eine Oracle-Datenbank, und dann die gewünschte Struktur der Daten in DynamoDB. Am Ende des Beispiels ist das JSON-Format dargestellt, mit dem die gewünschte Zielstruktur erstellt wird.
Die Struktur der Oracle-Daten ist im Folgenden angegeben:
****
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateOfBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Primärschlüssel | – | |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Die Struktur der DynamoDB-Daten ist im Folgenden angegeben:
****
| CustomerName | StoreId | ContactDetails | DateOfBirth |
| --- | --- | --- | --- |
| Partitionsschlüssel | Sortierschlüssel | – |
| Randy,Marsh
| 5
| {
"Name": "Randy",
"Home": {
"Address": "221B Baker Street",
"Phone": 1234567890
},
"Work": {
"Address": "31 Spooner Street, Quahog",
"Phone": 9876541230
}
} | 02/29/1988
|
Im folgenden JSON-Beispiel sind die Objekt- und Spaltenzuordnungen dargestellt, mit denen die DynamoDB-Struktur erzielt wird:
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToDDB",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "test",
"table-name": "customer"
},
"target-table-name": "customer_t",
"mapping-parameters": {
"partition-key-name": "CustomerName",
"sort-key-name": "StoreId",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${FirstName},${LastName}"
},
{
"target-attribute-name": "StoreId",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${StoreId}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "{\"Name\":\"${FirstName}\",\"Home\":{\"Address\":\"${HomeAddress}\",\"Phone\":\"${HomePhone}\"}, \"Work\":{\"Address\":\"${WorkAddress}\",\"Phone\":\"${WorkPhone}\"}}"
}
]
}
}
]
}
```
Alternativ kann bei der Spaltenzuordnung das DynamoDB-Format als Dokumenttyp verwendet werden. Im folgenden Codebeispiel wird *dynamodb-map* als `attribute-sub-type` für die Attributzuweisung verwendet.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToDDB",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "test",
"table-name": "customer"
},
"target-table-name": "customer_t",
"mapping-parameters": {
"partition-key-name": "CustomerName",
"sort-key-name": "StoreId",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${FirstName},${LastName}"
},
{
"target-attribute-name": "StoreId",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${StoreId}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "document",
"attribute-sub-type": "dynamodb-map",
"value": {
"M": {
"Name": {
"S": "${FirstName}"
},
"Home": {
"M": {
"Address": {
"S": "${HomeAddress}"
},
"Phone": {
"S": "${HomePhone}"
}
}
},
"Work": {
"M": {
"Address": {
"S": "${WorkAddress}"
},
"Phone": {
"S": "${WorkPhone}"
}
}
}
}
}
}
]
}
}
]
}
```
Als Alternative zu `dynamodb-map` können Sie das Attribut `dynamodb-list` as attribute-sub-type for verwenden, wie im folgenden Beispiel gezeigt.
```
{
"target-attribute-name": "ContactDetailsList",
"attribute-type": "document",
"attribute-sub-type": "dynamodb-list",
"value": {
"L": [
{
"N": "${FirstName}"
},
{
"N": "${HomeAddress}"
},
{
"N": "${HomePhone}"
},
{
"N": "${WorkAddress}"
},
{
"N": "${WorkPhone}"
}
]
}
}
```
### Beispiel 1: Verwenden der Attributzuweisung mit Objektzuweisung
Im folgenden Beispiel werden Daten aus zwei MySQL-Datenbanktabellen, *nfl\$1data und *sport\$1team**, in zwei DynamoDB-Tabellen mit dem Namen und migriert. *NFLTeams*SportTeams** Unten stehend ist die Tabellenstruktur und das JSON-Format angegeben, das zum Zuweisen der Daten aus den MySQL-Datenbanktabellen zu den DynamoDB-Tabellen verwendet wird.
Die Struktur der MySQL-Datenbanktabelle *nfl\$1data* ist im Folgenden dargestellt:
```
mysql> desc nfl_data;
+---------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+-------------+------+-----+---------+-------+
| Position | varchar(5) | YES | | NULL | |
| player_number | smallint(6) | YES | | NULL | |
| Name | varchar(40) | YES | | NULL | |
| status | varchar(10) | YES | | NULL | |
| stat1 | varchar(10) | YES | | NULL | |
| stat1_val | varchar(10) | YES | | NULL | |
| stat2 | varchar(10) | YES | | NULL | |
| stat2_val | varchar(10) | YES | | NULL | |
| stat3 | varchar(10) | YES | | NULL | |
| stat3_val | varchar(10) | YES | | NULL | |
| stat4 | varchar(10) | YES | | NULL | |
| stat4_val | varchar(10) | YES | | NULL | |
| team | varchar(10) | YES | | NULL | |
+---------------+-------------+------+-----+---------+-------+
```
Die Struktur der MySQL-Datenbanktabelle *sport\$1team* ist im Folgenden dargestellt:
```
mysql> desc sport_team;
+---------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------+--------------+------+-----+---------+----------------+
| id | mediumint(9) | NO | PRI | NULL | auto_increment |
| name | varchar(30) | NO | | NULL | |
| abbreviated_name | varchar(10) | YES | | NULL | |
| home_field_id | smallint(6) | YES | MUL | NULL | |
| sport_type_name | varchar(15) | NO | MUL | NULL | |
| sport_league_short_name | varchar(10) | NO | | NULL | |
| sport_division_short_name | varchar(10) | YES | | NULL | |
```
Im Folgenden sind die Tabellenzuordnungsregeln für die Zuordnung der zwei Tabellen zu den zwei DynamoDB-Tabellen aufgeführt:
```
{
"rules":[
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "dms_sample",
"table-name": "nfl_data"
},
"rule-action": "include"
},
{
"rule-type": "selection",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "dms_sample",
"table-name": "sport_team"
},
"rule-action": "include"
},
{
"rule-type":"object-mapping",
"rule-id":"3",
"rule-name":"MapNFLData",
"rule-action":"map-record-to-record",
"object-locator":{
"schema-name":"dms_sample",
"table-name":"nfl_data"
},
"target-table-name":"NFLTeams",
"mapping-parameters":{
"partition-key-name":"Team",
"sort-key-name":"PlayerName",
"exclude-columns": [
"player_number", "team", "name"
],
"attribute-mappings":[
{
"target-attribute-name":"Team",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${team}"
},
{
"target-attribute-name":"PlayerName",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${name}"
},
{
"target-attribute-name":"PlayerInfo",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"{\"Number\": \"${player_number}\",\"Position\": \"${Position}\",\"Status\": \"${status}\",\"Stats\": {\"Stat1\": \"${stat1}:${stat1_val}\",\"Stat2\": \"${stat2}:${stat2_val}\",\"Stat3\": \"${stat3}:${
stat3_val}\",\"Stat4\": \"${stat4}:${stat4_val}\"}"
}
]
}
},
{
"rule-type":"object-mapping",
"rule-id":"4",
"rule-name":"MapSportTeam",
"rule-action":"map-record-to-record",
"object-locator":{
"schema-name":"dms_sample",
"table-name":"sport_team"
},
"target-table-name":"SportTeams",
"mapping-parameters":{
"partition-key-name":"TeamName",
"exclude-columns": [
"name", "id"
],
"attribute-mappings":[
{
"target-attribute-name":"TeamName",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${name}"
},
{
"target-attribute-name":"TeamInfo",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"{\"League\": \"${sport_league_short_name}\",\"Division\": \"${sport_division_short_name}\"}"
}
]
}
}
]
}
```
Die Beispielausgabe für die *NFLTeams*DynamoDB-Tabelle ist unten dargestellt:
```
"PlayerInfo": "{\"Number\": \"6\",\"Position\": \"P\",\"Status\": \"ACT\",\"Stats\": {\"Stat1\": \"PUNTS:73\",\"Stat2\": \"AVG:46\",\"Stat3\": \"LNG:67\",\"Stat4\": \"IN 20:31\"}",
"PlayerName": "Allen, Ryan",
"Position": "P",
"stat1": "PUNTS",
"stat1_val": "73",
"stat2": "AVG",
"stat2_val": "46",
"stat3": "LNG",
"stat3_val": "67",
"stat4": "IN 20",
"stat4_val": "31",
"status": "ACT",
"Team": "NE"
}
```
Die Beispielausgabe für die SportsTeams *DynamoDB-Tabelle* ist unten dargestellt:
```
{
"abbreviated_name": "IND",
"home_field_id": 53,
"sport_division_short_name": "AFC South",
"sport_league_short_name": "NFL",
"sport_type_name": "football",
"TeamInfo": "{\"League\": \"NFL\",\"Division\": \"AFC South\"}",
"TeamName": "Indianapolis Colts"
}
```
## Zieldatentypen für DynamoDB
Der DynamoDB-Endpunkt für AWS DMS unterstützt die meisten DynamoDB-Datentypen. Die folgende Tabelle zeigt die AWS DMS Amazon-Zieldatentypen, die bei der Verwendung unterstützt werden, AWS DMS und die Standardzuweisung von AWS DMS Datentypen.
Weitere Informationen zu AWS DMS Datentypen finden Sie unter[Datentypen für den AWS Database Migration Service](CHAP_Reference.DataTypes.md).
Bei der AWS DMS Migration von Daten aus heterogenen Datenbanken ordnen wir Datentypen aus der Quelldatenbank Zwischendatentypen zu, die als Datentypen bezeichnet AWS DMS werden. Wir weisen dann die Zwischendatentypen zu den Zieldatentypen zu. Die folgende Tabelle zeigt jeden AWS DMS Datentyp und den Datentyp, dem er in DynamoDB zugeordnet ist:
| AWS DMS Datentyp | DynamoDB-Datentyp |
| --- | --- |
| Zeichenfolge | Zeichenfolge |
| WString | Zeichenfolge |
| Boolesch | Boolesch |
| Datum | Zeichenfolge |
| DateTime | Zeichenfolge |
| INT1 | Zahl |
| INT2 | Zahl |
| INT4 | Zahl |
| INT8 | Zahl |
| Numerischer Wert | Zahl |
| Real4 | Zahl |
| Real8 | Zahl |
| UINT1 | Zahl |
| UINT2 | Zahl |
| UINT4 | Zahl |
| UINT8 | Zahl |
| CLOB | Zeichenfolge |
# Verwendung von Amazon Kinesis Data Streams als Ziel für AWS Database Migration Service
Sie können AWS DMS es verwenden, um Daten in einen Amazon Kinesis Kinesis-Datenstream zu migrieren. Amazon-Kinesis-Datenströme sind Teil des Service Amazon Kinesis Data Streams. Sie können Kinesis-Datenströme zum Erfassen und Verarbeiten großer Ströme von Datensätzen in Echtzeit nutzen.
Ein Kinesis-Datenstrom besteht aus Shards. *Shards* sind eindeutig identifizierbare Sequenzen von Datensätzen in einem Stream. Weitere Informationen zu Shards in Amazon Kinesis Data Streams finden Sie unter [Shard](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html#shard) im *Amazon-Kinesis-Data-Streams-Entwicklerhandbuch*.
AWS Database Migration Service veröffentlicht Datensätze mithilfe von JSON in einem Kinesis-Datenstream. Während der Konvertierung serialisiert AWS DMS jeden Datensatz aus der Quelldatenbank in ein Attributwertpaar im JSON-Format oder in ein JSON\$1UNFORMATTED-Nachrichtenformat. Ein JSON\$1UNFORMATTED-Nachrichtenformat ist eine einzeilige JSON-Zeichenfolge mit neuem Zeilenbegrenzer. Es ermöglicht Amazon Data Firehose, Kinesis-Daten an ein Amazon S3 S3-Ziel zu senden und sie dann mit verschiedenen Abfrage-Engines, einschließlich Amazon Athena, abzufragen.
Sie verwenden die Objektzuweisung zum Migrieren Ihrer Daten von einer unterstützten Datenquelle zu einem Ziel-Stream. Mit der Objektzuweisung bestimmen Sie, wie die Datensätze im Stream zu strukturieren sind. Außerdem definieren Sie einen Partitionsschlüssel für jede Tabelle, die Kinesis Data Streams zum Gruppieren der Daten in Shards verwendet.
AWS DMS legt auch mehrere Kinesis Data Streams Streams-Parameterwerte fest. Die Kosten für die Erstellung der Tabelle sind abhängig von der Datenmenge und der Anzahl der zu migrierenden Tabellen.
**Anmerkung**
Die Option **SSL-Modus** auf der AWS DMS Konsole oder API gilt nicht für einige Datenstreaming- und NoSQL-Dienste wie Kinesis und DynamoDB. **Sie sind standardmäßig sicher, sodass AWS DMS angezeigt wird, dass die Einstellung für den SSL-Modus auf „Keine“ gesetzt ist (SSL-Modus=Keine).** Sie müssen keine zusätzliche Konfiguration für Ihren Endpunkt angeben, um SSL verwenden zu können. Wenn Sie beispielsweise Kinesis als Zielendpunkt verwenden, ist dies standardmäßig sicher. Alle API-Aufrufe an Kinesis verwenden SSL, sodass keine zusätzliche SSL-Option am AWS DMS Endpunkt erforderlich ist. Mithilfe des HTTPS-Protokolls, das AWS DMS standardmäßig verwendet, wenn eine Verbindung zu einem Kinesis-Datenstrom hergestellt wird, können Sie Daten sicher über SSL-Endpunkte einfügen und abrufen.
**Kinesis-Data-Streams-Endpunkteinstellungen**
Wenn Sie Kinesis Data Streams Streams-Zielendpunkte verwenden, können Sie Transaktions- und Kontrolldetails mithilfe der `KinesisSettings` Option in der AWS DMS API abrufen.
Sie können die Verbindungseinstellungen auf eine der folgenden Weisen festlegen:
+ In der AWS DMS Konsole mithilfe der Endpunkteinstellungen.
+ In der CLI mit der `kinesis-settings` Option des [CreateEndpoint](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateEndpoint.html)Befehls.
Verwenden Sie in der CLI die folgenden Anforderungsparameter der Option `kinesis-settings`:
**Anmerkung**
Unterstützung für die Endpunkteinstellung `IncludeNullAndEmpty` ist in AWS DMS -Version 3.4.1 und höher verfügbar. Unterstützung für die anderen folgenden Endpunkteinstellungen für Kinesis Data Streams Streams-Ziele ist jedoch in AWS DMS verfügbar.
+ `MessageFormat` – Das Ausgabeformat für die Datensätze, die auf dem Endpunkt erstellt wurden. Das Nachrichtenformat ist `JSON` (Standard) oder `JSON_UNFORMATTED` (eine einzelne Zeile ohne Tabulator).
+ `IncludeControlDetails` – Zeigt detaillierte Steuerungsinformationen für Tabellendefinition, Spaltendefinition und Tabellen- und Spaltenänderungen in der Kinesis-Nachrichtenausgabe an. Der Standardwert ist `false`.
+ `IncludeNullAndEmpty` – Schließt NULL-Spalten und leere Spalten in das Ziel ein. Der Standardwert ist `false`.
+ `IncludePartitionValue` – Zeigt den Partitionswert innerhalb der Kinesis-Nachrichtenausgabe an, es sei denn, der Partitionstyp ist `schema-table-type`. Der Standardwert ist `false`.
+ `IncludeTableAlterOperations` – Enthält alle DDL-Operationen (DDL = Data Definition Language), die die Tabelle in den Steuerungsdaten ändern, wie etwa `rename-table`, `drop-table`, `add-column`, `drop-column` und `rename-column`. Der Standardwert ist `false`.
+ `IncludeTransactionDetails` – Stellt detaillierte Transaktionsinformationen aus der Quelldatenbank bereit. Diese Informationen beinhalten einen Durchführungszeitstempel, eine Protokollposition sowie Werte für `transaction_id`, `previous_transaction_id` und `transaction_record_id ` (den Datensatzoffset innerhalb einer Transaktion). Der Standardwert ist `false`.
+ `PartitionIncludeSchemaTable` – Fügt Schema- und Tabellennamen zu Partitionswerten als Präfix hinzu, wenn der Partitionstyp `primary-key-type` ist. Dadurch wird die Datenverteilung zwischen Kinesis-Shards erhöht. Angenommen, ein `SysBench`-Schema hat Tausende von Tabellen und jede davon hat nur einen begrenzten Bereich für einen Primärschlüssel. In diesem Fall wird derselbe Primärschlüssel von Tausenden von Tabellen an denselben Shard gesendet, was zu einer Drosselung führt. Der Standardwert ist `false`.
+ `UseLargeIntegerValue`— Verwenden Sie bis zu 18-stellige Ganzzahlen, anstatt Ganzzahlen in Doppelzahlen umzuwandeln. Diese Option ist ab AWS DMS Version 3.5.4 verfügbar. Der Standardwert lautet „false“.
Das folgende Beispiel zeigt die Option `kinesis-settings` mit einem Beispielbefehl `create-endpoint`, der über die AWS CLI ausgegeben wird.
```
aws dms \
create-endpoint \
--region \
--endpoint-identifier \
--endpoint-type target \
--engine-name kinesis \
--kinesis-settings ServiceAccessRoleArn=arn:aws:iam:::role/,StreamArn=arn:aws:kinesis:::stream/,MessageFormat=json-unformatted,
IncludeControlDetails=true,IncludeTransactionDetails=true,IncludePartitionValue=true,PartitionIncludeSchemaTable=true,
IncludeTableAlterOperations=true
```
**Aufgabeneinstellungen für vollständige Multithread-Ladevorgänge**
AWS DMS Unterstützt eine Multithread-Volllast auf eine Kinesis Data Streams Streams-Ziel-Instance, um die Übertragungsgeschwindigkeit zu erhöhen. DMS unterstützt Multithreading u. a. mithilfe der folgenden Aufgabeneinstellungen:
+ `MaxFullLoadSubTasks` – Geben Sie diese Option an, um die maximale Anzahl von Quelltabellen festzulegen, die parallel geladen werden sollen. DMS lädt jede Tabelle in die entsprechende Kinesis-Zieltabelle mithilfe einer dedizierten Unteraufgabe. Der Standardwert beträgt 8; der Maximalwert beträgt 49.
+ `ParallelLoadThreads`— Verwenden Sie diese Option, um die Anzahl der Threads anzugeben, die AWS DMS verwendet werden, um jede Tabelle in ihre Kinesis-Zieltabelle zu laden. Der Höchstwert für ein Kinesis-Data-Streams-Ziel ist 32. Sie können eine Erhöhung dieses Höchstwerts anfordern.
+ `ParallelLoadBufferSize` – Verwenden Sie diese Option, um die maximale Anzahl der Datensätze anzugeben, die in dem Puffer gespeichert werden sollen, den die parallelen Lade-Threads zum Laden von Daten in das Kinesis-Ziel verwenden. Der Standardwert lautet 50. Die maximale Wert ist 1.000. Verwenden Sie diese Einstellung mit `ParallelLoadThreads`; `ParallelLoadBufferSize` ist nur gültig, wenn es mehr als einen Thread gibt.
+ `ParallelLoadQueuesPerThread` – Verwenden Sie diese Option, um die Anzahl der Warteschlangen anzugeben, auf die jeder gleichzeitige Thread zugreift, um Datensätze aus Warteschlangen zu entfernen und eine Stapellast für das Ziel zu generieren. Der Standardwert ist 1. Für Kinesis-Ziele mit verschiedenen Nutzlastgrößen beträgt der gültige Bereich jedoch 5–512 Warteschlangen pro Thread.
**Aufgabeneinstellungen für Multithreaded CDC-Ladevorgänge**
Sie können die Leistung der Änderungsdatenerfassung (Change Data Capture, CDC) für Echtzeitdaten-Streaming-Zielendpunkte wie Kinesis mithilfe von Aufgabeneinstellungen verbessern, die das Verhalten des API–Aufrufs `PutRecords` ändern. Dazu können Sie die Anzahl der gleichzeitigen Threads, der Warteschlangen pro Thread und die Anzahl der Datensätze angeben, die in einem Puffer unter Verwendung von `ParallelApply*`-Aufgabeneinstellungen gespeichert werden sollen. Beispiel: Sie möchten eine CDC-Last durchführen und 128 Threads parallel anwenden. Außerdem möchten Sie auf 64 Warteschlangen pro Thread zugreifen, wobei 50 Datensätze pro Puffer gespeichert sind.
AWS DMS Unterstützt die folgenden Task-Einstellungen, um die CDC-Leistung zu verbessern:
+ `ParallelApplyThreads`— Gibt die Anzahl der gleichzeitigen Threads an, die während eines CDC-Ladevorgangs AWS DMS verwendet werden, um Datensätze an einen Kinesis-Zielendpunkt zu übertragen. Der Standardwert ist Null (0) und der maximale Wert ist 32.
+ `ParallelApplyBufferSize` – Gibt die maximale Anzahl von Datensätzen an, die in jeder Pufferwarteschlange für gleichzeitige Threads gespeichert werden sollen, um sie während einer CDC-Last an einen Kinesis-Zielendpunkt zu übertragen. Der Standardwert ist 100 und der maximale Wert 1 000. Verwenden Sie diese Option, wenn `ParallelApplyThreads` mehrere Threads angibt.
+ `ParallelApplyQueuesPerThread` – Gibt die Anzahl der Warteschlangen an, auf die jeder Thread zugreift, um Datensätze aus Warteschlangen zu entfernen und während des CDC eine Stapellast für einen Kinesis-Endpunkt zu generieren. Der Standardwert ist 1 und der maximale Wert 512.
Wenn Sie `ParallelApply*`-Aufgabeneinstellungen verwenden, ist der `primary-key` der Tabelle der `partition-key-type`-Standardwert, nicht `schema-name.table-name`.
## Verwenden eines Vorher-Abbilds zum Anzeigen von Originalwerten von CDC-Zeilen für einen Kinesis-Datenstrom als Ziel
Wenn Sie CDC-Aktualisierungen in ein Data-Streaming-Ziel wie Kinesis schreiben, können Sie die ursprünglichen Werte einer Quelldatenbankzeile vor der Änderung durch eine Aktualisierung anzeigen. Um dies zu ermöglichen, AWS DMS füllt es ein *Vorher-Image* der Aktualisierungsereignisse auf der Grundlage von Daten aus, die von der Quelldatenbank-Engine bereitgestellt werden.
Verschiedene Quelldatenbank-Engines liefern unterschiedliche Mengen an Informationen für ein Vorher-Abbild:
+ Oracle stellt für Spalten nur dann Aktualisierungen bereit, wenn sie sich ändern.
+ PostgreSQL stellt nur Daten für Spalten bereit, die Teil des Primärschlüssels sind (geändert oder nicht). Um Daten für alle Spalten (geändert oder nicht) bereitzustellen, müssen Sie `FULL` statt `DEFAULT` für `REPLICA_IDENTITY` festlegen. Beachten Sie, dass Sie die Einstellung `REPLICA_IDENTITY` für jede Tabelle sorgfältig auswählen sollten. Wenn Sie für `REPLICA_IDENTITY` `FULL` festlegen, werden alle Spaltenwerte kontinuierlich in das Write-Ahead Logging (WAL) geschrieben. Dies kann bei Tabellen, die häufig aktualisiert werden, zu Leistungs- oder Ressourcenproblemen führen.
+ MySQL stellt generell Daten für alle Spalten außer für BLOB- und CLOB-Datentypen bereit (geändert oder nicht).
Verwenden Sie entweder die `BeforeImageSettings`-Aufgabeneinstellung oder den `add-before-image-columns`-Parameter, um die Erstellung von Vorher-Abbildern zum Hinzufügen von Originalwerten aus der Quelldatenbank zur AWS DMS -Ausgabe zu aktivieren. Dieser Parameter wendet eine Spalten-Transformationsregel an.
`BeforeImageSettings` fügt jeder Aktualisierungsoperation ein neues JSON-Attribut mit Werten hinzu, die aus dem Quelldatenbanksystem erfasst werden, wie nachfolgend gezeigt.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**Anmerkung**
Gilt nur für `BeforeImageSettings` AWS DMS Aufgaben, die eine CDC-Komponente enthalten, z. B. Volllast- und CDC-Aufgaben (bei denen vorhandene Daten migriert und laufende Änderungen repliziert werden), oder für reine CDC-Aufgaben (bei denen nur Datenänderungen repliziert werden). Wenden Sie `BeforeImageSettings` nicht auf Nur-Volllast-Aufgaben an.
Für `BeforeImageSettings`-Optionen gilt Folgendes:
+ Legen Sie die `EnableBeforeImage`-Option vor dem Imaging auf `true` fest. Der Standardwert ist `false`.
+ Verwenden Sie die `FieldName`-Option, um dem neuen JSON-Attribut einen Namen zuzuweisen. Wann `EnableBeforeImage` `true` ist, ist `FieldName` erforderlich und darf nicht leer sein.
+ Die `ColumnFilter`-Option gibt eine Spalte an, die vor dem Imaging hinzugefügt werden soll. Wenn Sie nur Spalten hinzufügen möchten, die Teil der Primärschlüssel der Tabelle sind, verwenden Sie den Standardwert `pk-only`. Wenn Sie eine Spalte hinzufügen möchten, die einen Vorher-Abbild-Wert hat, verwenden Sie `all`. Beachten Sie, dass das Vorher-Abbild keine Spalten mit LOB-Datentypen wie CLOB oder BLOB enthält.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
**Anmerkung**
Amazon-S3-Ziele unterstützen `BeforeImageSettings` nicht. Verwenden Sie für S3-Ziele nur die `add-before-image-columns`-Transformationsregel, die vor de- Imaging während des CDC-Vorgangs ausgeführt werden soll.
### Verwenden einer Vorher-Abbild-Transformationsregel
Alternativ zu den Aufgabeneinstellungen können Sie den `add-before-image-columns`-Parameter verwenden, der eine Spalten-Transformationsregel anwendet. Mit diesem Parameter können Sie das Vorher-Abbild während des CDC-Vorgangs auf Data-Streaming-Zielen wie Kinesis aktivieren.
Wenn Sie `add-before-image-columns` in einer Transformationsregel verwenden, können Sie eine feinere Steuerung der Ergebnisse für das Vorher-Abbild anwenden. Mit Transformationsregeln können Sie einen Objekt-Locator verwenden, der Ihnen die Kontrolle über die für die Regel ausgewählten Tabellen gibt. Außerdem können Sie Transformationsregeln miteinander verketten, wodurch verschiedene Regeln auf verschiedene Tabellen angewendet werden können. Anschließend können Sie die erzeugten Spalten mithilfe anderer Regeln bearbeiten.
**Anmerkung**
Verwenden Sie den `add-before-image-columns`-Parameter nicht zusammen mit der `BeforeImageSettings`-Aufgabeneinstellung innerhalb derselben Aufgabe. Verwenden Sie stattdessen entweder den Parameter oder die Einstellung, aber nicht beide, für eine einzelne Aufgabe.
Ein `transformation`-Regeltyp mit dem `add-before-image-columns`-Parameter für eine Spalte muss einen `before-image-def`-Abschnitt bereitstellen. Es folgt ein Beispiel.
```
{
"rule-type": "transformation",
…
"rule-target": "column",
"rule-action": "add-before-image-columns",
"before-image-def":{
"column-filter": one-of (pk-only / non-lob / all),
"column-prefix": string,
"column-suffix": string,
}
}
```
Der Wert von `column-prefix` wird einem Spaltennamen vorangestellt, und der Standardwert von `column-prefix` ist `BI_`. Der Wert von `column-suffix` wird an den Spaltennamen angehängt, und der Standardwert ist leer. Setzen Sie nicht `column-prefix` und `column-suffix` auf leere Zeichenfolgen.
Wählen Sie einen Wert für `column-filter`. Wenn Sie nur Spalten hinzufügen möchten, die Teil der Primärschlüssel der Tabelle sind, wählen Sie `pk-only` . Wählen Sie `non-lob`, um nur Spalten hinzuzufügen, die nicht vom LOB-Typ sind. Oder lassen`all` Sie eine Spalte hinzufügen, die einen Vorher-Abbild-Wert hat.
### Beispiel für eine Vorher-Abbild-Transformationsregel
Die Transformationsregel im folgenden Beispiel fügt eine neue Spalte mit dem Namen `BI_emp_no` auf dem Ziel hinzu. Eine Anweisung wie `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` füllt daher das `BI_emp_no` Feld mit 1. Wenn Sie CDC-Aktualisierungen für Amazon-S3-Ziele schreiben, ermöglicht die `BI_emp_no`-Spalte, zu erkennen, welche ursprüngliche Zeile aktualisiert wurde.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "employees"
},
"rule-action": "add-before-image-columns",
"before-image-def": {
"column-prefix": "BI_",
"column-suffix": "",
"column-filter": "pk-only"
}
}
]
}
```
Weitere Informationen zur Verwendung der `add-before-image-columns`-Regelaktion finden Sie unter [Transformationsregeln und Aktionen](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Voraussetzungen für die Verwendung eines Kinesis-Datenstroms als Ziel für AWS Database Migration Service
### IAM-Rolle für die Verwendung eines Kinesis-Datenstroms als Ziel für AWS Database Migration Service
Bevor Sie einen Kinesis-Datenstream als Ziel für einrichten, stellen Sie sicher AWS DMS, dass Sie eine IAM-Rolle erstellen. Diese Rolle muss es ermöglichen AWS DMS , Zugriff auf die Kinesis-Datenströme zu übernehmen und zu gewähren, in die migriert werden. In der folgenden IAM-Richtlinie sind die Mindestzugriffsberechtigungen dargestellt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Die Rolle, die Sie für die Migration zu einem Kinesis-Datenstrom verwenden, muss über die folgenden Berechtigungen verfügen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:PutRecord",
"kinesis:PutRecords"
],
"Resource": "*"
}
]
}
```
------
### Zugreifen auf einen Kinesis-Datenstream als Ziel für AWS Database Migration Service
In AWS DMS Version 3.4.7 und höher müssen Sie einen der folgenden Schritte ausführen, um eine Verbindung zu einem Kinesis-Endpunkt herzustellen:
+ Konfigurieren von DMS für die Verwendung von VPC-Endpunkten. Informationen zur Konfiguration von VPC-Endpunkten finden Sie in [Konfiguration von VPC-Endpunkten für AWS DMS](CHAP_VPC_Endpoints.md).
+ Konfigurieren Sie DMS so, dass es öffentliche Routen verwendet, d. h. Ihre Replikations-Instance öffentlich zugänglich macht. Informationen zu Replikations-Instances finden Sie unter [Öffentliche und private Replikations-Instances](CHAP_ReplicationInstance.PublicPrivate.md).
## Einschränkungen bei der Verwendung von Kinesis Data Streams als Ziel für AWS Database Migration Service
Bei der Verwendung von Kinesis Data Streams als Ziel gelten die folgenden Einschränkungen:
+ AWS DMS veröffentlicht jedes Update eines einzelnen Datensatzes in der Quelldatenbank als einen Datensatz in einem bestimmten Kinesis-Datenstrom, unabhängig von den Transaktionen. Sie können jedoch Transaktionsdetails für jeden Datensatz hinzufügen, indem Sie relevante Parameter der `KinesisSettings`-API verwenden.
+ Der vollständige LOB-Modus wird nicht unterstützt.
+ Die maximale unterstützte LOB-Größe beträgt 1 MB.
+ Kinesis Data Streams unterstützt keine Deduplizierung. Anwendungen, die Daten aus einem Stream aufnehmen, müssen doppelte Datensätze verarbeiten können. Weitere Informationen finden Sie unter [Umgang mit doppelten Datensätzen](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html) im *Amazon-Kinesis-Data-Streams-Entwicklerhandbuch*.
+ AWS DMS unterstützt die folgenden vier Formen für Partitionsschlüssel:
+ `SchemaName.TableName`: Eine Kombination des Schema- und Tabellennamens.
+ `${AttributeName}`: Der Wert in einem der Felder in der JSON-Datei oder der Primärschlüssel der Tabelle in der Quelldatenbank.
+ `transaction-id`: Die CDC-Transaktions-ID. Alle Datensätze innerhalb derselben Transaktion gehen auf dieselbe Partition.
+ `constant`: Ein fester Literalwert für jeden Datensatz, unabhängig von Tabelle oder Daten. Alle Datensätze werden an denselben Partitionsschlüsselwert „constant“ gesendet, wodurch eine strikte globale Reihenfolge in allen Tabellen gewährleistet ist.
```
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "PartitionKeyTypeExample",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "onprem",
"table-name": "it_system"
},
"mapping-parameters": {
"partition-key-type": "transaction-id | constant | attribute-name | schema-table"
}
}
```
+ Weitere Informationen zum Verschlüsseln Ihrer Daten im Ruhezustand in Kinesis Data Streams finden Sie unter [Datenschutz in Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/server-side-encryption.html.html) im *AWS Key Management Service -Entwicklerhandbuch*.
+ Die `IncludeTransactionDetails` Endpunkteinstellung wird nur unterstützt, wenn der Quellendpunkt Oracle, SQL Server, PostgreSQL oder MySQL ist. Bei anderen Quellendpunkttypen sind Transaktionsdetails nicht enthalten.
+ `BatchApply` wird für einen Kinesis-Endpunkt nicht unterstützt. Die Verwendung von Batch Apply (z. B. die `BatchApplyEnabled` Zielmetadaten-Aufgabeneinstellung) für ein Kinesis-Ziel führt zu Aufgabenfehlern und Datenverlust. Nicht aktivieren`BatchApply`, wenn Kinesis als Zielendpunkt verwendet wird.
+ Kinesis-Ziele werden nur für einen Kinesis-Datenstream im selben AWS Konto und in derselben AWS-Region Replikationsinstanz unterstützt.
+ Bei der Migration von einer MySQL-Quelle enthalten die BeforeImage Daten keine CLOB- und BLOB-Datentypen. Weitere Informationen finden Sie unter [Verwenden eines Vorher-Abbilds zum Anzeigen von Originalwerten von CDC-Zeilen für einen Kinesis-Datenstrom als Ziel](#CHAP_Target.Kinesis.BeforeImage).
+ AWS DMS unterstützt nicht die Migration von Werten mit einem `BigInt` Datentyp mit mehr als 16 Ziffern. Um diese Einschränkung zu umgehen, können Sie die folgende Transformationsregel verwenden, um die `BigInt`-Spalte in eine Zeichenfolge zu konvertieren. Informationen zu Transformationsregeln finden Sie unter [Transformationsregeln und Aktionen](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
```
{
"rule-type": "transformation",
"rule-id": "id",
"rule-name": "name",
"rule-target": "column",
"object-locator": {
"schema-name": "valid object-mapping rule action",
"table-name": "",
"column-name": ""
},
"rule-action": "change-data-type",
"data-type": {
"type": "string",
"length": 20
}
}
```
+ Wenn mehrere DML-Operationen innerhalb einer einzigen Transaktion eine LOB-Spalte (Large Object) in der Quelldatenbank ändern, behält die Zieldatenbank nur den letzten LOB-Wert der letzten Operation in dieser Transaktion bei. Die LOB-Zwischenwerte, die durch frühere Operationen in derselben Transaktion festgelegt wurden, werden überschrieben, was zu potenziellem Datenverlust oder Inkonsistenzen führen kann. Dieses Verhalten ist darauf zurückzuführen, wie LOB-Daten während der Replikation verarbeitet werden.
+ AWS DMS unterstützt keine Quelldaten mit eingebetteten `'\0'` Zeichen, wenn Kinesis als Zielendpunkt verwendet wird. Daten, die eingebettete `'\0'` Zeichen enthalten, werden beim ersten `'\0'` Zeichen gekürzt.
## Verwenden der Objektzuweisung zum Migrieren von Daten zu einem Kinesis-Datenstrom
AWS DMS verwendet Tabellenzuordnungsregeln, um Daten von der Quelle dem Kinesis-Zieldatenstrom zuzuordnen. Um Daten einem Ziel-Stream zuzuweisen , verwenden Sie eine Art von Tabellenzuweisungsregel, die als Objektzuweisung bezeichnet wird. Durch die Objektzuweisung legen Sie fest, wie Datensätze in der Quelle den im Kinesis-Datenstrom veröffentlichten Datensätzen zugewiesen werden.
Kinesis-Datenströme verfügen bis auf einen Partitionsschlüssel über keine voreingestellte Struktur. In einer Objektzuweisungsregel sind die möglichen Werte eines `partition-key-type` für Datensätze `schema-table`, `transaction-id`, `primary-key`, `constant` und `attribute-name`.
Um eine Objektzuweisungsregel zu erstellen, legen Sie `rule-type` als `object-mapping` fest. Diese Regel gibt an, welchen Objektzuweisungstyp Sie verwenden möchten.
Die Struktur für die Regel lautet wie folgt.
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "id",
"rule-name": "name",
"rule-action": "valid object-mapping rule action",
"object-locator": {
"schema-name": "case-sensitive schema name",
"table-name": ""
}
}
]
}
```
AWS DMS unterstützt derzeit `map-record-to-record` und `map-record-to-document` als einzig gültige Werte für den Parameter. `rule-action` Diese Einstellungen wirken sich auf Werte aus, die nicht in der `exclude-columns`-Attributliste ausgeschlossen sind. Die `map-record-to-document` Werte `map-record-to-record` und geben an, wie diese Datensätze standardmäßig AWS DMS behandelt werden. Diese Werte wirken sich in keiner Weise auf die Attributzuweisungen aus.
Verwenden Sie `map-record-to-record` beim Migrieren aus einer relationalen Datenbank zu einem Kinesis-Datenstrom. Dieser Regeltyp verwendet den `taskResourceId.schemaName.tableName`-Wert aus der relationalen Datenbank als Partitionsschlüssel im Kinesis-Datenstrom und erstellt ein Attribut für jede Spalte in der Quelldatenbank.
Beachten Sie bei Verwendung von `map-record-to-record` Folgendes:
+ Diese Einstellung wirkt sich nur auf Spalten aus, die durch die `exclude-columns`-Liste ausgeschlossen wurden.
+ AWS DMS Erstellt für jede dieser Spalten ein entsprechendes Attribut im Zielthema.
+ AWS DMS erstellt dieses entsprechende Attribut unabhängig davon, ob die Quellspalte in einer Attributzuordnung verwendet wird.
Verwenden Sie `map-record-to-document`, um Quellspalten in ein einziges, flaches Dokument im entsprechenden Ziel-Stream unter Verwendung des Attributnamens „\$1doc“ einzufügen. AWS DMS platziert die Daten in einer einzigen, flachen Zuweisung in der Quelle mit dem Namen „`_doc`“. Diese Platzierung gilt für jede Spalte der Quelltabelle, die nicht in der `exclude-columns`-Attributliste aufgeführt ist.
Eine Möglichkeit, `map-record-to-record` zu verstehen, besteht darin, sich die praktische Anwendung zu veranschaulichen. In diesem Beispiel wird davon ausgegangen, dass Sie mit einer Tabellenzeile einer relationalen Datenbank beginnen, die die folgende Struktur aufweist und die folgenden Daten enthält.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Um diese Informationen von einem Schema mit dem Namen `Test` zu einem Kinesis-Datenstrom zu migrieren, erstellen Sie Regeln zur Zuordnung der Daten zu dem Zieldatenstrom. Die folgende Regel veranschaulicht die Zuweisung.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToKinesis",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
}
}
]
}
```
Im Folgenden ist das resultierende Datensatzformat im Kinesis-Datenstrom dargestellt:
+ StreamName: XXX
+ PartitionKey: Test.Customers //schmaname.tableName
+ Data: //Die folgende JSON-Meldung
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
Nehmen wir jedoch an, dass Sie dieselben Regeln verwenden, den `rule-action`-Parameter jedoch in `map-record-to-document` ändern und bestimmte Spalten ausschließen. Die folgende Regel veranschaulicht die Zuweisung.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToKinesis",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
},
"mapping-parameters": {
"exclude-columns": [
"homeaddress",
"homephone",
"workaddress",
"workphone"
]
}
}
]
}
```
In diesem Fall werden die nicht im `exclude-columns`-Parameter aufgeführten Spalten `FirstName`, `LastName`, `StoreId` und `DateOfBirth` zu `_doc` zugeordnet. Im Folgenden ist das resultierende Datensatzformat dargestellt.
```
{
"data":{
"_doc":{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"DateOfBirth": "02/29/1988"
}
}
}
```
### Umstrukturieren von Daten mit Attributzuweisung
Sie können die Daten während der Migration zu einem Kinesis-Datenstrom mithilfe einer Attributzuordnung umstrukturieren. So möchten Sie zum Beispiel vielleicht mehrere Felder in der Quelle in einem einzigen Feld im Ziel vereinen. Die folgenden Attributzuordnung veranschaulicht, wie die Daten umstrukturiert werden.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToKinesis",
"rule-action": "map-record-to-record",
"target-table-name": "CustomerData",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
},
"mapping-parameters": {
"partition-key-type": "attribute-name",
"partition-key-name": "CustomerName",
"exclude-columns": [
"firstname",
"lastname",
"homeaddress",
"homephone",
"workaddress",
"workphone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${lastname}, ${firstname}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "document",
"attribute-sub-type": "json",
"value": {
"Home": {
"Address": "${homeaddress}",
"Phone": "${homephone}"
},
"Work": {
"Address": "${workaddress}",
"Phone": "${workphone}"
}
}
}
]
}
}
]
}
```
Um einen konstanten Wert für festzulegen, geben `"partition-key-type: "constant"` Sie an`partition-key`, dass dadurch der Partitionswert auf gesetzt wird. `constant` So könnten Sie auf diese Weise beispielsweise erzwingen, dass alle Daten in einem einzigen Shard gespeichert werden. Die folgende Darstellung veranschaulicht dieses Konzept.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToKinesis",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "Test",
"table-name": "Customer"
},
"mapping-parameters": {
"partition-key-type": "constant",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${FirstName},${LastName}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": {
"Home": {
"Address": "${HomeAddress}",
"Phone": "${HomePhone}"
},
"Work": {
"Address": "${WorkAddress}",
"Phone": "${WorkPhone}"
}
}
},
{
"target-attribute-name": "DateOfBirth",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${DateOfBirth}"
}
]
}
}
]
}
```
**Anmerkung**
Der `partition-key`-Wert für einen Steuerungsdatensatz, der für eine spezifische Tabelle bestimmt ist, lautet `TaskId.SchemaName.TableName`. Der `partition-key`-Wert für einen Steuerungsdatensatz, der für eine spezifische Aufgabe bestimmt ist, ist die `TaskId` des betreffenden Datensatzes. Wenn Sie einen `partition-key`-Wert in der Objektzuweisung angeben, hat dies keine Auswirkungen auf den `partition-key` für einen Steuerungsdatensatz.
Wann `attribute-name` in einer Tabellenzuordnungsregel auf festgelegt `partition-key-type` ist, müssen Sie angeben`partition-key-name`, was entweder auf eine Spalte aus der Quelltabelle oder auf eine in der Zuordnung definierte benutzerdefinierte Spalte verweisen muss. Zusätzlich `attribute-mappings` muss definiert werden, wie Quellspalten dem Ziel-Kinesis Stream zugeordnet werden.
### Nachrichtenformat für Kinesis-Datenströme
Die JSON-Ausgabe ist einfach eine Liste von Schlüssel-Wert-Paaren. Ein JSON\$1UNFORMATTED-Nachrichtenformat ist eine einzeilige JSON-Zeichenfolge mit neuem Zeilenbegrenzer.
AWS DMS stellt die folgenden reservierten Felder bereit, um die Nutzung der Daten aus den Kinesis Data Streams zu vereinfachen:
**RecordType**
Der Datensatztyp kann entweder für Daten oder zur Steuerung bestimmt sein. *Datensätze für Daten*repräsentieren die tatsächlichen Zeilen in der Quelle. *Steuerungsdatensätze* sind für wichtige Ereignisse im Stream bestimmt, z. B. einen Neustart der Aufgabe.
**Operation**
Mögliche Operationen für Datensätze sind `load`, `insert`, `update` oder `delete`.
Mögliche Operationen für Steuerungsdatensätze sind `create-table`, `rename-table`, `drop-table`, `change-columns`, `add-column`, `drop-column`, `rename-column` oder `column-type-change`.
**SchemaName**
Das Quellschema für den Datensatz. Dieses Feld kann für einen Steuerungsdatensatz leer sein.
**TableName**
Die Quelltabelle für den Datensatz. Dieses Feld kann für einen Steuerungsdatensatz leer sein.
**Zeitstempel**
Der Zeitstempel für den Zeitpunkt, an dem die JSON-Nachricht erstellt wurde. Das Feld ist mit dem ISO-8601-Format formatiert.
# Verwendung von Apache Kafka als Ziel für AWS Database Migration Service
Sie können es verwenden AWS DMS , um Daten zu einem Apache Kafka-Cluster zu migrieren. Apache Kafka ist eine verteilte Streaming-Plattform. Mit Apache Kafka können Sie Streaming-Daten in Echtzeit erfassen und verarbeiten.
AWS bietet auch Amazon Managed Streaming for Apache Kafka (Amazon MSK) zur Verwendung als Ziel an AWS DMS . Amazon MSK ist ein vollständig verwalteter Apache-Kafka-Streaming-Service, der die Implementierung und Verwaltung von Apache-Kafka-Instances vereinfacht. Es funktioniert mit Open-Source-Versionen von Apache Kafka, und Sie greifen genau wie jede Apache Kafka-Instance auf Amazon MSK-Instances als AWS DMS Ziele zu. Weitere Informationen finden Sie unter [Was ist Amazon MSK?](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) im *Entwicklerhandbuch für Amazon Managed Streaming für Apache Kafka*.
Ein Kafka-Cluster speichert Streams von Datensätzen in Kategorien, die als Themen bezeichnet und in Partitionen unterteilt werden. *Partitionen* sind eindeutig identifizierte Sequenzen von Datensätzen (Nachrichten) in einem Thema. Partitionen können über mehrere Broker in einem Cluster verteilt werden, um die parallele Verarbeitung der Datensätze eines Themas zu ermöglichen. Weitere Informationen zu Themen und Partitionen und ihrer Verteilung in Apache Kafka finden Sie unter [Themen und Protokolle](https://kafka.apache.org/documentation/#intro_topics) und [Verteilung](https://kafka.apache.org/documentation/#intro_distribution).
Bei Ihrem Kafka-Cluster kann es sich entweder um eine Amazon-MSK-Instance, einen Cluster, der auf einer Amazon-EC2-Instance ausgeführt wird, oder einen On-Premises-Cluster handeln. Eine Amazon-MSK-Instance oder ein Cluster auf einer Amazon-EC2-Instance kann sich in derselben oder einer anderen VPC befinden. Wenn es sich um einen On-Premises-Cluster handelt, können Sie Ihren eigenen On-Premises-Namensserver für Ihre Replikations-Instance verwenden, um den Host-Namen des Clusters aufzulösen. Informationen zum Einrichten eines Namensservers für Ihre Replikations-Instance finden Sie unter [Verwenden Ihres eigenen Vor-Ort-Nameservers](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver). Weitere Informationen zum Einrichten eines Netzwerks finden Sie unter [Einrichten eines Netzwerks für eine Replikations-Instance](CHAP_ReplicationInstance.VPC.md).
Wenn Sie einen Amazon-MSK-Cluster verwenden, stellen Sie sicher, dass dessen Sicherheitsgruppe den Zugriff von Ihrer Replikations-Instance aus ermöglicht. Informationen zum Ändern der Sicherheitsgruppe für einen Amazon-MSK-Cluster finden Sie unter [Ändern der Sicherheitsgruppe eines Amazon-MSK-Clusters](https://docs.aws.amazon.com/msk/latest/developerguide/change-security-group.html).
AWS Database Migration Service veröffentlicht mithilfe von JSON Datensätze zu einem Kafka-Thema. Während der Konvertierung serialisiert AWS DMS jeden Datensatz aus der Quelldatenbank in ein Attribut/Wert-Paar im JSON-Format.
Zum Migrieren Ihrer Daten von einer unterstützten Datenquelle zu einem Kafka-Ziel-Cluster verwenden Sie die Objektzuweisung. Mit der Objektzuweisung bestimmen Sie, wie die Datensätze im Zielthema strukturiert werden sollen. Außerdem definieren Sie einen Partitionsschlüssel für jede Tabelle, die Apache Kafka zum Gruppieren der Daten in seine Partitionen verwendet.
AWS DMS Unterstützt derzeit ein einzelnes Thema pro Aufgabe. Bei einer einzelnen Aufgabe mit mehreren Tabellen beziehen sich alle Nachrichten auf ein einzelnes Thema. Jede Nachricht enthält einen Metadaten-Abschnitt, der das Zielschema und die Zieltabelle identifiziert. AWS DMS Versionen 3.4.6 und höher unterstützen die themenübergreifende Replikation mithilfe von Objektzuordnung. Weitere Informationen finden Sie unter [Replikation für mehrere Themen mithilfe der Objektzuweisung](#CHAP_Target.Kafka.MultiTopic).
**Apache Kafka-Endpunkteinstellungen**
Sie können Verbindungsdetails über die Endpunkteinstellungen in der AWS DMS Konsole oder über die `--kafka-settings` Option in der CLI angeben. Es folgen die Anforderungen für jede Einstellung:
+ `Broker` – Geben Sie die Speicherorte eines oder mehrerer Broker in Ihrem Kafka-Cluster jeweils in Form einer durch Kommata getrennten Liste mit `broker-hostname:port` an. Ein Beispiel ist `"ec2-12-345-678-901.compute-1.amazonaws.com:2345,ec2-10-987-654-321.compute-1.amazonaws.com:9876"`. Mit dieser Einstellung können Sie die Speicherorte einiger oder aller Broker im Cluster angeben. Die Cluster-Broker kommunizieren miteinander, um die Partitionierung von Datensätzen zu verarbeiten, die zu dem Thema migriert wurden.
+ `Topic` – (Optional) Geben Sie den Themennamen mit einer maximalen Länge von 255 Buchstaben und Symbolen an. Sie können Punkt (.), Unterstrich (\$1) und Minuszeichen (-) verwenden. Themennamen mit einem Punkt (.) oder einem Unterstrich (\$1) können in internen Datenstrukturen kollidieren. Verwenden Sie entweder eines, aber nicht beide dieser Symbole im Namen des Themas. Wenn Sie keinen Themennamen angeben, AWS DMS verwendet `"kafka-default-topic"` als Migrationsthema.
**Anmerkung**
Wenn Sie entweder ein von Ihnen angegebenes Migrationsthema oder das Standardthema AWS DMS erstellen möchten, das `auto.create.topics.enable = true` als Teil Ihrer Kafka-Cluster-Konfiguration festgelegt wurde. Weitere Informationen finden Sie unter [Einschränkungen bei der Verwendung von Apache Kafka als Ziel für AWS Database Migration Service](#CHAP_Target.Kafka.Limitations).
+ `MessageFormat` – Das Ausgabeformat für die Datensätze, die auf dem Endpunkt erstellt wurden. Das Nachrichtenformat ist `JSON` (Standard) oder `JSON_UNFORMATTED` (eine einzelne Zeile ohne Tabulator).
+ `MessageMaxBytes` – Die maximale Größe in Byte für Datensätze, die auf dem Endpunkt erstellt wurden. Der Standardwert ist 1.000.000.
**Anmerkung**
Sie können die AWS CLI/das SDK nur verwenden, um zu einem Wert `MessageMaxBytes` zu wechseln, der nicht dem Standard entspricht. Verwenden Sie beispielsweise den folgenden Befehl, um Ihren vorhandenen Kafka-Endpunkt und `MessageMaxBytes` zu ändern.
```
aws dms modify-endpoint --endpoint-arn your-endpoint
--kafka-settings Broker="broker1-server:broker1-port,broker2-server:broker2-port,...",
Topic=topic-name,MessageMaxBytes=integer-of-max-message-size-in-bytes
```
+ `IncludeTransactionDetails` – Stellt detaillierte Transaktionsinformationen aus der Quelldatenbank bereit. Diese Informationen beinhalten einen Durchführungszeitstempel, eine Protokollposition sowie Werte für `transaction_id`, `previous_transaction_id` und `transaction_record_id` (den Datensatzoffset innerhalb einer Transaktion). Der Standardwert ist `false`.
+ `IncludePartitionValue` – Zeigt den Partitionswert innerhalb der Kafka-Nachrichtenausgabe an, es sei denn, der Partitionstyp ist `schema-table-type`. Der Standardwert ist `false`.
+ `PartitionIncludeSchemaTable` – Fügt Schema- und Tabellennamen zu Partitionswerten als Präfix hinzu, wenn der Partitionstyp `primary-key-type` ist. Dadurch wird die Datenverteilung zwischen Kafka-Partitionen erhöht. Angenommen, ein `SysBench`-Schema hat Tausende von Tabellen und jede davon hat nur einen begrenzten Bereich für einen Primärschlüssel. In diesem Fall wird derselbe Primärschlüssel von Tausenden von Tabellen an dieselbe Partition gesendet, was zu einer Drosselung führt. Der Standardwert ist `false`.
+ `IncludeTableAlterOperations` – Enthält alle DDL-Operationen (DDL = Data Definition Language), die die Tabelle in den Steuerungsdaten ändern, wie etwa `rename-table`, `drop-table`, `add-column`, `drop-column` und `rename-column`. Der Standardwert ist `false`.
+ `IncludeControlDetails` – Zeigt detaillierte Steuerungsinformationen für Tabellendefinition, Spaltendefinition und Tabellen- und Spaltenänderungen in der Kafka-Nachrichtenausgabe an. Der Standardwert ist `false`.
+ `IncludeNullAndEmpty` – Schließt NULL-Spalten und leere Spalten in das Ziel ein. Der Standardwert ist `false`.
+ `SecurityProtocol` – Richtet eine sichere Verbindung mit einem Kafka-Zielendpunkt mit Transport Layer Security (TLS) ein. Optionen: `ssl-authentication`, `ssl-encryption` und `sasl-ssl`. Für die Verwendung von `sasl-ssl` sind `SaslUsername` und `SaslPassword` erforderlich.
+ `SslEndpointIdentificationAlgorithm`— Legt die Überprüfung des Hostnamens für das Zertifikat fest. Diese Einstellung wird in AWS DMS Version 3.5.1 und höher unterstützt. Es gibt die folgenden Optionen:
+ `NONE`: Deaktiviert die Überprüfung des Hostnamens des Brokers in der Client-Verbindung.
+ `HTTPS`: Aktiviert die Überprüfung des Hostnamens des Brokers in der Client-Verbindung.
+ `useLargeIntegerValue`— Verwenden Sie bis zu 18-stellige Ganzzahlen, anstatt Ganzzahlen als Doppelzahl umzuwandeln. Dies ist ab AWS DMS Version 3.5.4 verfügbar. Der Standardwert lautet „false“.
Sie können Einstellungen verwenden, um die Übertragungsgeschwindigkeit zu erhöhen. Dazu unterstützt AWS DMS Multi-Thread-Volllastvorgänge in einen Ziel-Cluster in Apache Kafka. AWS DMS unterstützt Multi-Threading u. a. mithilfe der folgenden Aufgabeneinstellungen:
+ `MaxFullLoadSubTasks`— Verwenden Sie diese Option, um die maximale Anzahl von Quelltabellen anzugeben, die parallel geladen werden sollen. AWS DMS lädt jede Tabelle mithilfe einer speziellen Unteraufgabe in die entsprechende Kafka-Zieltabelle. Der Standardwert beträgt 8; der Maximalwert beträgt 49.
+ `ParallelLoadThreads`— Verwenden Sie diese Option, um die Anzahl der Threads anzugeben, die AWS DMS verwendet werden, um jede Tabelle in ihre Kafka-Zieltabelle zu laden. Der maximale Wert für ein Apache Kafka-Ziel ist 32. Sie können eine Erhöhung dieses Höchstwerts anfordern.
+ `ParallelLoadBufferSize` – Verwenden Sie diese Option, um die maximale Anzahl der Datensätze anzugeben, die in dem Puffer gespeichert werden sollen, den die parallelen Lade-Threads zum Laden von Daten in das Kafka-Ziel verwenden. Der Standardwert lautet 50. Die maximale Wert ist 1.000. Verwenden Sie diese Einstellung mit `ParallelLoadThreads`; `ParallelLoadBufferSize` ist nur gültig, wenn es mehr als einen Thread gibt.
+ `ParallelLoadQueuesPerThread` – Verwenden Sie diese Option, um die Anzahl der Warteschlangen anzugeben, auf die jeder gleichzeitige Thread zugreift, um Datensätze aus Warteschlangen zu entfernen und eine Stapellast für das Ziel zu generieren. Der Standardwert ist 1. Der Höchstwert ist 512.
Sie können die Leistung der Erfassung von Datenänderungen (Change Data Capture, CDC) für Kafka-Endpunkte verbessern, indem Sie die Aufgabeneinstellungen für parallele Threads und Massenoperationen optimieren. Dazu können Sie die Anzahl der gleichzeitigen Threads, der Warteschlangen pro Thread und die Anzahl der Datensätze angeben, die in einem Puffer unter Verwendung von `ParallelApply*`-Aufgabeneinstellungen gespeichert werden sollen. Beispiel: Sie möchten eine CDC-Last durchführen und 128 Threads parallel anwenden. Außerdem möchten Sie auf 64 Warteschlangen pro Thread zugreifen, wobei 50 Datensätze pro Puffer gespeichert sind.
AWS DMS Unterstützt die folgenden Task-Einstellungen, um die CDC-Leistung zu verbessern:
+ `ParallelApplyThreads`— Gibt die Anzahl gleichzeitiger Threads an, die während eines CDC-Ladevorgangs AWS DMS verwendet werden, um Datensätze an einen Kafka-Zielendpunkt zu übertragen. Der Standardwert ist Null (0) und der maximale Wert ist 32.
+ `ParallelApplyBufferSize` – Gibt die maximale Anzahl von Datensätzen an, die in jeder Pufferwarteschlange für gleichzeitige Threads gespeichert werden sollen, um sie während einer CDC-Last an einen Kafka-Zielendpunkt zu übertragen. Der Standardwert ist 100 und der Höchstwert 1 000. Verwenden Sie diese Option, wenn `ParallelApplyThreads` mehrere Threads angibt.
+ `ParallelApplyQueuesPerThread` – Gibt die Anzahl der Warteschlangen an, auf die jeder Thread zugreift, um Datensätze aus Warteschlangen zu entfernen und während CDC eine Stapellast für einen Kafka-Endpunkt zu generieren. Der Standardwert ist 1. Der Höchstwert ist 512.
Wenn Sie `ParallelApply*`-Aufgabeneinstellungen verwenden, ist der `primary-key` der Tabelle der `partition-key-type`-Standardwert, nicht `schema-name.table-name`.
## Herstellen einer Verbindung zu Kafka mit Transport Layer Security (TLS)
Ein Kafka-Cluster akzeptiert sichere Verbindungen mit Transport Layer Security (TLS). Mit DMS können Sie eine der folgenden drei Sicherheitsprotokoll-Optionen verwenden, um eine Verbindung mit einem Kafka-Endpunkt zu sichern.
**SSL-Verschlüsselung (`server-encryption`)**
Clients validieren die Serveridentität anhand des Serverzertifikats. Anschließend wird eine verschlüsselte Verbindung zwischen Server und Client hergestellt.
**SSL-Authentifizierung (`mutual-authentication`)**
Server und Client validieren die Identität untereinander durch ihre eigenen Zertifikate. Anschließend wird eine verschlüsselte Verbindung zwischen Server und Client hergestellt.
**SASL-SSL (`mutual-authentication`)**
Bei der Methode Simple Authentication and Security Layer (SASL) wird das Zertifikat des Clients durch einen Benutzernamen und ein Passwort ersetzt, um die Identität eines Clients zu überprüfen. Sie geben einen Benutzernamen und ein Passwort an, die der Server registriert hat, damit der Server die Identität eines Clients überprüfen kann. Anschließend wird eine verschlüsselte Verbindung zwischen Server und Client hergestellt.
**Wichtig**
Apache Kafka und Amazon MSK akzeptieren aufgelöste Zertifikate. Dies ist eine bekannte Einschränkung von Kafka und Amazon MSK, die behoben werden muss. Weitere Informationen finden Sie unter [Apache Kafka issues, KAFKA-3700](https://issues.apache.org/jira/browse/KAFKA-3700).
Wenn Sie Amazon MSK verwenden, sollten Sie die Verwendung von Zugriffskontrolllisten (ACLs) als Workaround für diese bekannte Einschränkung in Betracht ziehen. Weitere Informationen zur Verwendung ACLs finden Sie im ACLs Abschnitt [Apache Kafka](https://docs.aws.amazon.com//msk/latest/developerguide/msk-acls.html) im *Amazon Managed Streaming for Apache Kafka Developer Guide*.
Wenn Sie einen selbstverwalteten Kafka-Cluster verwenden, finden Sie Informationen zur Konfiguration des Clusters im [Kommentar vom 21. Oktober 18](https://issues.apache.org/jira/browse/KAFKA-3700?focusedCommentId=16658376).
### Verwenden von SSL-Verschlüsselung mit Amazon MSK oder einem selbstverwalteten Kafka-Cluster
Sie können SSL-Verschlüsselung verwenden, um eine Endpunktverbindung mit Amazon MSK oder einem selbstverwalteten Kafka-Cluster zu sichern. Wenn Sie die SSL-Verschlüsselung als Authentifizierungsmethode verwenden, validieren Clients die Identität eines Servers anhand des Serverzertifikats. Anschließend wird eine verschlüsselte Verbindung zwischen Server und Client hergestellt.
**So verwenden Sie SSL-Verschlüsselung für die Verbindung mit Amazon MSK**
+ Legen Sie die Sicherheitsprotokoll-Endpunkteinstellung (`SecurityProtocol`) mithilfe der Option `ssl-encryption` fest, wenn Sie Ihren Kafka-Zielendpunkt erstellen.
Im folgenden JSON-Beispiel wird das Sicherheitsprotokoll als SSL-Verschlüsselung festgelegt.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
**So verwenden Sie SSL-Verschlüsselung für einen selbstverwalteten Kafka-Cluster**
1. Wenn Sie eine private Zertifizierungsstelle (Certification Authority, CA) in Ihrem On-Premises-Kafka-Cluster verwenden, laden Sie Ihr privates CA-Zertifikat hoch, um einen Amazon-Ressourcennamen (ARN) abzurufen.
1. Legen Sie die Sicherheitsprotokoll-Endpunkteinstellung (`SecurityProtocol`) mithilfe der Option `ssl-encryption` fest, wenn Sie Ihren Kafka-Zielendpunkt erstellen. Im folgenden JSON-Beispiel wird das Sicherheitsprotokoll als `ssl-encryption` festgelegt.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
1. Wenn Sie eine private CA verwenden, legen Sie `SslCaCertificateArn` im ARN fest, den Sie im ersten Schritt abgerufen haben.
### Verwenden von SSL-Authentifizierung
Sie können SSL-Authentifizierung verwenden, um eine Endpunktverbindung mit Amazon MSK oder einem selbstverwalteten Kafka-Cluster zu sichern.
Gehen Sie wie folgt vor, um die Client-Authentifizierung und -Verschlüsselung mithilfe von SSL-Authentifizierung für die Verbindung mit Amazon MSK zu aktivieren:
+ Bereiten Sie einen privaten Schlüssel und ein öffentliches Zertifikat für Kafka vor.
+ Laden Sie die Zertifikate in den DMS-Zertifikatmanager hoch.
+ Erstellen Sie einen Kafka-Zielendpunkt mit dem entsprechenden Zertifikat, das in den Kafka-Endpunkteinstellungen ARNs angegeben ist.
**So bereiten Sie einen privaten Schlüssel und ein öffentliches Zertifikat für Amazon MSK vor**
1. Erstellen Sie eine EC2-Instance und richten Sie einen Client zur Verwendung der Authentifizierung ein, wie in den Schritten 1 bis 9 im Abschnitt zur [Client-Authentifizierung](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) im *Entwicklerhandbuch für Amazon Managed Streaming für Apache Kafka* beschrieben.
Nachdem Sie diese Schritte abgeschlossen haben, verfügen Sie über einen Zertifikat-ARN (den in ACM gespeicherten öffentlichen Zertifikat-ARN) und einen privaten Schlüssel, der in einer Datei mit dem Namen `kafka.client.keystore.jks` enthalten ist.
1. Rufen Sie das öffentliche Zertifikat ab und kopieren Sie das Zertifikat mit dem folgenden Befehl in die Datei `signed-certificate-from-acm.pem`:
```
aws acm-pca get-certificate --certificate-authority-arn Private_CA_ARN --certificate-arn Certificate_ARN
```
Dieser Befehl gibt ähnliche Informationen wie im folgenden Beispiel zurück:
```
{"Certificate": "123", "CertificateChain": "456"}
```
Anschließend kopieren Sie Ihr Äquivalent von `"123"` in die Datei `signed-certificate-from-acm.pem`.
1. Rufen Sie den privaten Schlüssel ab, indem Sie den Schlüssel `msk-rsa` aus `kafka.client.keystore.jks to keystore.p12` importieren, wie im folgenden Beispiel gezeigt.
```
keytool -importkeystore \
-srckeystore kafka.client.keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12 \
-srcalias msk-rsa-client \
-deststorepass test1234 \
-destkeypass test1234
```
1. Verwenden Sie den folgenden Befehl, um `keystore.p12` in das Format `.pem` zu exportieren.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-client-key.pem –nocerts
```
Die Meldung **PEM-Passphrase eingeben** wird angezeigt und gibt den Schlüssel an, der zur Verschlüsselung des Zertifikats verwendet wird.
1. Entfernen Sie Taschen- und Schlüsselattribute aus der `.pem`-Datei, um sicherzustellen, dass die erste Zeile mit der folgenden Zeichenfolge beginnt.
```
---BEGIN ENCRYPTED PRIVATE KEY---
```
**So laden Sie ein öffentliches Zertifikat und einen privaten Schlüssel in den DMS-Zertifikatmanager hoch und testen die Verbindung mit Amazon MSK**
1. Führen Sie den folgenden Befehl aus, um den Upload in den DMS-Zertifikatmanager auszuführen.
```
aws dms import-certificate --certificate-identifier signed-cert --certificate-pem file://path to signed cert
aws dms import-certificate --certificate-identifier private-key —certificate-pem file://path to private key
```
1. Erstellen Sie einen Amazon-MSK-Zielendpunkt und testen Sie die Verbindung, um sicherzustellen, dass die TLS-Authentifizierung funktioniert.
```
aws dms create-endpoint --endpoint-identifier $endpoint-identifier --engine-name kafka --endpoint-type target --kafka-settings
'{"Broker": "b-0.kafka260.aaaaa1.a99.kafka.us-east-1.amazonaws.com:0000", "SecurityProtocol":"ssl-authentication",
"SslClientCertificateArn": "arn:aws:dms:us-east-1:012346789012:cert:",
"SslClientKeyArn": "arn:aws:dms:us-east-1:0123456789012:cert:","SslClientKeyPassword":"test1234"}'
aws dms test-connection -replication-instance-arn=$rep_inst_arn —endpoint-arn=$kafka_tar_arn_msk
```
**Wichtig**
Sie können SSL-Authentifizierung verwenden, um eine Verbindung mit einem selbstverwalteten Kafka-Cluster zu sichern. In Einzelfällen können Sie eine private Zertifizierungsstelle (CA) in Ihrem On-Premises-Kafka-Cluster verwenden. Laden Sie in diesem Fall Ihre CA-Kette, das öffentliche Zertifikat und den privaten Schlüssel in den DMS-Zertifikatmanager hoch. Verwenden Sie dann den entsprechenden Amazon-Ressourcennamen (ARN) in Ihren Endpunkteinstellungen, wenn Sie Ihren On-Premises-Kafka-Zielendpunkt erstellen.
**So bereiten Sie einen privaten Schlüssel und ein signiertes Zertifikat für einen selbstverwalteten Kafka-Cluster vor**
1. Erzeugen Sie ein Schlüsselpaar wie im folgenden Beispiel dargestellt.
```
keytool -genkey -keystore kafka.server.keystore.jks -validity 300 -storepass your-keystore-password
-keypass your-key-passphrase -dname "CN=your-cn-name"
-alias alias-of-key-pair -storetype pkcs12 -keyalg RSA
```
1. Generieren Sie eine Anfrage zum Signieren des Zertifikats (Certificate Sign Request, CSR).
```
keytool -keystore kafka.server.keystore.jks -certreq -file server-cert-sign-request-rsa -alias on-premise-rsa -storepass your-key-store-password
-keypass your-key-password
```
1. Verwenden Sie die CA in Ihrem Cluster-Truststore zum Signieren der CSR. Wenn Sie keine CA haben, können Sie Ihre eigene private CA erstellen.
```
openssl req -new -x509 -keyout ca-key -out ca-cert -days validate-days
```
1. Importieren Sie `ca-cert` in den Truststore und Keystore des Servers. Wenn Sie keinen Truststore haben, führen Sie folgenden Befehl aus, um den Truststore zu erstellen und `ca-cert ` in diesen zu importieren.
```
keytool -keystore kafka.server.truststore.jks -alias CARoot -import -file ca-cert
keytool -keystore kafka.server.keystore.jks -alias CARoot -import -file ca-cert
```
1. Signieren Sie das Zertifikat.
```
openssl x509 -req -CA ca-cert -CAkey ca-key -in server-cert-sign-request-rsa -out signed-server-certificate.pem
-days validate-days -CAcreateserial -passin pass:ca-password
```
1. Importieren Sie das signierte Zertifikat in den Keystore.
```
keytool -keystore kafka.server.keystore.jks -import -file signed-certificate.pem -alias on-premise-rsa -storepass your-keystore-password
-keypass your-key-password
```
1. Verwenden Sie den folgenden Befehl, um den Schlüssel `on-premise-rsa` von `kafka.server.keystore.jks` in `keystore.p12` zu importieren.
```
keytool -importkeystore \
-srckeystore kafka.server.keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12 \
-srcalias on-premise-rsa \
-deststorepass your-truststore-password \
-destkeypass your-key-password
```
1. Verwenden Sie den folgenden Befehl, um `keystore.p12` in das Format `.pem` zu exportieren.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-server-key.pem –nocerts
```
1. Laden Sie `encrypted-private-server-key.pem`, `signed-certificate.pem` und `ca-cert` in den DMS-Zertifikatmanager hoch.
1. Erstellen Sie einen Endpunkt mithilfe des zurückgegebenen. ARNs
```
aws dms create-endpoint --endpoint-identifier $endpoint-identifier --engine-name kafka --endpoint-type target --kafka-settings
'{"Broker": "b-0.kafka260.aaaaa1.a99.kafka.us-east-1.amazonaws.com:9092", "SecurityProtocol":"ssl-authentication",
"SslClientCertificateArn": "your-client-cert-arn","SslClientKeyArn": "your-client-key-arn","SslClientKeyPassword":"your-client-key-password",
"SslCaCertificateArn": "your-ca-certificate-arn"}'
aws dms test-connection -replication-instance-arn=$rep_inst_arn —endpoint-arn=$kafka_tar_arn_msk
```
### Verwenden von SASL-SSL-Authentifizierung für die Verbindung mit Amazon MSK
Bei der Methode Simple Authentication and Security Layer (SASL) werden ein Benutzername und ein Passwort verwendet, um die Identität eines Clients zu überprüfen, und es wird eine verschlüsselte Verbindung zwischen Server und Client hergestellt.
Um SASL zu verwenden, erstellen Sie zunächst einen sicheren Benutzernamen und ein sicheres Passwort, wenn Sie Ihren Amazon-MSK-Cluster einrichten. Eine Beschreibung, wie Sie einen sicheren Benutzernamen und ein sicheres Passwort für einen Amazon MSK-Cluster einrichten, finden Sie unter [Einrichten der SASL/SCRAM Authentifizierung für einen Amazon MSK-Cluster im Amazon](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html#msk-password-tutorial) *Managed Streaming for Apache Kafka* Developer Guide.
Wenn Sie dann Ihren Kafka-Zielendpunkt erstellen, legen Sie die Sicherheitsprotokoll-Endpunkteinstellung (`SecurityProtocol`) mithilfe der Option `sasl-ssl` fest. Legen Sie auch die Optionen `SaslUsername` und `SaslPassword` fest. Stellen Sie sicher, dass diese mit dem sicheren Benutzernamen und Passwort übereinstimmen, die Sie bei der erstmaligen Einrichtung Ihres Amazon-MSK-Clusters erstellt haben, wie im folgenden JSON-Beispiel gezeigt.
```
"KafkaSettings": {
"SecurityProtocol": "sasl-ssl",
"SaslUsername":"Amazon MSK cluster secure user name",
"SaslPassword":"Amazon MSK cluster secure password"
}
```
**Anmerkung**
Unterstützt derzeit nur öffentliches, von CA AWS DMS unterstütztes SASL-SSL. DMS unterstützt SASL-SSL nicht für die Verwendung mit selbstverwaltetem Kafka, das von einer privaten CA unterstützt wird.
Unterstützt für die SASL-SSL-Authentifizierung standardmäßig den SCRAM-SHA-512-Mechanismus AWS DMS . AWS DMS Versionen 3.5.0 und höher unterstützen auch den Plain-Mechanismus. Setzen Sie den Parameter `SaslMechanism` des API-Datentyps `KafkaSettings` auf `PLAIN`, um den Plain-Mechanismus zu unterstützen. Der Datentyp `PLAIN` wird von Kafka unterstützt, aber nicht von Amazon Kafka (MSK).
## Verwenden eines Vorher-Abbilds zum Anzeigen von Originalwerten von CDC-Zeilen für Apache Kafka als Ziel
Beim Schreiben von CDC-Aktualisierungen auf ein Data-Streaming-Ziel wie Kafka können Sie die ursprünglichen Werte einer Quelldatenbankzeile anzeigen, bevor sie durch eine Aktualisierung geändert werden. Um dies zu ermöglichen, AWS DMS füllt es ein *Vorher-Bild* der Aktualisierungsereignisse auf der Grundlage von Daten aus, die von der Quelldatenbank-Engine bereitgestellt werden.
Verschiedene Quelldatenbank-Engines liefern unterschiedliche Mengen an Informationen für ein Vorher-Abbild:
+ Oracle stellt für Spalten nur dann Aktualisierungen bereit, wenn sie sich ändern.
+ PostgreSQL stellt nur Daten für Spalten bereit, die Teil des Primärschlüssels sind (geändert oder nicht). Wenn eine logische Replikation verwendet wird und REPLICA IDENTITY FULL für die Quelltabelle festgelegt ist, können Sie vollständige Vorher-Nachher-Informationen zu der Zeile abrufen, die in die geschrieben wurde WALs und hier verfügbar ist.
+ MySQL stellt generell Daten für alle Spalten (geändert oder nicht) bereit.
Verwenden Sie entweder die `BeforeImageSettings`-Aufgabeneinstellung oder den `add-before-image-columns`-Parameter, um die Erstellung von Vorher-Abbildern zum Hinzufügen von Originalwerten aus der Quelldatenbank zur AWS DMS -Ausgabe zu aktivieren. Dieser Parameter wendet eine Spalten-Transformationsregel an.
`BeforeImageSettings` fügt jeder Aktualisierungsoperation ein neues JSON-Attribut mit Werten hinzu, die aus dem Quelldatenbanksystem erfasst werden, wie nachfolgend gezeigt.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**Anmerkung**
Wenden Sie `BeforeImageSettings` auf Volllast plus CDC-Aufgaben (die vorhandene Daten migrieren und laufende Änderungen replizieren) oder nur auf CDC-Aufgaben (die nur Datenänderungen replizieren) an. Wenden Sie `BeforeImageSettings` nicht auf Nur-Volllast-Aufgaben an.
Für `BeforeImageSettings`-Optionen gilt Folgendes:
+ Legen Sie die `EnableBeforeImage`-Option vor dem Imaging auf `true` fest. Der Standardwert ist `false`.
+ Verwenden Sie die `FieldName`-Option, um dem neuen JSON-Attribut einen Namen zuzuweisen. Wann `EnableBeforeImage` `true` ist, ist `FieldName` erforderlich und darf nicht leer sein.
+ Die `ColumnFilter`-Option gibt eine Spalte an, die vor dem Imaging hinzugefügt werden soll. Wenn Sie nur Spalten hinzufügen möchten, die Teil der Primärschlüssel der Tabelle sind, verwenden Sie den Standardwert `pk-only`. Wenn Sie nur Spalten hinzufügen möchten, die nicht vom LOB-Typ sind, verwenden Sie `non-lob`. Wenn Sie eine Spalte hinzufügen möchten, die einen Vorher-Abbild-Wert hat, verwenden Sie `all`.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
### Verwenden einer Vorher-Abbild-Transformationsregel
Alternativ zu den Aufgabeneinstellungen können Sie den `add-before-image-columns`-Parameter verwenden, der eine Spalten-Transformationsregel anwendet. Mit diesem Parameter können Sie das Vorher-Imaging während des CDC-Vorgangs auf Data-Streaming-Zielen wie Kafka aktivieren.
Wenn Sie `add-before-image-columns` in einer Transformationsregel verwenden, können Sie eine feinere Steuerung der Ergebnisse für das Vorher-Abbild anwenden. Mit Transformationsregeln können Sie einen Objekt-Locator verwenden, der Ihnen die Kontrolle über die für die Regel ausgewählten Tabellen gibt. Außerdem können Sie Transformationsregeln miteinander verketten, wodurch verschiedene Regeln auf verschiedene Tabellen angewendet werden können. Anschließend können Sie die erzeugten Spalten mithilfe anderer Regeln bearbeiten.
**Anmerkung**
Verwenden Sie den `add-before-image-columns`-Parameter nicht zusammen mit der `BeforeImageSettings`-Aufgabeneinstellung innerhalb derselben Aufgabe. Verwenden Sie stattdessen entweder den Parameter oder die Einstellung, aber nicht beide, für eine einzelne Aufgabe.
Ein `transformation`-Regeltyp mit dem `add-before-image-columns`-Parameter für eine Spalte muss einen `before-image-def`-Abschnitt bereitstellen. Es folgt ein Beispiel.
```
{
"rule-type": "transformation",
…
"rule-target": "column",
"rule-action": "add-before-image-columns",
"before-image-def":{
"column-filter": one-of (pk-only / non-lob / all),
"column-prefix": string,
"column-suffix": string,
}
}
```
Der Wert von `column-prefix` wird einem Spaltennamen vorangestellt, und der Standardwert von `column-prefix` ist `BI_`. Der Wert von `column-suffix` wird an den Spaltennamen angehängt, und der Standardwert ist leer. Setzen Sie nicht `column-prefix` und `column-suffix` auf leere Zeichenfolgen.
Wählen Sie einen Wert für `column-filter`. Wenn Sie nur Spalten hinzufügen möchten, die Teil der Primärschlüssel der Tabelle sind, wählen Sie `pk-only` . Wählen Sie `non-lob`, um nur Spalten hinzuzufügen, die nicht vom LOB-Typ sind. Oder lassen`all` Sie eine Spalte hinzufügen, die einen Vorher-Abbild-Wert hat.
### Beispiel für eine Vorher-Abbild-Transformationsregel
Die Transformationsregel im folgenden Beispiel fügt eine neue Spalte mit dem Namen `BI_emp_no` auf dem Ziel hinzu. Eine Anweisung wie `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` füllt daher das `BI_emp_no` Feld mit 1. Wenn Sie CDC-Aktualisierungen für Amazon-S3-Ziele schreiben, ermöglicht die `BI_emp_no`-Spalte, zu erkennen, welche ursprüngliche Zeile aktualisiert wurde.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "employees"
},
"rule-action": "add-before-image-columns",
"before-image-def": {
"column-prefix": "BI_",
"column-suffix": "",
"column-filter": "pk-only"
}
}
]
}
```
Weitere Informationen zur Verwendung der `add-before-image-columns`-Regelaktion finden Sie unter [Transformationsregeln und Aktionen](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Einschränkungen bei der Verwendung von Apache Kafka als Ziel für AWS Database Migration Service
Bei der Verwendung von Apache Kafka als Ziel gelten die folgenden Einschränkungen:
+ AWS DMS Kafka-Zielendpunkte unterstützen keine IAM-Zugriffskontrolle für Amazon Managed Streaming for Apache Kafka (Amazon MSK).
+ Der vollständige LOB-Modus wird nicht unterstützt.
+ Geben Sie eine Kafka-Konfigurationsdatei für Ihren Cluster mit Eigenschaften an, mit denen Sie automatisch neue Themen erstellen können AWS DMS . Schließen Sie die Einstellung `auto.create.topics.enable = true` ein. Wenn Sie Amazon MSK verwenden, können Sie beim Erstellen Ihres Kafka-Clusters die Standardkonfiguration angeben und dann die Einstellung `auto.create.topics.enable` in `true` ändern. Weitere Informationen zu den Standardkonfigurationseinstellungen finden Sie unter [Die Standardkonfiguration von Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/msk-default-configuration.html) im *Entwicklerhandbuch für Amazon Managed Streaming für Apache Kafka*. Wenn Sie einen vorhandenen Kafka-Cluster ändern müssen, der mit Amazon MSK erstellt wurde, führen Sie den AWS CLI Befehl aus, `aws kafka create-configuration` um Ihre Kafka-Konfiguration zu aktualisieren, wie im folgenden Beispiel gezeigt:
```
14:38:41 $ aws kafka create-configuration --name "kafka-configuration" --kafka-versions "2.2.1" --server-properties file://~/kafka_configuration
{
"LatestRevision": {
"Revision": 1,
"CreationTime": "2019-09-06T14:39:37.708Z"
},
"CreationTime": "2019-09-06T14:39:37.708Z",
"Name": "kafka-configuration",
"Arn": "arn:aws:kafka:us-east-1:111122223333:configuration/kafka-configuration/7e008070-6a08-445f-9fe5-36ccf630ecfd-3"
}
```
Hier ist `//~/kafka_configuration` die Konfigurationsdatei, die Sie mit den erforderlichen Eigenschaftseinstellungen erstellt haben.
Wenn Sie Ihre eigene Kafka-Instance verwenden, die auf Amazon EC2 installiert ist, ändern Sie die Kafka-Cluster-Konfiguration mit der `auto.create.topics.enable = true` Einstellung, dass mithilfe der in Ihrer Instance bereitgestellten Optionen automatisch neue Themen erstellt werden können AWS DMS .
+ AWS DMS veröffentlicht jedes Update eines einzelnen Datensatzes in der Quelldatenbank als einen Datensatz (Nachricht) in einem bestimmten Kafka-Thema, unabhängig von den Transaktionen.
+ AWS DMS unterstützt die folgenden vier Formen für Partitionsschlüssel:
+ `SchemaName.TableName`: Eine Kombination des Schema- und Tabellennamens.
+ `${AttributeName}`: Der Wert in einem der Felder in der JSON-Datei oder der Primärschlüssel der Tabelle in der Quelldatenbank.
+ `transaction-id`: Die CDC-Transaktions-ID. Alle Datensätze innerhalb derselben Transaktion gehen auf dieselbe Partition.
+ `constant`: Ein fester Literalwert für jeden Datensatz, unabhängig von Tabelle oder Daten. Alle Datensätze werden an denselben Partitionsschlüsselwert „constant“ gesendet, wodurch eine strikte globale Reihenfolge in allen Tabellen gewährleistet ist.
```
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransactionIdPartitionKey",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "onprem",
"table-name": "it_system"
},
"mapping-parameters": {
"partition-key-type": "transaction-id | constant | attribute-name | schema-table"
}
}
```
+ Die `IncludeTransactionDetails` Endpunkteinstellung wird nur unterstützt, wenn der Quellendpunkt Oracle, SQL Server, PostgreSQL oder MySQL ist. Bei anderen Quellendpunkttypen sind Transaktionsdetails nicht enthalten.
+ `BatchApply` wird für einen Kafka-Endpunkt nicht unterstützt. Bei Verwendung von Batch Apply (z. B. der Zielmetadaten-Aufgabeneinstellung `BatchApplyEnabled`) für ein Kafka-Ziel kann es zu einem Datenverlust kommen.
+ AWS DMS unterstützt nicht die Migration von Werten eines `BigInt` Datentyps mit mehr als 16 Ziffern. Um diese Einschränkung zu umgehen, können Sie die folgende Transformationsregel verwenden, um die `BigInt`-Spalte in eine Zeichenfolge zu konvertieren. Informationen zu Transformationsregeln finden Sie unter [Transformationsregeln und Aktionen](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
```
{
"rule-type": "transformation",
"rule-id": "id",
"rule-name": "name",
"rule-target": "column",
"object-locator": {
"schema-name": "valid object-mapping rule action",
"table-name": "",
"column-name": ""
},
"rule-action": "change-data-type",
"data-type": {
"type": "string",
"length": 20
}
}
```
+ AWS DMS Kafka-Zielendpunkte unterstützen Amazon MSK Servless nicht.
+ Bei der Definition von Zuordnungsregeln wird es nicht unterstützt, sowohl eine Objektzuordnungsregel als auch eine Transformationsregel zu verwenden. Sie müssen nur eine Regel festlegen.
+ AWS DMS unterstützt die SASL-Authentifizierung für Apache Kafka-Versionen bis 3.8. Wenn Sie Kafka 4.0 oder höher verwenden, können Sie nur ohne SASL-Authentifizierung eine Verbindung herstellen.
+ AWS DMS unterstützt keine Quelldaten mit eingebetteten `'\0'` Zeichen, wenn Kafka als Zielendpunkt verwendet wird. Daten, die eingebettete `'\0'` Zeichen enthalten, werden beim ersten `'\0'` Zeichen gekürzt.
## Verwenden der Objektzuweisung zum Migrieren von Daten zu einem Kafka-Thema
AWS DMS verwendet Regeln für die Tabellenzuweisung, um Daten aus der Quelle dem Kafka-Zielthema zuzuordnen. Um Daten einem Zielthema zuzuweisen, verwenden Sie eine Art von Tabellenzuweisungsregel, die als Objektzuweisung bezeichnet wird. Mit der Objektzuweisung legen Sie fest, wie Datensätze in der Quelle den in einem Kafka-Thema veröffentlichten Datensätzen zugewiesen werden.
Kafka-Themen verfügen bis auf einen Partitionsschlüssel über keine voreingestellte Struktur.
**Anmerkung**
Sie müssen die Objektzuweisung nicht verwenden. Sie können die reguläre Tabellenzuweisung für verschiedene Transformationen verwenden. Der Partitionsschlüsseltyp folgt jedoch diesen Standardverhaltensweisen:
Der Primärschlüssel wird als Partitionsschlüssel für Volllast verwendet.
Wenn keine Aufgabeneinstellungen für die parallele Anwendung verwendet werden, wird `schema.table` als Partitionsschlüssel für CDC verwendet.
Wenn Aufgabeneinstellungen für parallele Anwendung verwendet werden, wird der Primärschlüssel als Partitionsschlüssel für CDC verwendet.
Um eine Objektzuweisungsregel zu erstellen, legen Sie `rule-type` als `object-mapping` fest. Diese Regel gibt an, welchen Objektzuweisungstyp Sie verwenden möchten.
Die Struktur für die Regel lautet wie folgt.
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "id",
"rule-name": "name",
"rule-action": "valid object-mapping rule action",
"object-locator": {
"schema-name": "case-sensitive schema name",
"table-name": ""
}
}
]
}
```
AWS DMS unterstützt derzeit `map-record-to-record` und `map-record-to-document` als einzig gültige Werte für den Parameter. `rule-action` Diese Einstellungen wirken sich auf Werte aus, die nicht in der `exclude-columns`-Attributliste ausgeschlossen sind. Die `map-record-to-document` Werte `map-record-to-record` und geben an, wie diese Datensätze standardmäßig AWS DMS behandelt werden. Diese Werte wirken sich in keiner Weise auf die Attributzuweisungen aus.
Verwenden Sie `map-record-to-record` beim Migrieren aus einer relationalen Datenbank zu einem Kafka-Thema. Dieser Regeltyp verwendet den `taskResourceId.schemaName.tableName`-Wert aus der relationalen Datenbank als Partitionsschlüssel in dem Kafka-Thema und erstellt ein Attribut für jede Spalte in der Quelldatenbank.
Beachten Sie bei Verwendung von `map-record-to-record` Folgendes:
+ Diese Einstellung wirkt sich nur auf Spalten aus, die durch die `exclude-columns`-Liste ausgeschlossen wurden.
+ AWS DMS Erstellt für jede dieser Spalten ein entsprechendes Attribut im Zielthema.
+ AWS DMS erstellt dieses entsprechende Attribut unabhängig davon, ob die Quellspalte in einer Attributzuordnung verwendet wird.
Eine Möglichkeit, `map-record-to-record` zu verstehen, besteht darin, sich die praktische Anwendung zu veranschaulichen. In diesem Beispiel wird davon ausgegangen, dass Sie mit einer Tabellenzeile einer relationalen Datenbank beginnen, die die folgende Struktur aufweist und die folgenden Daten enthält.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Um diese Informationen von einem Schema mit dem Namen `Test` zu einem Kafka-Thema zu migrieren, erstellen Sie Regeln, um die Daten dem Zielthema zuzuweisen. Die folgende Regel veranschaulicht die Zuweisung.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToKafka",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
}
}
]
}
```
Nachfolgend wird das resultierende Datensatzformat bei Verwendung unserer Beispieldaten in dem Kafka-Zielthema für ein bestimmtes Kafka-Thema und einen bestimmten Partitionsschlüssel (in diesem Fall `taskResourceId.schemaName.tableName`) illustriert.
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
**Topics**
+ [Umstrukturieren von Daten mit Attributzuweisung](#CHAP_Target.Kafka.AttributeMapping)
+ [Replikation für mehrere Themen mithilfe der Objektzuweisung](#CHAP_Target.Kafka.MultiTopic)
+ [Nachrichtenformat für Apache Kafka](#CHAP_Target.Kafka.Messageformat)
### Umstrukturieren von Daten mit Attributzuweisung
Sie können die Daten umstrukturieren, während Sie sie mittels einer Attributzuweisung zu einem Kafka-Thema migrieren. So möchten Sie zum Beispiel vielleicht mehrere Felder in der Quelle in einem einzigen Feld im Ziel vereinen. Die folgenden Attributzuordnung veranschaulicht, wie die Daten umstrukturiert werden.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToKafka",
"rule-action": "map-record-to-record",
"target-table-name": "CustomerData",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
},
"mapping-parameters": {
"partition-key-type": "attribute-name",
"partition-key-name": "CustomerName",
"exclude-columns": [
"firstname",
"lastname",
"homeaddress",
"homephone",
"workaddress",
"workphone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${lastname}, ${firstname}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "document",
"attribute-sub-type": "json",
"value": {
"Home": {
"Address": "${homeaddress}",
"Phone": "${homephone}"
},
"Work": {
"Address": "${workaddress}",
"Phone": "${workphone}"
}
}
}
]
}
}
]
}
```
Um einen konstanten Wert für festzulegen`partition-key`, geben Sie an`"partition-key-type: "constant"`, dass dadurch der Partitionswert auf gesetzt wird`constant`. So könnten Sie auf diese Weise beispielsweise erzwingen, dass alle Daten in einer einzigen Partition gespeichert werden. Die folgende Darstellung veranschaulicht dieses Konzept.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "1",
"rule-name": "TransformToKafka",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "Test",
"table-name": "Customer"
},
"mapping-parameters": {
"partition-key-type": "constant",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"attribute-name": "CustomerName",
"value": "${FirstName},${LastName}"
},
{
"attribute-name": "ContactDetails",
"value": {
"Home": {
"Address": "${HomeAddress}",
"Phone": "${HomePhone}"
},
"Work": {
"Address": "${WorkAddress}",
"Phone": "${WorkPhone}"
}
}
},
{
"attribute-name": "DateOfBirth",
"value": "${DateOfBirth}"
}
]
}
}
]
}
```
**Anmerkung**
Der `partition-key`-Wert für einen Steuerungsdatensatz, der für eine spezifische Tabelle bestimmt ist, lautet `TaskId.SchemaName.TableName`. Der `partition-key`-Wert für einen Steuerungsdatensatz, der für eine spezifische Aufgabe bestimmt ist, ist die `TaskId` des betreffenden Datensatzes. Wenn Sie einen `partition-key`-Wert in der Objektzuweisung angeben, hat dies keine Auswirkungen auf den `partition-key` für einen Steuerungsdatensatz.
Wann `attribute-name` in einer Tabellenzuordnungsregel auf festgelegt `partition-key-type` ist, müssen Sie angeben`partition-key-name`, was entweder auf eine Spalte aus der Quelltabelle oder auf eine in der Zuordnung definierte benutzerdefinierte Spalte verweisen muss. Zusätzlich `attribute-mappings` muss definiert werden, wie Quellspalten dem Ziel-Kafka-Thema zugeordnet werden.
### Replikation für mehrere Themen mithilfe der Objektzuweisung
Standardmäßig migrieren AWS DMS Aufgaben alle Quelldaten zu einem der folgenden Kafka-Themen:
+ Wie im Feld **Thema** des AWS DMS Zielendpunkts angegeben.
+ Wie von `kafka-default-topic` angegeben, wenn das Feld **Thema** des Zielendpunkts nicht gefüllt ist und die Kafka-Einstellung `auto.create.topics.enable` auf `true` gesetzt ist.
Bei AWS DMS Engine-Versionen 3.4.6 und höher können Sie das `kafka-target-topic` Attribut verwenden, um jede migrierte Quelltabelle einem separaten Thema zuzuordnen. Mit den folgenden Objektzuweisungsregeln werden beispielsweise die Quelltabellen `Customer` und `Address` zu den Kafka-Themen `customer_topic` bzw. `address_topic` migriert. AWS DMS Migriert gleichzeitig alle anderen Quelltabellen, einschließlich der `Bills` Tabelle im `Test` Schema, zu dem im Zielendpunkt angegebenen Thema.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "MapToKafka1",
"rule-action": "map-record-to-record",
"kafka-target-topic": "customer_topic",
"object-locator": {
"schema-name": "Test",
"table-name": "Customer"
},
"partition-key-type": "constant"
},
{
"rule-type": "object-mapping",
"rule-id": "3",
"rule-name": "MapToKafka2",
"rule-action": "map-record-to-record",
"kafka-target-topic": "address_topic",
"object-locator": {
"schema-name": "Test",
"table-name": "Address"
},
"partition-key-type": "constant"
},
{
"rule-type": "object-mapping",
"rule-id": "4",
"rule-name": "DefaultMapToKafka",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Bills"
}
}
]
}
```
Mithilfe der Kafka-Replikation für mehrere Themen können Sie Quelltabellen mit einer einzigen Replikationsaufgabe gruppieren und zu separaten Kafka-Themen migrieren.
### Nachrichtenformat für Apache Kafka
Die JSON-Ausgabe ist einfach eine Liste von Schlüssel-Wert-Paaren.
**RecordType**
Der Datensatztyp kann entweder für Daten oder zur Steuerung bestimmt sein. *Datensätze für Daten*repräsentieren die tatsächlichen Zeilen in der Quelle. *Steuerungsdatensätze* sind für wichtige Ereignisse im Stream bestimmt, z. B. einen Neustart der Aufgabe.
**Operation**
Mögliche Operationen für Datensätze sind `load`, `insert`, `update` oder `delete`.
Mögliche Operationen für Steuerungsdatensätze sind `create-table`, `rename-table`, `drop-table`, `change-columns`, `add-column`, `drop-column`, `rename-column` oder `column-type-change`.
**SchemaName**
Das Quellschema für den Datensatz. Dieses Feld kann für einen Steuerungsdatensatz leer sein.
**TableName**
Die Quelltabelle für den Datensatz. Dieses Feld kann für einen Steuerungsdatensatz leer sein.
**Zeitstempel**
Der Zeitstempel für den Zeitpunkt, an dem die JSON-Nachricht erstellt wurde. Das Feld ist mit dem ISO-8601-Format formatiert.
Das folgende Beispiel für eine JSON-Nachricht veranschaulicht eine Datentyp-Nachricht mit allen zusätzlichen Metadaten.
```
{
"data":{
"id":100000161,
"fname":"val61s",
"lname":"val61s",
"REGION":"val61s"
},
"metadata":{
"timestamp":"2019-10-31T22:53:59.721201Z",
"record-type":"data",
"operation":"insert",
"partition-key-type":"primary-key",
"partition-key-value":"sbtest.sbtest_x.100000161",
"schema-name":"sbtest",
"table-name":"sbtest_x",
"transaction-id":9324410911751,
"transaction-record-id":1,
"prev-transaction-id":9324410910341,
"prev-transaction-record-id":10,
"commit-timestamp":"2019-10-31T22:53:55.000000Z",
"stream-position":"mysql-bin-changelog.002171:36912271:0:36912333:9324410911751:mysql-bin-changelog.002171:36912209"
}
}
```
Das folgende Beispiel für eine JSON-Nachricht veranschaulicht eine Steuerungstyp-Nachricht.
```
{
"control":{
"table-def":{
"columns":{
"id":{
"type":"WSTRING",
"length":512,
"nullable":false
},
"fname":{
"type":"WSTRING",
"length":255,
"nullable":true
},
"lname":{
"type":"WSTRING",
"length":255,
"nullable":true
},
"REGION":{
"type":"WSTRING",
"length":1000,
"nullable":true
}
},
"primary-key":[
"id"
],
"collation-name":"latin1_swedish_ci"
}
},
"metadata":{
"timestamp":"2019-11-21T19:14:22.223792Z",
"record-type":"control",
"operation":"create-table",
"partition-key-type":"task-id",
"schema-name":"sbtest",
"table-name":"sbtest_t1"
}
}
```
# Verwendung eines Amazon OpenSearch Service-Clusters als Ziel für AWS Database Migration Service
Sie können AWS DMS es verwenden, um Daten zu Amazon OpenSearch Service (OpenSearch Service) zu migrieren. OpenSearch Service ist ein verwalteter Service, der die Bereitstellung, den Betrieb und die Skalierung eines OpenSearch Service-Clusters vereinfacht.
In OpenSearch Service arbeiten Sie mit Indizes und Dokumenten. Ein *Index* ist eine Sammlung von Dokumenten, und ein *Dokument* ist ein JSON-Objekt, das Skalarwerte, Arrays und andere Objekte enthält. OpenSearch stellt eine JSON-basierte Abfragesprache bereit, sodass Sie Daten in einem Index abfragen und die entsprechenden Dokumente abrufen können.
Wenn AWS DMS Indizes für einen Zielendpunkt für OpenSearch Service erstellt werden, wird für jede Tabelle vom Quellendpunkt aus ein Index erstellt. Die Kosten für die Erstellung eines OpenSearch Serviceindex hängen von mehreren Faktoren ab. Dies sind die Anzahl der erstellten Indizes, die Gesamtmenge der Daten in diesen Indizes und die geringe Menge an Metadaten, die für jedes Dokument OpenSearch gespeichert werden.
Konfigurieren Sie Ihren OpenSearch Service-Cluster mit Rechen- und Speicherressourcen, die für den Umfang Ihrer Migration geeignet sind. Wir empfehlen, dass Sie abhängig von der Replikationsaufgabe, die Sie verwenden möchten, die folgenden Faktoren berücksichtigen:
+ Erwägen Sie für einen vollständigen Datenladevorgang die Gesamtmenge der Daten, die Sie migrieren möchten, sowie auch die Übertragungsgeschwindigkeit.
+ Berücksichtigen Sie bei der Replikation laufender Änderungen die Häufigkeit der Updates und Ihre end-to-end Latenzanforderungen.
Konfigurieren Sie außerdem die Indexeinstellungen in Ihrem OpenSearch Cluster und achten Sie dabei genau auf die Anzahl der Dokumente.
**Aufgabeneinstellungen für vollständige Multithread-Ladevorgänge**
AWS DMS Unterstützt eine Multithread-Volllast zu einem OpenSearch Service-Zielcluster, um die Übertragungsgeschwindigkeit zu erhöhen. AWS DMS unterstützt dieses Multithreading mit Aufgabeneinstellungen, die Folgendes beinhalten:
+ `MaxFullLoadSubTasks` – Geben Sie diese Option an, um die maximale Anzahl von Quelltabellen festzulegen, die parallel geladen werden sollen. DMS lädt jede Tabelle mithilfe einer speziellen Unteraufgabe in den entsprechenden OpenSearch Service-Zielindex. Der Standardwert beträgt 8; der Maximalwert beträgt 49.
+ `ParallelLoadThreads`— Verwenden Sie diese Option, um die Anzahl der Threads anzugeben, die AWS DMS verwendet werden, um jede Tabelle in ihren OpenSearch Service-Zielindex zu laden. Der Höchstwert für ein OpenSearch Serviceziel ist 32. Sie können eine Erhöhung dieses Höchstwerts anfordern.
**Anmerkung**
Wenn Sie am Standardwert für `ParallelLoadThreads` (0) keine Änderung vornehmen, überträgt AWS DMS jeweils immer nur einen Datensatz. Dieser Ansatz belastet Ihren OpenSearch Service-Cluster übermäßig. Überprüfen Sie, dass für diese Option ein Wert 1 oder mehr angegeben wurde.
+ `ParallelLoadBufferSize`— Verwenden Sie diese Option, um die maximale Anzahl von Datensätzen anzugeben, die in dem Puffer gespeichert werden sollen, den die parallel Ladethreads verwenden, um Daten in das OpenSearch Serviceziel zu laden. Der Standardwert lautet 50. Die maximale Wert ist 1.000. Verwenden Sie diese Einstellung mit `ParallelLoadThreads`; `ParallelLoadBufferSize` ist nur gültig, wenn es mehr als einen Thread gibt.
Weitere Informationen darüber, wie DMS einen OpenSearch Service-Cluster mithilfe von Multithreading lädt, finden Sie im AWS Blogbeitrag [Scale Amazon OpenSearch Service](https://aws.amazon.com/blogs/database/scale-amazon-elasticsearch-service-for-aws-database-migration-service-migrations/) for Migrations. AWS Database Migration Service
**Aufgabeneinstellungen für Multithreaded CDC-Ladevorgänge**
Sie können die Leistung der Change Data Capture (CDC) für einen OpenSearch Service-Zielcluster verbessern, indem Sie Aufgabeneinstellungen verwenden, um das Verhalten des API-Aufrufs zu ändern. `PutRecords` Dazu können Sie die Anzahl der gleichzeitigen Threads, der Warteschlangen pro Thread und die Anzahl der Datensätze angeben, die in einem Puffer unter Verwendung von `ParallelApply*`-Aufgabeneinstellungen gespeichert werden sollen. Beispiel: Sie möchten eine CDC-Last ausführen und 32 Threads parallel anwenden. Außerdem möchten Sie auf 64 Warteschlangen pro Thread zugreifen, wobei 50 Datensätze pro Puffer gespeichert sind.
**Anmerkung**
Support für die Verwendung von `ParallelApply*` Aufgabeneinstellungen während der Übertragung von CDC zu Amazon OpenSearch Service-Zielendpunkten ist in den AWS DMS Versionen 3.4.0 und höher verfügbar.
AWS DMS Unterstützt die folgenden Aufgabeneinstellungen, um die Leistung des CDC zu fördern:
+ `ParallelApplyThreads`— Gibt die Anzahl gleichzeitiger Threads an, die während eines CDC-Ladevorgangs AWS DMS verwendet werden, um Datensätze an einen OpenSearch Service-Zielendpunkt weiterzuleiten. Der Standardwert ist Null (0) und der maximale Wert ist 32.
+ `ParallelApplyBufferSize`— Gibt die maximale Anzahl von Datensätzen an, die in jeder Pufferwarteschlange gespeichert werden sollen, damit gleichzeitige Threads während eines CDC-Ladevorgangs an einen OpenSearch Service-Zielendpunkt weitergeleitet werden. Der Standardwert ist 100 und der Höchstwert 1 000. Verwenden Sie diese Option, wenn `ParallelApplyThreads` mehrere Threads angibt.
+ `ParallelApplyQueuesPerThread`— Gibt die Anzahl der Warteschlangen an, auf die jeder Thread zugreift, um Datensätze aus den Warteschlangen zu entfernen und während des CDC einen Batchload für einen OpenSearch Service-Endpunkt zu generieren.
Wenn Sie `ParallelApply*`-Aufgabeneinstellungen verwenden, ist der `primary-key` der Tabelle der `partition-key-type`-Standardwert, nicht `schema-name.table-name`.
## Migration von einer relationalen Datenbanktabelle zu einem Serviceindex OpenSearch
AWS DMS unterstützt die Migration von Daten zu den skalaren Datentypen von OpenSearch Service. Wenn Sie von einer relationalen Datenbank wie Oracle oder MySQL zu OpenSearch Service migrieren, möchten Sie möglicherweise die Art und Weise, wie Sie diese Daten speichern, neu strukturieren.
AWS DMS unterstützt die folgenden skalaren OpenSearch Service-Datentypen:
+ Boolesch
+ Date
+ Gleitkommazahl
+ Int
+ Zeichenfolge
AWS DMS konvertiert Daten vom Typ Date in den Typ String. Sie können zum Auslegen dieser Datumsangaben eine benutzerdefinierte Zuweisung angeben.
AWS DMS unterstützt keine Migration von LOB-Datentypen.
## Voraussetzungen für die Verwendung von Amazon OpenSearch Service als Ziel für AWS Database Migration Service
Bevor Sie mit der Arbeit mit einer OpenSearch Service-Datenbank als Ziel für beginnen AWS DMS, stellen Sie sicher, dass Sie eine AWS Identity and Access Management (IAM-) Rolle erstellen. Diese Rolle sollte den AWS DMS Zugriff auf die OpenSearch Dienstindizes am Zielendpunkt ermöglichen. In der folgenden IAM-Richtlinie sind die Mindestzugriffsberechtigungen dargestellt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Die Rolle, die Sie für die Migration zu OpenSearch Service verwenden, muss über die folgenden Berechtigungen verfügen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"es:ESHttpDelete",
"es:ESHttpGet",
"es:ESHttpHead",
"es:ESHttpPost",
"es:ESHttpPut"
],
"Resource": "*"
}
]
}
```
------
Ersetzen Sie es im vorherigen Beispiel `region` durch die AWS Regionskennung, *`account-id`* durch Ihre AWS Konto-ID und `domain-name` durch den Namen Ihrer Amazon OpenSearch Service-Domain. Ein Beispiel ist `arn:aws:es:us-west-2:123456789012:domain/my-es-domain`.
## Endpunkteinstellungen bei Verwendung von OpenSearch Service als Ziel für AWS DMS
Sie können Endpunkteinstellungen verwenden, um Ihre OpenSearch Service-Zieldatenbank ähnlich wie bei der Verwendung zusätzlicher Verbindungsattribute zu konfigurieren. Sie geben die Einstellungen an, wenn Sie den Zielendpunkt mithilfe der AWS DMS Konsole oder mithilfe des `create-endpoint` Befehls in der mit der [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)`--elasticsearch-settings '{"EndpointSetting": "value", ...}'`JSON-Syntax erstellen.
Die folgende Tabelle zeigt die Endpunkteinstellungen, die Sie mit OpenSearch Service als Ziel verwenden können.
| Attributname | Zulässige Werte | Standardwert und Beschreibung |
| --- | --- | --- |
| `FullLoadErrorPercentage` | Eine positive Ganzzahl größer als 0, aber nicht größer als 100. | 10 – Bei einem vollständigen Ladevorgang bestimmt dieses Attribut den Schwellenwert von Fehlern, die zulässig sind, bevor die Aufgabe fehlschlägt. Nehmen wir beispielsweise an, dass 1.500 Zeilen am Quellendpunkt vorhanden sind und dieser Parameter auf 10 eingestellt ist. Dann schlägt die Aufgabe fehl AWS DMS , wenn beim Schreiben auf den Zielendpunkt mehr als 150 Fehler (10 Prozent der Zeilenanzahl) auftreten. |
| `ErrorRetryDuration` | Eine positive Ganzzahl größer als 0. | 300 — Wenn am Zielendpunkt ein Fehler auftritt, werden die AWS DMS Versuche so viele Sekunden lang wiederholt. Andernfalls schlägt die Aufgabe fehl. |
| `UseNewMappingType` | true oder false | `false`, aber um mit opensearch v2.x zu funktionieren, sollte es auf eingestellt sein. `true` |
## Einschränkungen bei der Verwendung von Amazon OpenSearch Service als Ziel für AWS Database Migration Service
Die folgenden Einschränkungen gelten, wenn Sie Amazon OpenSearch Service als Ziel verwenden:
+ OpenSearch Der Service verwendet dynamisches Mapping (auto Schätzung), um die Datentypen zu bestimmen, die für migrierte Daten verwendet werden sollen.
+ OpenSearch Der Service speichert jedes Dokument mit einer eindeutigen ID. Es folgt ein Beispiel für eine solche ID.
```
"_id": "D359F8B537F1888BC71FE20B3D79EAE6674BE7ACA9B645B0279C7015F6FF19FD"
```
Jede Dokument-ID ist 64 Bytes lang. Dies kann daher als Speicheranforderung vorausgesetzt werden. Wenn Sie beispielsweise 100.000 Zeilen aus einer AWS DMS Quelle migrieren, benötigt der resultierende OpenSearch Serviceindex Speicherplatz für weitere 6.400.000 Byte.
+ Mit OpenSearch Service können Sie keine Aktualisierungen an den Primärschlüsselattributen vornehmen. Diese Einschränkung ist wichtig, wenn Sie die laufende Replikation mit Change Data Capture (CDC) verwenden, da sie zu unerwünschten Daten im Ziel führen kann. Im CDC-Modus werden Primärschlüssel SHA256 Werten zugeordnet, die 32 Byte lang sind. Diese werden in für Menschen lesbare 64-Byte-Zeichenfolgen konvertiert und als Servicedokument verwendet. OpenSearch IDs
+ Wenn AWS DMS Elemente gefunden werden, die nicht migriert werden können, werden Fehlermeldungen in Amazon CloudWatch Logs geschrieben. Dieses Verhalten unterscheidet sich von dem anderer AWS DMS Zielendpunkte, die Fehler in eine Ausnahmetabelle schreiben.
+ AWS DMS unterstützt keine Verbindung zu einem Amazon ES-Cluster, für den Fine-Grained Access Control mit Masterbenutzer und Passwort aktiviert ist.
+ AWS DMS unterstützt OpenSearch Service Serverless nicht.
+ OpenSearch Der Dienst unterstützt das Schreiben von Daten in bereits bestehende Indizes nicht.
+ Die Einstellung für die Replikationsaufgabe `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` wird für die Verwendung mit einem OpenSearch Zielendpunkt nicht unterstützt.
+ Bei der Migration von Daten zu Amazon Elasticsearch mithilfe AWS DMS müssen die Quelldaten über einen Primärschlüssel oder eine eindeutige Kennungsspalte verfügen. Wenn die Quelldaten keinen Primärschlüssel oder keine eindeutige Kennung haben, müssen Sie einen mithilfe der define-primary-key Transformationsregel definieren.
## Zieldatentypen für Amazon OpenSearch Service
Bei der AWS DMS Migration von Daten aus heterogenen Datenbanken ordnet der Service Datentypen aus der Quelldatenbank Zwischendatentypen zu, die als Datentypen bezeichnet AWS DMS werden. Der Service ordnet dann die Zwischendatentypen den Zieldatentypen zu. Die folgende Tabelle zeigt jeden AWS DMS Datentyp und den Datentyp, dem er in OpenSearch Service zugeordnet ist.
| AWS DMS Datentyp | OpenSearch Datentyp des Dienstes |
| --- | --- |
| Boolesch | boolesch |
| Datum | Zeichenfolge |
| Zeit | date |
| Zeitstempel | date |
| INT4 | Ganzzahl |
| Real4 | float |
| UINT4 | Ganzzahl |
Weitere Informationen zu AWS DMS Datentypen finden Sie unter[Datentypen für den AWS Database Migration Service](CHAP_Reference.DataTypes.md).
# Amazon DocumentDB als Ziel für den AWS Database Migration Service verwenden
Informationen darüber, welche Versionen von Amazon DocumentDB (mit MongoDB-Kompatibilität) AWS DMS unterstützt werden, finden Sie unter. [Ziele für AWS DMS](CHAP_Introduction.Targets.md) Sie können mithilfe von AWS DMS Daten zu Amazon DocumentDB (mit MongoDB-Kompatibilität) migrieren – von jeder der Quelldaten-Engines aus, die AWS DMS unterstützt. Die Quell-Engine kann sich in einem AWS verwalteten Service wie Amazon RDS, Aurora oder Amazon S3 befinden. Die Engine kann sich außerdem in einer selbstverwalteten Datenbank befinden, wie beispielsweise MongoDB, das auf Amazon EC2 oder On-Premises ausgeführt wird.
Sie können AWS DMS damit Quelldaten in Amazon DocumentDB DocumentDB-Datenbanken, Sammlungen oder Dokumente replizieren.
**Anmerkung**
Wenn der Quellendpunkt MongoDB oder Amazon DocumentDB ist, führen Sie die Migration im **Dokumentmodus** aus.
MongoDB speichert Daten in einem binären JSON-Format (BSON). AWS DMS unterstützt alle BSON-Datentypen, die von Amazon DocumentDB unterstützt werden. Eine Liste dieser Datentypen finden Sie unter [Unterstützte APIs MongoDB-Operationen und Datentypen](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-apis.html) im *Amazon DocumentDB Developer Guide*.
Wenn der Quellendpunkt eine relationale Datenbank ist, AWS DMS ordnet er Datenbankobjekte Amazon DocumentDB wie folgt zu:
+ Eine relationale Datenbank oder ein Datenbankschema wird einer *Datenbank* in Amazon DocumentDB zugeordnet.
+ Tabellen innerhalb einer relationalen Datenbank werden *Sammlungen* in Amazon DocumentDB zugeordnet.
+ Datensätze in einer relationalen Tabelle werden *Dokumenten* in Amazon DocumentDB zugeordnet. Jedes Dokument wird aus den Daten des Quelldatensatzes erstellt.
Wenn der Quellendpunkt Amazon S3 ist, entsprechen die resultierenden Amazon-DocumentDB-Objekte den AWS DMS -Zuordnungsregeln für Amazon S3. Betrachten Sie beispielsweise die folgende URI:
```
s3://amzn-s3-demo-bucket/hr/employee
```
In diesem Fall AWS DMS ordnet die Objekte Amazon DocumentDB wie folgt `amzn-s3-demo-bucket` zu:
+ Der oberste URI-Teil (`hr`) wird einer Datenbank in Amazon DocumentDB zugeordnet.
+ Der nächste URI-Teil (`employee`) wird einer Sammlung in Amazon DocumentDB zugeordnet.
+ Jedes Objekt in `employee` wird einem Dokument in Amazon DocumentDB zugeordnet.
Weitere Informationen zu den Zuordnungsregeln für Amazon S3 finden Sie unter [Verwendung von Amazon S3 als Quelle für AWS DMS](CHAP_Source.S3.md).
**Amazon-DocumentDB-Endpunkteinstellungen**
In den AWS DMS Versionen 3.5.0 und höher können Sie die Leistung von Change Data Capture (CDC) für Amazon DocumentDB DocumentDB-Endpunkte verbessern, indem Sie die Aufgabeneinstellungen für parallel Threads und Massenoperationen optimieren. Dazu können Sie die Anzahl der gleichzeitigen Threads, der Warteschlangen pro Thread und die Anzahl der Datensätze angeben, die in einem Puffer unter Verwendung von `ParallelApply*`-Aufgabeneinstellungen gespeichert werden sollen. Beispiel: Sie möchten eine CDC-Last durchführen und 128 Threads parallel anwenden. Außerdem möchten Sie auf 64 Warteschlangen pro Thread zugreifen, wobei 50 Datensätze pro Puffer gespeichert sind.
Unterstützt die folgenden Aufgabeneinstellungen, um die CDC-Leistung zu fördern: AWS DMS
+ `ParallelApplyThreads`— Gibt die Anzahl der gleichzeitigen Threads an, die während eines CDC-Ladens AWS DMS verwendet werden, um Datensätze an einen Amazon DocumentDB DocumentDB-Zielendpunkt zu übertragen. Der Standardwert ist Null (0) und der maximale Wert ist 32.
+ `ParallelApplyBufferSize` – Gibt die maximale Anzahl von Datensätzen an, die in jeder Pufferwarteschlange für gleichzeitige Threads gespeichert werden sollen, um sie während einer CDC-Last an einen Amazon-DocumentDB-Zielendpunkt zu übertragen. Der Standardwert ist 100 und der Höchstwert 1 000. Verwenden Sie diese Option, wenn `ParallelApplyThreads` mehrere Threads angibt.
+ `ParallelApplyQueuesPerThread` – Gibt die Anzahl der Warteschlangen an, auf die jeder Thread zugreift, um Datensätze aus Warteschlangen zu entfernen und während CDC eine Stapellast für einen Amazon-DocumentDB-Endpunkt zu generieren. Der Standardwert ist 1. Der Höchstwert ist 512.
**Anmerkung**
Bei Amazon DocumentDB DocumentDB-Zielen kann die parallel CDC-Anwendung zu doppelten Schlüsselfehlern führen, oder bei Workloads, die sekundäre eindeutige Indizes verwenden oder eine strikte Reihenfolge der Änderungen erfordern, kann eine blockierte CDC-Anwendung auftreten. Verwenden Sie für diese Workloads die standardmäßige Single-Thread-CDC-Anwendungskonfiguration.
Weitere Informationen zur Arbeit mit Amazon DocumentDB als Ziel für AWS DMS finden Sie in den folgenden Abschnitten:
**Topics**
+ [Zuordnen von Daten von einer Quelle zu einem Amazon-DocumentDB-Ziel](#CHAP_Target.DocumentDB.data-mapping)
+ [Herstellen einer Verbindung mit elastischen Amazon-DocumentDB-Clustern als Ziel](#CHAP_Target.DocumentDB.data-mapping.elastic-cluster-connect)
+ [Laufende Replikation mit Amazon DocumentDB als Ziel](#CHAP_Target.DocumentDB.data-mapping.ongoing-replication)
+ [Einschränkungen bei Verwendung von Amazon DocumentDB als Ziel](#CHAP_Target.DocumentDB.limitations)
+ [Verwenden von Endpunkteinstellungen mit Amazon DocumentDB als Ziel](#CHAP_Target.DocumentDB.ECAs)
+ [Zieldatentypen für Amazon DocumentDB](#CHAP_Target.DocumentDB.datatypes)
**Anmerkung**
Eine step-by-step exemplarische Vorgehensweise für den Migrationsprozess finden Sie unter [Migration von MongoDB zu Amazon DocumentDB im Migrationshandbuch](https://docs.aws.amazon.com/dms/latest/sbs/CHAP_MongoDB2DocumentDB.html). AWS Database Migration Service Step-by-Step
## Zuordnen von Daten von einer Quelle zu einem Amazon-DocumentDB-Ziel
AWS DMS liest Datensätze vom Quellendpunkt und erstellt JSON-Dokumente auf der Grundlage der gelesenen Daten. Für jedes JSON-Dokument AWS DMS muss ein `_id` Feld bestimmt werden, das als eindeutiger Bezeichner dient. Anschließend wird das JSON-Dokument in eine Amazon-DocumentDB-Sammlung geschrieben, wobei das Feld `_id` als Primärschlüssel verwendet wird.
### Quelldaten, die eine einzelne Spalte darstellen
Wenn die Quelldaten aus einer einzelnen Spalte bestehen, müssen die Daten vom Typ Zeichenfolge sein. (Je nach Quell-Engine kann der tatsächliche Datentyp VARCHAR, NVARCHAR, TEXT, LOB, CLOB oder ähnlich lauten.) AWS DMS geht davon aus, dass es sich bei den Daten um ein gültiges JSON-Dokument handelt, und repliziert die Daten unverändert in Amazon DocumentDB.
Wenn das resultierende JSON-Dokument ein Feld mit dem Namen `_id` enthält, wird dieses Feld als eindeutige `_id` in Amazon DocumentDB verwendet.
Wenn das JSON-Dokument kein `_id`-Feld enthält, generiert Amazon DocumentDB automatisch einen `_id`-Wert.
### Quelldaten, die mehrere Spalten darstellen
Wenn die Quelldaten aus mehreren Spalten bestehen, wird aus all AWS DMS diesen Spalten ein JSON-Dokument erstellt. Gehen Sie wie folgt vor, um das `_id` Feld für das AWS DMS Dokument zu ermitteln:
+ Wenn der Name einer der Spalten `_id` lautet, dann werden die Daten in dieser Spalte als Ziel-`_id` verwendet.
+ Wenn es keine `_id` Spalte gibt, die Quelldaten jedoch einen Primärschlüssel oder einen eindeutigen Index haben, wird dieser Schlüssel oder Indexwert als `_id` Wert AWS DMS verwendet. Die Daten aus dem Primärschlüssel oder eindeutigen Index erscheinen auch als explizite Felder im JSON-Dokument.
+ Wenn keine `_id`-Spalte vorhanden ist und es keinen Primärschlüssel oder eindeutigen Index gibt, generiert Amazon DocumentDB automatisch einen `_id`-Wert.
### Zwingen eines Datentyps an den Zielendpunkt
AWS DMS kann Datenstrukturen ändern, wenn es auf einen Amazon DocumentDB DocumentDB-Zielendpunkt schreibt. Sie können diese Änderungen anfordern, indem Sie Spalten und Tabellen am Quellendpunkt umbenennen oder Transformationsregeln bereitstellen, die bei der Ausführung einer Aufgabe angewendet werden.
#### Verwenden eines verschachtelten JSON-Dokuments (json\$1prefix)
Um einen Datentyp zu erzwingen, können Sie dem Namen der Quellspalte das Präfix `json_` (d. h. `json_columnName`) entweder manuell oder mittels einer Transformation voranstellen. In diesem Fall wird die Spalte nicht als Zeichenfolgenfeld, sondern als verschachteltes JSON-Dokument innerhalb des Zieldokuments erstellt.
Angenommen, Sie möchten beispielsweise das folgende Dokument von einem MongoDB-Quellenendpunkt migrieren.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{"Home": {"Address": "Boston","Phone": "1111111"},"Work": { "Address": "Boston", "Phone": "2222222222"}}"
}
```
Wenn Sie keinen der Quelldatentypen erzwingen, wird das eingebettete `ContactDetails`-Dokument als Zeichenfolge migriert.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{\"Home\": {\"Address\": \"Boston\",\"Phone\": \"1111111\"},\"Work\": { \"Address\": \"Boston\", \"Phone\": \"2222222222\"}}"
}
```
Sie können jedoch eine Transformationsregel hinzufügen, um `ContactDetails` zu einem JSON-Objekt umzuwandeln. Angenommen, der ursprüngliche Name der Quellspalte ist `ContactDetails`. Um den Datentyp als verschachteltes JSON zu erzwingen, muss die Spalte am Quellendpunkt in „json\$1ContactDetails“ umbenannt werden, indem entweder der Quelle manuell das Präfix „\$1json\$1\$1“ hinzugefügt wird oder mithilfe von Transformationsregeln. Sie können beispielsweise die folgende Transformationsregel verwenden:
```
{
"rules": [
{
"rule-type": "transformation",
"rule-id": "1",
"rule-name": "1",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%",
"column-name": "ContactDetails"
},
"rule-action": "rename",
"value": "json_ContactDetails",
"old-value": null
}
]
}
```
AWS DMS repliziert das Feld wie folgt als verschachteltes JSON. ContactDetails
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": {
"Home": {
"Address": "Boston",
"Phone": "1111111111"
},
"Work": {
"Address": "Boston",
"Phone": "2222222222"
}
}
}
```
#### Verwenden eines JSON-Arrays (array\$1prefix)
Um einen Datentyp zu erzwingen, können Sie einem Spaltennamen das Präfix `array_` (d. h. `array_columnName`) entweder manuell oder mittels einer Transformation voranstellen. In diesem Fall AWS DMS betrachtet die Spalte als JSON-Array und erstellt sie als solches im Zieldokument.
Angenommen, Sie möchten das folgende Dokument von einem MongoDB-Quellenendpunkt migrieren.
```
{
"_id" : "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": ["Boston", "New York"],
"ContactPhoneNumbers": ["1111111111", "2222222222"]
}
```
Wenn Sie keinen der Quelldatentypen erzwingen, wird das eingebettete `ContactDetails`-Dokument als Zeichenfolge migriert.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": "[\"Boston\", \"New York\"]",
"ContactPhoneNumbers": "[\"1111111111\", \"2222222222\"]"
}
```
Sie können jedoch Transformationsregeln hinzufügen, um `ContactAddress` und `ContactPhoneNumbers` zu JSON-Arrays umzuwandeln, wie in der folgenden Tabelle veranschaulicht.
****
| Ursprünglicher Name der Quellspalte | Umbenannte Quellspalte |
| --- | --- |
| ContactAddress | array\$1ContactAddress |
| ContactPhoneNumbers | array\$1ContactPhoneNumbers |
AWS DMS repliziert `ContactAddress` und `ContactPhoneNumbers` wie folgt.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": [
"Boston",
"New York"
],
"ContactPhoneNumbers": [
"1111111111",
"2222222222"
]
}
```
### Herstellen einer Verbindung mit Amazon DocumentDB über TLS
Standardmäßig akzeptiert ein neu erstellter Amazon-DocumentDB-Cluster sichere Verbindungen nur mit Transport Layer Security (TLS). Wenn TLS aktiviert ist, erfordert jede Verbindung mit Amazon DocumentDB einen öffentlichen Schlüssel.
Sie können den öffentlichen Schlüssel für Amazon DocumentDB abrufen, indem Sie die Datei,`rds-combined-ca-bundle.pem`, aus einem AWS gehosteten Amazon S3 S3-Bucket herunterladen. Weitere Informationen zum Herunterladen dieser Datei finden Sie unter [Encrypting connections using TLS](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html) im *Entwicklerhandbuch für Amazon DocumentDB*.
Nachdem Sie diese PEM-Datei heruntergeladen haben, können Sie den darin enthaltenen öffentlichen Schlüssel AWS DMS wie unten beschrieben importieren.
#### AWS-Managementkonsole
**So importieren Sie die Datei mit dem öffentlichen Schlüssel (.pem)**
1. [Öffnen Sie die AWS DMS Konsole unter /dms. https://console.aws.amazon.com](https://console.aws.amazon.com/dms)
1. Wählen Sie im Navigationsbereich **Certificates** aus.
1. Wählen Sie **Import certificate (Zertifikat importieren)** aus und gehen Sie folgendermaßen vor:
+ Geben Sie für **Certificate Identifier (Zertifikat-ID)** einen eindeutigen Namen für das Zertifikat ein, z. B. `docdb-cert`.
+ Für **Import file (Datei importieren)** navigieren Sie zum Speicherort der .pem-Datei.
Wenn Sie die gewünschten Einstellungen vorgenommen haben, wählen Sie **Add new CA certificate (Neues CA-Zertifikat hinzufügen)** aus.
#### AWS CLI
Verwenden Sie den Befehl `aws dms import-certificate`, wie im folgenden Beispiel gezeigt.
```
aws dms import-certificate \
--certificate-identifier docdb-cert \
--certificate-pem file://./rds-combined-ca-bundle.pem
```
Wenn Sie einen AWS DMS Zielendpunkt erstellen, geben Sie die Zertifikats-ID an (z. B.`docdb-cert`). Legen Sie außerdem den SSL-Modus-Parameter auf `verify-full` fest.
## Herstellen einer Verbindung mit elastischen Amazon-DocumentDB-Clustern als Ziel
In den AWS DMS Versionen 3.4.7 und höher können Sie einen Amazon DocumentDB DocumentDB-Zielendpunkt als Elastic Cluster erstellen. Wenn Sie Ihren Zielendpunkt als elastischen Cluster erstellen, müssen Sie ein neues SSL-Zertifikat an Ihren Endpunkt im elastischen Amazon-DocumentDB-Cluster anfügen, da Ihr vorhandenes SSL-Zertifikat nicht funktioniert.
**So fügen Sie ein neues SSL-Zertifikat an Ihren Endpunkt im elastischen Amazon-DocumentDB-Cluster an**
1. Öffnen Sie in einem Browser die Datei [ https://www.amazontrust.com/repository/SFSRootCAG2.pem](https://www.amazontrust.com/repository/SFSRootCAG2.pem) und speichern Sie den Inhalt beispielsweise in einer `.pem` Datei mit einem eindeutigen Dateinamen. `SFSRootCAG2.pem` Dies ist die Zertifikatsdatei, die Sie in den nachfolgenden Schritten importieren müssen.
1. Erstellen Sie den Endpunkt im elastischen Cluster und legen Sie die folgenden Optionen fest:
1. Wählen Sie unter **Endpunktkonfiguration** die Option **Neues CA-Zertifikat hinzufügen** aus.
1. Geben Sie für **Zertifikat-ID** **SFSRootCAG2.pem** ein.
1. Wählen Sie unter **Zertifikatdatei importieren** die Option **Datei auswählen** und navigieren Sie zur Datei `SFSRootCAG2.pem`, die Sie zuvor heruntergeladen haben.
1. Wählen Sie die heruntergeladene Datei `SFSRootCAG2.pem` aus und öffnen Sie sie.
1. Wählen Sie **Import certificate (Zertifikat importieren)**.
1. **Wählen Sie in der Dropdownliste Zertifikat auswählen** **die Datei .pem aus SFSRootCAG2.**
Das neue SSL-Zertifikat aus der heruntergeladenen Datei `SFSRootCAG2.pem` ist jetzt an Ihren Endpunkt im elastischen Amazon-DocumentDB-Cluster angehängt.
## Laufende Replikation mit Amazon DocumentDB als Ziel
Wenn die laufende Replikation (Erfassung von Datenänderungen, CDC) für Amazon DocumentDB als Ziel aktiviert ist, bieten die AWS DMS -Versionen 3.5.0 und höher eine zwanzigfache Leistungsverbesserung gegenüber früheren Versionen. In früheren Versionen, in denen bis zu 250 Datensätze pro Sekunde AWS DMS verarbeitet wurden, werden AWS DMS jetzt effizient über 5000 Datensätze pro Sekunde verarbeitet. AWS DMS stellt außerdem sicher, dass Dokumente in Amazon DocumentDB mit der Quelle synchron bleiben. Wenn ein Quelldatensatz erstellt oder aktualisiert wird, AWS DMS müssen Sie zunächst ermitteln, welcher Amazon DocumentDB DocumentDB-Datensatz von den folgenden Aktionen betroffen ist:
+ Wenn der Quelldatensatz über eine Spalte mit dem Namen `_id` verfügt, bestimmt der Wert dieser Spalte den entsprechenden `_id`-Wert in der Amazon-DocumentDB-Sammlung.
+ Wenn es keine `_id` Spalte gibt, aber die Quelldaten einen Primärschlüssel oder einen eindeutigen Index haben, wird dieser Schlüssel oder Indexwert als `_id` für die Amazon DocumentDB-Sammlung AWS DMS verwendet.
+ Wenn der Quelldatensatz keine `_id` Spalte, keinen Primärschlüssel oder keinen eindeutigen Index hat, ordnet er alle Quellspalten den entsprechenden Feldern in der Amazon DocumentDB-Sammlung zu. AWS DMS
Wenn ein neuer Quelldatensatz erstellt wird, AWS DMS schreibt ein entsprechendes Dokument in Amazon DocumentDB. Wenn ein vorhandener Quelldatensatz aktualisiert wird, AWS DMS werden die entsprechenden Felder im Zieldokument in Amazon DocumentDB aktualisiert. Alle Felder, die zwar im Zieldokument, aber nicht im Quelldatensatz vorhanden sind, bleiben unberührt.
Wenn ein Quelldatensatz gelöscht wird, AWS DMS wird das entsprechende Dokument aus Amazon DocumentDB gelöscht.
### Strukturelle Änderungen (DDL) an der Quelle
Bei der laufenden Replikation werden alle Änderungen an Quelldatenstrukturen (z. B. Tabellen, Spalten usw.) an ihre Entsprechungen in Amazon DocumentDB weitergegeben. In relationalen Datenbanken werden diese Änderungen durch DDL-Anweisungen (Data Definition Language) eingeleitet. In der folgenden Tabelle können Sie sehen AWS DMS , wie diese Änderungen an Amazon DocumentDB weitergegeben werden.
****
| DDL an Quelle | Auswirkung auf das Amazon-DocumentDB-Ziel |
| --- | --- |
| CREATE TABLE | Erstellt eine leere Sammlung. |
| Anweisung, die eine Tabelle umbenennt (RENAME TABLE, ALTER TABLE...RENAME und Ähnliches) | Benennt die Sammlung um. |
| TRUNCATE TABLE | Entfernt alle Dokumente aus der Sammlung, aber nur, wenn HandleSourceTableTruncated true ist. Weitere Informationen finden Sie unter [Aufgabeneinstellungen für den Umgang mit der DDL-Änderungsverarbeitung](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| DROP TABLE | Löscht die Sammlung, aber nur, wenn HandleSourceTableDropped true ist. Weitere Informationen finden Sie unter [Aufgabeneinstellungen für den Umgang mit der DDL-Änderungsverarbeitung](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| Anweisung, die einer Tabelle eine Spalte hinzufügt (ALTER TABLE...ADD und Ähnliches) | Die DDL-Anweisung wird ignoriert und eine Warnung ausgegeben. Wenn der erste INSERT an der Quelle ausgeführt wird, wird das neue Feld dem Zieldokument hinzugefügt. |
| ALTER TABLE...RENAME COLUMN | Die DDL-Anweisung wird ignoriert und eine Warnung ausgegeben. Wenn der erste INSERT an der Quelle ausgeführt wird, wird das neu benannte Feld dem Zieldokument hinzugefügt. |
| ALTER TABLE...DROP COLUMN | Die DDL-Anweisung wird ignoriert und eine Warnung ausgegeben. |
| Anweisung, die den Datentyp der Spalte ändert (ALTER COLUMN...MODIFY und Ähnliches) | Die DDL-Anweisung wird ignoriert und eine Warnung ausgegeben. Wenn der erste INSERT an der Quelle mit dem neuen Datentyp ausgeführt wird, wird das Zieldokument mit einem Feld dieses neuen Datentyps erstellt. |
## Einschränkungen bei Verwendung von Amazon DocumentDB als Ziel
Die folgenden Einschränkungen gelten bei der Verwendung von Amazon DocumentDB als Ziel für AWS DMS:
+ In Amazon DocumentDB dürfen Namen für Sammlungen nicht das Dollarzeichen (\$1) enthalten. Darüber hinaus dürfen Datenbanknamen keine Unicode-Zeichen enthalten.
+ AWS DMS unterstützt nicht das Zusammenführen mehrerer Quelltabellen zu einer einzigen Amazon DocumentDB-Sammlung.
+ Wenn Änderungen aus einer Quelltabelle AWS DMS verarbeitet werden, die keinen Primärschlüssel hat, werden alle LOB-Spalten in dieser Tabelle ignoriert.
+ Wenn die Option **Change table (Änderungstabelle)** aktiviert ist und AWS DMS auf eine Quellspalte mit dem Namen "*\$1id*" trifft, dann erscheint diese Spalte als "*\$1\$1id*" (zwei Unterstriche) in der Änderungstabelle.
+ Wenn Sie Oracle als Quellendpunkt wählen, muss für die Oracle-Quelle die vollständige ergänzende Protokollierung aktiviert sein. Andernfalls werden, wenn es an der Quelle Spalten gibt, die nicht geändert wurden, die Daten als Nullwerte in Amazon DocumentDB geladen.
+ Die Einstellung `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` für die Replikationsaufgabe wird nicht für die Verwendung mit einem DocumentDB-Zielendpunkt unterstützt.
+ MongoDB-Sammlungen mit Obergrenzen werden in Amazon DocumentDB nicht unterstützt. Migriert solche Objekte jedoch AWS DMS automatisch als Sammlungen ohne Obergrenzen auf die Ziel-DocumentDB.
+ Die parallele CDC-Anwendung auf Amazon DocumentDB DocumentDB-Ziele kann zu doppelten Schlüsselfehlern führen, oder bei Workloads, die sekundäre eindeutige Indizes verwenden oder eine strikte Reihenfolge der Änderungen erfordern, können blockierte CDC-Anwendungen auftreten. Verwenden Sie für solche Workloads die standardmäßige CDC-Anwendungskonfiguration mit einem Thread.
## Verwenden von Endpunkteinstellungen mit Amazon DocumentDB als Ziel
Sie können Endpunkteinstellungen, ähnlich wie zusätzliche Verbindungsattribute, zum Konfigurieren Ihrer Amazon-DocumentDB-Zieldatenbank verwenden. Sie geben die Einstellungen an, wenn Sie den Zielendpunkt mithilfe der AWS DMS Konsole oder mithilfe des `create-endpoint` Befehls in [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), mit der `--doc-db-settings '{"EndpointSetting": "value", ...}'` JSON-Syntax erstellen.
Die folgende Tabelle zeigt die Endpunkteinstellungen, die Sie mit Amazon DocumentDB als Ziel verwenden können.
| Attributname | Zulässige Werte | Standardwert und Beschreibung |
| --- | --- | --- |
| `replicateShardCollections` | boolesch `true` `false` | Wann `true` festgelegt ist, hat diese Endpunkteinstellung die folgenden Auswirkungen und beinhaltet die folgenden Einschränkungen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_Target.DocumentDB.html) |
## Zieldatentypen für Amazon DocumentDB
In der folgenden Tabelle finden Sie die Amazon DocumentDB DocumentDB-Zieldatentypen, die bei der Verwendung von AWS DMS unterstützt werden, sowie die Standardzuweisung von AWS DMS-Datentypen. Weitere Informationen zu AWS DMS-Datentypen finden Sie unter. [Datentypen für den AWS Database Migration Service](CHAP_Reference.DataTypes.md)
| AWS DMS-Datentyp | Amazon-DocumentDB-Datentyp |
| --- | --- |
| BOOLEAN | Boolesch |
| BYTES | Binäre Daten |
| DATE | Date |
| TIME | Zeichenfolge () UTF8 |
| DATETIME | Date |
| INT1 | 32-Bit-Ganzzahl |
| INT2 | 32-Bit-Ganzzahl |
| INT4 | 32-Bit-Ganzzahl |
| INT8 | 64-Bit-Ganzzahl |
| NUMERIC | Zeichenfolge (UTF8) |
| REAL4 | Double |
| REAL8 | Double |
| STRING | Wenn die Daten als JSON erkannt werden, werden sie als Dokument zu Amazon DocumentDB AWS DMS migriert. Andernfalls werden die Daten String () zugeordnet. UTF8 |
| UINT1 | 32-Bit-Ganzzahl |
| UINT2 | 32-Bit-Ganzzahl |
| UINT4 | 64-Bit-Ganzzahl |
| UINT8 | Zeichenfolge () UTF8 |
| WSTRING | Wenn die Daten als JSON erkannt werden, werden sie als Dokument zu Amazon DocumentDB AWS DMS migriert. Andernfalls werden die Daten String () zugeordnet. UTF8 |
| BLOB | Binär |
| CLOB | Wenn die Daten als JSON erkannt werden, werden sie als Dokument zu Amazon DocumentDB AWS DMS migriert. Andernfalls werden die Daten String () zugeordnet. UTF8 |
| NCLOB | Wenn die Daten als JSON erkannt werden, werden sie als Dokument zu Amazon DocumentDB AWS DMS migriert. Andernfalls werden die Daten String () zugeordnet. UTF8 |
# Verwendung von Amazon Neptune als Ziel für AWS Database Migration Service
Amazon Neptune ist ein schneller, zuverlässiger, vollständig verwalteter Graph-Datenbankservice, mit dem es ganz einfach ist, Anwendungen zu erstellen und auszuführen, die mit stark verbundenen Datensätzen arbeiten. Den Kern von Neptune bildet eine speziell entwickelte, hochleistungsfähige Graphdatenbank-Engine. Diese Engine ist für die Speicherung von Milliarden von Beziehungen und die Abfrage des Graphen mit einer Latenzzeit von Millisekunden optimiert. Neptune unterstützt die beliebten Graph-Abfragesprachen Apache TinkerPop Gremlin und SPARQL des W3C. Weitere Informationen zu Amazon Neptune finden Sie unter [Was ist Amazon Neptune?](https://docs.aws.amazon.com/neptune/latest/userguide/intro.html) im *Amazon-Neptune-Benutzerhandbuch*.
Ohne eine Graphdatenbank wie Neptune modellieren Sie wahrscheinlich hoch verbundene Daten in einer relationalen Datenbank. Da die Daten über potenziell dynamische Verbindungen verfügen, müssen Anwendungen, die solche Datenquellen verwenden, verbundene Datenabfragen in SQL modellieren. Dieser Ansatz erfordert, dass Sie einen zusätzlichen Layer schreiben, um Graph-Abfragen in SQL zu konvertieren. Außerdem haben relationale Datenbanken eine Schemastarrheit. Änderungen am Schema an modelländernden Verbindungen erfordern Ausfallzeiten und zusätzliche Wartung der Abfragekonvertierung, um das neue Schema zu unterstützen. Die Abfrageleistung ist auch eine weitere große Einschränkung, die beim Entwerfen Ihrer Anwendungen berücksichtigt werden muss.
Graph-Datenbanken können solche Situationen erheblich vereinfachen. Frei von einem Schema, einem Rich Graph Query Layer (Gremlin oder SPARQL) und Indizes, die für Graph-Abfragen optimiert sind, erhöhen die Flexibilität und Leistung. Die Graphdatenbank von Amazon Neptune verfügt auch über Enterprise-Features wie Verschlüsselung im Ruhezustand, eine sichere Autorisierungsebene, Standardsicherungen, Multi-AZ-Unterstützung, Unterstützung für Lesereplikate und mehr.
Mithilfe können Sie relationale Daten AWS DMS, die einen stark verbundenen Graphen modellieren, von einem DMS-Quellendpunkt für jede unterstützte SQL-Datenbank zu einem Neptune-Zielendpunkt migrieren.
Weitere Informationen finden Sie im Folgenden.
**Topics**
+ [Übersicht über die Migration zu Amazon Neptune als Ziel](#CHAP_Target.Neptune.MigrationOverview)
+ [Angeben von Endpunkteinstellungen für Amazon Neptune als Ziel](#CHAP_Target.Neptune.EndpointSettings)
+ [Erstellen einer IAM-Servicerolle für den Zugriff auf Amazon Neptune als Ziel](#CHAP_Target.Neptune.ServiceRole)
+ [Angeben von Graph-Zuordnungsregeln mit Gremlin und R2RML für Amazon Neptune als Ziel](#CHAP_Target.Neptune.GraphMapping)
+ [Datentypen für die Migration von Gremlin und R2RML zu Amazon Neptune als Ziel](#CHAP_Target.Neptune.DataTypes)
+ [Einschränkungen bei der Verwendung von Amazon Neptune als Ziel](#CHAP_Target.Neptune.Limitations)
## Übersicht über die Migration zu Amazon Neptune als Ziel
Bevor Sie eine Migration zu einem Neptune-Ziel starten, erstellen Sie die folgenden Ressourcen in Ihrem AWS Konto:
+ Einen Neptune-Cluster für den Zielendpunkt.
+ Eine relationale SQL-Datenbank, die von AWS DMS for the Source Endpoint unterstützt wird.
+ Einen Amazon-S3-Bucket für den Zielendpunkt. Erstellen Sie diesen S3-Bucket in derselben AWS Region wie Ihr Neptun-Cluster. AWS DMS verwendet diesen S3-Bucket als Zwischenspeicher für die Zieldaten, die er massenweise in die Neptune-Datenbank lädt. Weitere Informationen zum Erstellen eines S3-Buckets finden Sie unter [Erstellen von Buckets](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html) im *Benutzerhandbuch für Amazon Simple Storage Service*.
+ Einen Virtual Private Cloud (VPC)-Endpunkt für S3 in derselben VPC wie der Neptune-Cluster.
+ Eine AWS Identity and Access Management (IAM-) Rolle, die eine IAM-Richtlinie beinhaltet. In dieser Richtlinie sollten die Berechtigungen `ListObject`, `GetObject`, `PutObject` und `DeleteObject` für den S3-Bucket für den Zielendpunkt angegeben werden. Diese Rolle wird sowohl von Neptune als auch von Neptune mit IAM-Zugriff AWS DMS sowohl auf den Ziel-S3-Bucket als auch auf die Neptune-Datenbank übernommen. Weitere Informationen finden Sie unter [Erstellen einer IAM-Servicerolle für den Zugriff auf Amazon Neptune als Ziel](#CHAP_Target.Neptune.ServiceRole).
Nachdem Sie über diese Ressourcen verfügen, sind die Einrichtung und das Starten einer Migration zu einem Neptune-Ziel ähnlich wie bei einer Volllastmigration unter Verwendung der Konsole oder der DMS-API. Eine Migration zu einem Neptune-Ziel erfordert jedoch einige spezifische Schritte.
**Um eine AWS DMS relationale Datenbank zu Neptune zu migrieren**
1. Erstellen Sie eine Replikations-Instance wie unter [Erstellen einer Replikations-Instance](CHAP_ReplicationInstance.Creating.md) beschrieben.
1. Erstellen und testen Sie eine relationale SQL-Datenbank, die von AWS DMS für den Quellendpunkt unterstützt wird.
1. Erstellen und testen Sie den Zielendpunkt für Ihre Neptune-Datenbank.
Um den Zielendpunkt mit der Neptune-Datenbank zu verbinden, geben Sie den Servernamen für den Neptune-Cluster-Endpunkt oder den Neptune-Writer-Instance-Endpunkt an. Geben Sie außerdem den S3-Bucket-Ordner an, in AWS DMS dem die Zwischendateien für das Massenladen in die Neptune-Datenbank gespeichert werden sollen.
AWS DMS Speichert während der Migration alle migrierten Zieldaten in diesem S3-Bucket-Ordner bis zu einer von Ihnen angegebenen maximalen Dateigröße. Wenn dieser Dateispeicher diese maximale Größe erreicht, werden die gespeicherten S3-Daten AWS DMS massenweise in die Zieldatenbank geladen. Der Ordner wird gelöscht, um die Speicherung zusätzlicher Zieldaten für das nachfolgende Laden in die Zieldatenbank zu ermöglichen. Weitere Informationen zum Festlegen dieser Einstellungen finden Sie unter [Angeben von Endpunkteinstellungen für Amazon Neptune als Ziel](#CHAP_Target.Neptune.EndpointSettings).
1. Erstellen Sie eine Volllast-Replikationsaufgabe mit den Ressourcen, die in den Schritten 1 bis 3 erstellt wurden, und gehen Sie wie folgt vor:
1. Verwenden Sie die Aufgaben-Tabellenzuordnung wie gewohnt, um bestimmte Quellschemas, Tabellen und Ansichten zu identifizieren, die mit entsprechenden Auswahl- und Transformationsregeln aus Ihrer relationalen Datenbank migriert werden sollen. Weitere Informationen finden Sie unter [Verwenden der Tabellenzuweisung zum Angeben von Aufgabeneinstellungen](CHAP_Tasks.CustomizingTasks.TableMapping.md).
1. Geben Sie Zielzuordnungen an, indem Sie eine der folgenden Optionen auswählen, um Zuordnungsregeln aus Quelltabellen und Ansichten für den Neptune-Zieldatenbank-Graphen anzugeben:
+ Gremlin JSON – Informationen zur Verwendung von Gremlin JSON zum Laden einer Neptune-Datenbank finden Sie unter [Gremlin-Format zum Laden von Daten](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) im *Amazon-Neptune-Benutzerhandbuch*.
+ SPARQL RDB to Resource Description Framework Mapping Language (R2RML) – Weitere Informationen zur Verwendung von SPARQL R2RML finden Sie in der W3C-Spezifikation [R2RML: RDB to RDF Mapping Language](https://www.w3.org/TR/r2rml/).
1. Führen Sie eine der folgenden Aktionen aus:
+ Geben Sie in der AWS DMS Konsole mithilfe der **Regeln für die Grafikzuweisung auf der **Aufgabenseite Datenbankmigration erstellen** Optionen für die Grafikzuordnung** an.
+ Geben Sie diese Optionen mithilfe der AWS DMS API mithilfe des `TaskData` Anforderungsparameters des `CreateReplicationTask` API-Aufrufs an.
Weitere Informationen und Beispiele für die Verwendung von Gremlin JSON und SPARQL R2RML zum Angeben von Graph-Zuordnungsregeln finden Sie unter [Angeben von Graph-Zuordnungsregeln mit Gremlin und R2RML für Amazon Neptune als Ziel](#CHAP_Target.Neptune.GraphMapping).
1. Starten Sie die Replikation für Ihre Migrationsaufgabe.
## Angeben von Endpunkteinstellungen für Amazon Neptune als Ziel
Um einen Zielendpunkt zu erstellen oder zu ändern, können Sie die Konsole oder die `CreateEndpoint`- oder `ModifyEndpoint`-API-Vorgänge verwenden.
Geben Sie für ein Neptune-Ziel in der AWS DMS Konsole auf der Seite **Endpoint erstellen oder Endpoint **modifizieren** auf der Konsolenseite Endpunktspezifische** **Einstellungen** an. Geben Sie für `CreateEndpoint` und `ModifyEndpoint` Anforderungsparameter für die `NeptuneSettings`-Option an. Das folgende Beispiel zeigt, wie dies über die Befehlszeilenschnittstelle (CLI) möglich ist.
```
dms create-endpoint --endpoint-identifier my-neptune-target-endpoint
--endpoint-type target --engine-name neptune
--server-name my-neptune-db.cluster-cspckvklbvgf.us-east-1.neptune.amazonaws.com
--port 8192
--neptune-settings
'{"ServiceAccessRoleArn":"arn:aws:iam::123456789012:role/myNeptuneRole",
"S3BucketName":"amzn-s3-demo-bucket",
"S3BucketFolder":"amzn-s3-demo-bucket-folder",
"ErrorRetryDuration":57,
"MaxFileSize":100,
"MaxRetryCount": 10,
"IAMAuthEnabled":false}‘
```
Hier gibt die CLI-Option `--server-name` den Servernamen für den Neptune-Cluster-Writer-Endpunkt an. Sie können auch den Servernamen für einen Neptune-Writer-Instance-Endpunkt angeben.
Die `--neptune-settings`-Option fordert Parameter wie folgt an:
+ `ServiceAccessRoleArn` – (Erforderlich) Der Amazon-Ressourcenname (ARN) der Servicerolle, die Sie für den Neptune-Zielendpunkt erstellt haben. Weitere Informationen finden Sie unter [Erstellen einer IAM-Servicerolle für den Zugriff auf Amazon Neptune als Ziel](#CHAP_Target.Neptune.ServiceRole).
+ `S3BucketName` – (Erforderlich) Der Name des S3-Buckets, in dem DMS migrierte Diagrammdaten vorübergehend in CSV-Dateien speichern kann, bevor sie in einem Massenladevorgang in die Neptune-Zieldatenbank geladen werden. DMS ordnet die SQL-Quelldaten Diagrammdaten zu, bevor sie in diesen CSV-Dateien gespeichert werden.
+ `S3BucketFolder` – (Erforderlich) Ein Ordnerpfad, in dem DMS migrierte Diagrammdaten in dem S3-Bucket speichern soll, der durch `S3BucketName` angegeben wird.
+ `ErrorRetryDuration` – (Optional) Die Anzahl der Millisekunden, die DMS auf einen erneuten Massenladevorgang migrierter Diagrammdaten in die Neptune-Zieldatenbank warten soll, bevor ein Fehler ausgelöst wird. Der Standardwert ist 250.
+ `MaxFileSize` – (Optional) Die maximale Größe der migrierten Diagrammdaten in KB, die in einer CSV-Datei gespeichert werden, bevor DMS eine Massenladung der Daten in die Neptune-Zieldatenbank vornimmt. Der Standardwert ist 1.048.576 KB (1 GB) Wenn dies erfolgreich ist, löscht DMS den Bucket und ist bereit, den nächsten Stapel der migrierten Diagrammdaten zu speichern.
+ `MaxRetryCount` – (Optional) Gibt an, wie oft DMS eine Massenladung migrierter Diagrammdaten in die Neptune-Zieldatenbank erneut versucht, bevor ein Fehler ausgelöst wird. Der Standardwert ist 5.
+ `IAMAuthEnabled` – (Optional) Wenn Sie die IAM-Autorisierung für diesen Endpunkt aktivieren möchten, legen Sie für diesen Parameter `true` fest und fügen Sie das entsprechende IAM-Richtliniendokument zu Ihrer Servicerolle hinzu, die in `ServiceAccessRoleArn` angegeben ist. Der Standardwert ist `false`.
## Erstellen einer IAM-Servicerolle für den Zugriff auf Amazon Neptune als Ziel
Um auf Neptune als Ziel zuzugreifen, erstellen Sie mithilfe von IAM eine Dienstrolle. Fügen Sie dieser Rolle abhängig von Ihrer Neptune-Endpunktkonfiguration einige oder alle folgenden IAM-Richtlinien- und Vertrauensdokumente an. Wenn Sie den Neptune-Endpunkt erstellen, geben Sie den ARN dieser Servicerolle an. Dadurch kann AWS DMS Amazon Neptune Berechtigungen für den Zugriff auf Neptune und den zugehörigen Amazon S3 S3-Bucket annehmen.
Wenn Sie in Ihrer Neptune-Endpunktkonfiguration den Parameter `IAMAuthEnabled` in `NeptuneSettings` auf `true`festlegen, fügen Sie Ihrer Servicerolle eine IAM-Richtlinie wie die folgende hinzu. Wenn Sie `IAMAuthEnabled` auf `false` festlegen, können Sie diese Richtlinie ignorieren.
```
// Policy to access Neptune
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "neptune-db:*",
"Resource": "arn:aws:neptune-db:us-east-1:123456789012:cluster-CLG7H7FHK54AZGHEH6MNS55JKM/*"
}
]
}
```
Die vorangehende IAM-Richtlinie ermöglicht vollen Zugriff auf den von `Resource` angegebenen Neptune-Ziel-Cluster.
Fügen Sie Ihrer Dienstrolle eine IAM-Richtlinie wie die folgende an. Diese Richtlinie ermöglicht es DMS, migrierte Diagrammdaten vorübergehend im S3-Bucket zu speichern, den Sie für den Massenladevorgang in die Neptune-Zieldatenbank erstellt haben.
```
//Policy to access S3 bucket
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ListObjectsInBucket0",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": ["s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/"
]
},
{
"Sid": "ListObjectsInBucket1",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/"
]
}
]
}
```
Die vorangehende IAM-Richtlinie ermöglicht es Ihrem Konto, den Inhalt des S3-Buckets (`arn:aws:s3:::amzn-s3-demo-bucket`) abzufragen, der für Ihr Neptune-Ziel erstellt wurde. Außerdem kann Ihr Konto vollständig mit dem Inhalt aller Bucket-Dateien und Ordner arbeiten (`arn:aws:s3:::amzn-s3-demo-bucket/`).
Bearbeiten Sie die Vertrauensstellung und fügen Sie Ihrer Servicerolle die folgende IAM-Rolle hinzu, damit AWS DMS sowohl der Amazon Neptune Neptune-Datenbankdienst die Rolle übernehmen können.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Sid": "neptune",
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Weitere Informationen zum Angeben dieser Servicerolle für den Neptune-Zielendpunkt finden Sie unter [Angeben von Endpunkteinstellungen für Amazon Neptune als Ziel](#CHAP_Target.Neptune.EndpointSettings).
## Angeben von Graph-Zuordnungsregeln mit Gremlin und R2RML für Amazon Neptune als Ziel
Die von Ihnen erstellten Graph-Zuordnungsregeln geben an, wie Daten, die aus einer relationalen SQL-Datenbankquelle extrahiert werden, in ein Neptune-Datenbank-Cluster-Ziel geladen werden. Das Format dieser Zuordnungsregeln unterscheidet sich je nachdem, ob die Regeln für das Laden von Eigenschaftsdiagrammdaten mithilfe von Apache TinkerPop Gremlin oder Resource Description Framework (RDF) -Daten mithilfe von R2RML gelten. Im Folgenden finden Sie Informationen zu diesen Formaten und wo Sie mehr darüber erfahren können.
Sie können diese Zuordnungsregeln angeben, wenn Sie die Migrationsaufgabe mithilfe der Konsole oder der DMS-API erstellen.
Geben Sie mithilfe der **Graph-Zuordnungsregeln** auf der Seite **Datenbankmigration erstellen** diese Zuordnungsregeln an. In **Graph-Zuordnungsregeln** können Sie die Zuordnungsregeln direkt mit dem bereitgestellten Editor eingeben und bearbeiten. Sie können auch nach einer Datei suchen, die die Zuordnungsregeln im entsprechenden Graph-Zuordnungsformat enthält.
Geben Sie mithilfe der API diese Optionen über den `TaskData`-Anforderungsparameter des `CreateReplicationTask`-API-Aufrufs an. Legen Sie `TaskData` auf den Pfad einer Datei fest, die die Zuordnungsregeln im entsprechenden Graph-Zuordnungsformat enthält.
### Graph-Zuordnungsregeln zum Generieren von Eigenschafts-Graph-Daten mit Gremlin
Verwenden Sie Gremlin zum Generieren der Eigenschafts-Graph-Daten an, geben Sie ein JSON-Objekt mit einer Zuordnungsregel für jede Graph-Entität ein, die aus Quelldaten generiert werden soll. Das Format dieses JSON-Objekts ist speziell für einen Masseladevorgang von Amazon Neptune definiert. Die folgende Vorlage zeigt, wie die einzelnen Regeln in diesem Objekt aussehen:
```
{
"rules": [
{
"rule_id": "(an identifier for this rule)",
"rule_name": "(a name for this rule)",
"table_name": "(the name of the table or view being loaded)",
"vertex_definitions": [
{
"vertex_id_template": "{col1}",
"vertex_label": "(the vertex to create)",
"vertex_definition_id": "(an identifier for this vertex)",
"vertex_properties": [
{
"property_name": "(name of the property)",
"property_value_template": "{col2} or text",
"property_value_type": "(data type of the property)"
}
]
}
]
},
{
"rule_id": "(an identifier for this rule)",
"rule_name": "(a name for this rule)",
"table_name": "(the name of the table or view being loaded)",
"edge_definitions": [
{
"from_vertex": {
"vertex_id_template": "{col1}",
"vertex_definition_id": "(an identifier for the vertex referenced above)"
},
"to_vertex": {
"vertex_id_template": "{col3}",
"vertex_definition_id": "(an identifier for the vertex referenced above)"
},
"edge_id_template": {
"label": "(the edge label to add)",
"template": "{col1}_{col3}"
},
"edge_properties":[
{
"property_name": "(the property to add)",
"property_value_template": "{col4} or text",
"property_value_type": "(data type like String, int, double)"
}
]
}
]
}
]
}
```
Das Vorhandensein eines Vertex-Labels bedeutet, dass der Knoten hier erstellt wird. Seine Abwesenheit bedeutet, dass der Knoten von einer anderen Quelle erstellt wird, und diese Definition fügt nur Knoteneigenschaften hinzu. Geben Sie so viele Knoten- und Grenzdefinitionen an, wie erforderlich, um die Zuordnungen für die gesamte relationale Datenbankquelle anzugeben.
Es folgt eine Beispielregel für eine `employee`-Tabelle.
```
{
"rules": [
{
"rule_id": "1",
"rule_name": "vertex_mapping_rule_from_nodes",
"table_name": "nodes",
"vertex_definitions": [
{
"vertex_id_template": "{emp_id}",
"vertex_label": "employee",
"vertex_definition_id": "1",
"vertex_properties": [
{
"property_name": "name",
"property_value_template": "{emp_name}",
"property_value_type": "String"
}
]
}
]
},
{
"rule_id": "2",
"rule_name": "edge_mapping_rule_from_emp",
"table_name": "nodes",
"edge_definitions": [
{
"from_vertex": {
"vertex_id_template": "{emp_id}",
"vertex_definition_id": "1"
},
"to_vertex": {
"vertex_id_template": "{mgr_id}",
"vertex_definition_id": "1"
},
"edge_id_template": {
"label": "reportsTo",
"template": "{emp_id}_{mgr_id}"
},
"edge_properties":[
{
"property_name": "team",
"property_value_template": "{team}",
"property_value_type": "String"
}
]
}
]
}
]
}
```
Hier ordnen die Knoten- und Grenzdefinitionen eine Meldebeziehung von einem `employee`-Knoten mit Mitarbeiter-ID (`EmpID`) und einem `employee`-Knoten mit einer Manager-ID (`managerId`) zu.
Weitere Informationen zum Erstellen von Graph-Zuordnungsregeln mit Gremlin JSON finden Sie unter [Gremlin-Format zum Laden von Daten](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) im *Amazon-Neptune-Benutzerhandbuch*.
### RDF/SPARQL Graph-Mapping-Regeln für die Generierung von Daten
Wenn Sie RDF-Daten laden, die mit SPARQL abgefragt werden sollen, schreiben Sie die Graph-Zuordnungsregeln in R2RML. R2RML ist eine Standard-W3C-Sprache für die Zuordnung relationaler Daten zu RDF. In einer R2RML-Datei gibt eine *Dreifach-Zuordnung* (z B. `<#TriplesMap1>` folgend) eine Regel an, um jede Zeile einer logischen Tabelle in null oder mehr RDF-Triple zu übersetzen. Eine *Betreffzuordnung* (z. B. eine beliebige `rr:subjectMap` folgend) gibt eine Regel zum Generieren der Betreffe der RDF-Triple an, die von einer Tripel-Zuordnung generiert werden. Eine *-Prädikat-Objekt-Zuordnung* (z. B. eine beliebige `rr:predicateObjectMap` folgend) ist eine Funktion, die ein oder mehrere Prädikat-Objekt-Paare für jede logische Tabellenzeile einer logischen Tabelle erstellt.
Ein einfaches Beispiel für eine `nodes`-Tabelle folgt.
```
@prefix rr: .
@prefix ex: .
<#TriplesMap1>
rr:logicalTable [ rr:tableName "nodes" ];
rr:subjectMap [
rr:template "http://data.example.com/employee/{id}";
rr:class ex:Employee;
];
rr:predicateObjectMap [
rr:predicate ex:name;
rr:objectMap [ rr:column "label" ];
]
```
Im vorherigen Beispiel definiert die Zuordnung Graph-Knoten, die aus einer Tabelle mit Mitarbeitern zugeordnet sind.
Ein weiteres einfaches Beispiel für eine `Student`-Tabelle folgt.
```
@prefix rr: .
@prefix ex: .
@prefix foaf: .
@prefix xsd: .
<#TriplesMap2>
rr:logicalTable [ rr:tableName "Student" ];
rr:subjectMap [ rr:template "http://example.com/{ID}{Name}";
rr:class foaf:Person ];
rr:predicateObjectMap [
rr:predicate ex:id ;
rr:objectMap [ rr:column "ID";
rr:datatype xsd:integer ]
];
rr:predicateObjectMap [
rr:predicate foaf:name ;
rr:objectMap [ rr:column "Name" ]
].
```
Im vorherigen Beispiel definiert das Mapping Graphknoten, die friend-of-a-friend Beziehungen zwischen Personen in einer `Student` Tabelle abbilden.
Weitere Informationen zum Erstellen von Graph-Zuordnungsregeln mit SPARQL R2RML finden Sie in der W3C-Spezifikation [R2RML: RDB to RDF Mapping Language](https://www.w3.org/TR/r2rml/).
## Datentypen für die Migration von Gremlin und R2RML zu Amazon Neptune als Ziel
AWS DMS führt die Datentypzuordnung von Ihrem SQL-Quellendpunkt zu Ihrem Neptune-Ziel auf eine von zwei Arten durch. Welche Art Sie verwenden, hängt vom Graph-Zuordnungsformat ab, das Sie zum Laden der Neptune-Datenbank verwenden:
+ Apache TinkerPop Gremlin unter Verwendung einer JSON-Darstellung der Migrationsdaten.
+ SPARQL von W3C, unter Verwendung einer R2RML-Darstellung der Migrationsdaten.
Weitere Informationen zu diesen beiden Graph-Zuordnungsformaten finden Sie unter [Angeben von Graph-Zuordnungsregeln mit Gremlin und R2RML für Amazon Neptune als Ziel](#CHAP_Target.Neptune.GraphMapping).
Nachfolgend finden Sie Beschreibungen der Datentypzuordnungen für jedes Format.
### Datentypzuordnungen von SQL-Quelle auf Gremlin-Ziel
Die folgende Tabelle zeigt die Datentypzuordnungen von einer SQL-Quelle auf ein Gremlin-formatiertes Ziel.
AWS DMS ordnet einen beliebigen SQL-Quelldatentyp, der nicht aufgeführt ist, einem Gremlin zu. `String`
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_Target.Neptune.html)
Weitere Informationen zu den Gremlin-Datentypen zum Laden von Neptune finden Sie unter [Gremlin-Datentypen](https://docs.aws.amazon.com//neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html#bulk-load-tutorial-format-gremlin-datatypes) im *Neptune-Benutzerhandbuch*.
### SQL-Quell-zu-R2RML-Zieldatentyp-Zuordnungen (RDF)
Die folgende Tabelle zeigt die Datentypzuordnungen von einer SQL-Quelle zu einem R2RML-formatierten Ziel.
Bei allen aufgelisteten RDF-Datentypen wird zwischen Groß- und Kleinschreibung unterschieden, mit Ausnahme von RDF-Literal. AWS DMS ordnet jeden nicht aufgelisteten SQL-Quelldatentyp einem RDF-Literal zu.
Ein *RDF-Literal* ist eine von einer Vielzahl von wörtlichen lexikalischen Formen und Datentypen. Weitere Informationen finden Sie unter [RDF-Literale](https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-Literal) in der W3C-Spezifikation *Resource Description Framework (RDF): Konzepte und abstrakte Syntax*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_Target.Neptune.html)
Weitere Informationen zu den RDF-Datentypen zum Laden von Neptune und zu ihren Zuordnungen zu SQL-Quelldatentypen finden Sie unter [Datentypkonvertierungen](https://www.w3.org/TR/r2rml/#datatype-conversions) in der W3C-Spezifikation *R2RML: RDB to RDF Mapping Language*.
## Einschränkungen bei der Verwendung von Amazon Neptune als Ziel
Bei der Verwendung von Neptune als Ziel gelten die folgenden Einschränkungen:
+ AWS DMS unterstützt derzeit Volllastaufgaben nur für die Migration zu einem Neptune-Ziel. Die CDC-Migration (CDC = Change Data Capture) zu einem Neptune-Ziel wird nicht unterstützt.
+ Stellen Sie sicher, dass in Ihrer Neptune-Zieldatenbank alle Daten manuell gelöscht werden, bevor Sie die Migrationsaufgabe starten, wie in den folgenden Beispielen zu sehen ist.
Um alle Daten (Eckpunkte und Edges) innerhalb des Graphen zu löschen, führen Sie den folgenden Gremlin-Befehl aus.
```
gremlin> g.V().drop().iterate()
```
Um Eckpunkte mit dem Label `'customer'` zu löschen, führen Sie den folgenden Gremlin-Befehl aus.
```
gremlin> g.V().hasLabel('customer').drop()
```
**Anmerkung**
Es kann einige Zeit dauern, bis ein großes Dataset gelöscht wird. Möglicherweise möchten Sie `drop()` mit einem Limit iterieren, z. B. `limit(1000)`.
Um Edges mit dem Label `'rated'` zu löschen, führen Sie den folgenden Gremlin-Befehl aus.
```
gremlin> g.E().hasLabel('rated').drop()
```
**Anmerkung**
Es kann einige Zeit dauern, bis ein großes Dataset gelöscht wird. Möglicherweise möchten Sie `drop()` mit einem Limit iterieren, z. B. `limit(1000)`.
+ Der DMS-API-Vorgang `DescribeTableStatistics` kann aufgrund der Art der Neptune-Graph-Datenstrukturen ungenaue Ergebnisse zu einer bestimmten Tabelle zurückgeben.
AWS DMS Scannt während der Migration jede Quelltabelle und verwendet Graph-Mapping, um die Quelldaten in ein Neptun-Diagramm zu konvertieren. Die konvertierten Daten werden zuerst im S3-Bucket-Ordner gespeichert, der für den Zielendpunkt angegeben ist. Wenn die Quelle gescannt wird und diese zwischengeschalteten S3-Daten erfolgreich generiert werden, geht `DescribeTableStatistics` davon aus, dass die Daten erfolgreich in die Neptune-Zieldatenbank geladen wurden. Aber das ist nicht immer wahr. Um zu überprüfen, ob die Daten für eine bestimmte Tabelle korrekt geladen wurden, vergleichen Sie die `count()`-Rückgabewerte an beiden Enden der Migration für diese Tabelle.
Im folgenden Beispiel AWS DMS hat eine `customer` Tabelle aus der Quelldatenbank geladen, der das Label `'customer'` im Neptune-Zieldatenbankdiagramm zugewiesen wurde. Sie können sicherstellen, dass dieses Label in die Zieldatenbank geschrieben wird. Vergleichen Sie dazu die Anzahl der in der Quelldatenbank verfügbaren `customer`-Zeilen mit der Anzahl der mit `'customer'` beschrifteten Zeilen, die nach Abschluss der Aufgabe in die Neptune-Zieldatenbank geladen wurden.
Führen Sie die folgenden Schritte aus, um die Anzahl der Kundenzeilen aus der Quelldatenbank mithilfe von SQL abzurufen.
```
select count(*) from customer;
```
Um die Anzahl der beschrifteten `'customer'`-Zeilen zu erhalten, die mit Gremlin in den Zieldatenbank-Graph geladen wurden, führen Sie Folgendes aus.
```
gremlin> g.V().hasLabel('customer').count()
```
+ Wenn derzeit eine einzelne Tabelle nicht geladen werden kann, schlägt die gesamte Aufgabe fehl. Im Gegensatz zu einem relationalen Datenbankziel sind Daten in Neptune stark verbunden, was es in vielen Fällen unmöglich macht, eine Aufgabe fortzusetzen. Wenn eine Aufgabe aufgrund dieser Art von Datenladefehler nicht erfolgreich fortgesetzt werden kann, erstellen Sie eine neue Aufgabe, um die Tabelle zu laden, die nicht geladen werden konnte. Bevor Sie diese neue Aufgabe ausführen, löschen Sie die teilweise geladene Tabelle manuell aus dem Neptune-Ziel.
**Anmerkung**
Sie können eine Aufgabe fortsetzen, bei der die Migration zu einem Neptune-Ziel fehlschlägt, wenn der Fehler behoben werden kann (z. B. ein Netzwerk-Transitfehler).
+ AWS DMS unterstützt die meisten Standards für R2RML. Unterstützt jedoch bestimmte R2RML-Standards AWS DMS nicht, einschließlich inverser Ausdrücke, Joins und Views. Eine Problemumgehung für eine R2RML-Ansicht besteht darin, eine entsprechende benutzerdefinierte SQL-Ansicht in der Quelldatenbank zu erstellen. Verwenden Sie in der Migrationsaufgabe die Tabellenzuordnung, um die Ansicht als Eingabe auszuwählen. Ordnen Sie dann die Ansicht einer Tabelle zu, die dann von R2RML verwendet wird, um Diagrammdaten zu generieren.
+ Wenn Sie Quelldaten mit nicht unterstützten SQL-Datentypen migrieren, sind die sich daraus ergebenen Zieldaten möglicherweise nicht ganz genau. Weitere Informationen finden Sie unter [Datentypen für die Migration von Gremlin und R2RML zu Amazon Neptune als Ziel](#CHAP_Target.Neptune.DataTypes).
+ AWS DMS unterstützt nicht die Migration von LOB-Daten in ein Neptun-Ziel.
# Verwenden von Redis OSS als Ziel für AWS Database Migration Service
Redis OSS ist ein speicherinterner Open-Source-Datenstrukturspeicher, der als Datenbank, Cache und Nachrichtenbroker verwendet wird. Durch die Verwaltung von Daten im Speicher können Lese- oder Schreibvorgänge unter Umständen in weniger als einer Millisekunde ausgeführt werden und es sind Hunderte Millionen von Vorgängen pro Sekunde möglich. Als In-Memory-Datenspeicher unterstützt Redis OSS die anspruchsvollsten Anwendungen, die Reaktionszeiten unter einer Millisekunde erfordern.
Mit dieser AWS DMS Methode können Sie Daten aus jeder unterstützten Quelldatenbank mit minimaler Ausfallzeit in einen Redis OSS-Zieldatenspeicher migrieren. Weitere Informationen zu Redis OSS finden Sie in der [Redis](https://redis.io/documentation) OSS-Dokumentation.
Zusätzlich zu On-Premises-Redis OSS wird Folgendes unterstützt: AWS Database Migration Service
+ [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis/) als Zieldatenspeicher. ElastiCache (Redis OSS) funktioniert mit Ihren Redis OSS-Clients und verwendet das offene Redis OSS-Datenformat zum Speichern Ihrer Daten.
+ [Amazon MemoryDB](https://aws.amazon.com/memorydb/) als Zieldatenspeicher. MemoryDB ist mit Redis OSS kompatibel und ermöglicht es Ihnen, Anwendungen mit allen heute verwendeten Redis OSS-Datenstrukturen und Befehlen zu erstellen. APIs
Weitere Informationen zur Arbeit mit Redis OSS als Ziel für finden Sie in den folgenden Abschnitten AWS DMS:
**Topics**
+ [Voraussetzungen für die Verwendung eines Redis OSS-Clusters als Ziel für AWS DMS](#CHAP_Target.Redis.Prerequisites)
+ [Einschränkungen bei der Verwendung von Redis als Ziel für AWS Database Migration Service](#CHAP_Target.Redis.Limitations)
+ [Migrieren von Daten aus einer relationalen oder nicht-relationalen Datenbank zu einem Redis OSS-Ziel](#CHAP_Target.Redis.Migrating)
+ [Angeben der Endpunkteinstellungen für Redis OSS als Ziel](#CHAP_Target.Redis.EndpointSettings)
## Voraussetzungen für die Verwendung eines Redis OSS-Clusters als Ziel für AWS DMS
*DMS unterstützt ein lokales Redis OSS-Ziel in einer eigenständigen Konfiguration oder als Redis OSS-Cluster, bei dem Daten automatisch auf mehrere Knoten verteilt werden.* Sharding ist ein Prozess, bei dem Daten in kleinere Blöcke, sogenannte Shards, aufgeteilt werden, die auf mehrere Server oder Knoten verteilt werden. Ein Shard ist eine Datenpartition, die eine Teilmenge des gesamten Datensatzes enthält und einen Teil der gesamten Workload abdeckt.
**Da es sich bei Redis OSS um einen NoSQL-Datenspeicher mit Schlüsselwerten handelt, lautet die Redis OSS-Schlüsselbenennungskonvention, die Sie verwenden sollten, wenn Ihre Quelle eine relationale Datenbank ist, schema-name.table-name.primary-key.** In Redis OSS dürfen der Schlüssel und der Wert das Sonderzeichen% nicht enthalten. Andernfalls überspringt DMS den Datensatz.
**Anmerkung**
Wenn Sie ElastiCache (Redis OSS) als Ziel verwenden, unterstützt DMS nur Konfigurationen, die den *Clustermodus aktivieren.* Weitere Informationen zur Verwendung von ElastiCache (Redis OSS) Version 6.x oder höher zur Erstellung eines Zieldatenspeichers mit aktiviertem Clustermodus finden Sie unter [Erste Schritte](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/GettingStarted.html) im *Amazon ElastiCache (Redis OSS)* -Benutzerhandbuch.
Bevor Sie mit einer Datenbankmigration beginnen, starten Sie Ihren Redis OSS-Cluster mit den folgenden Kriterien.
+ Ihr Cluster enthält einen oder mehrere Shards.
+ Wenn Sie ein ElastiCache (Redis OSS-) Ziel verwenden, stellen Sie sicher, dass Ihr Cluster keine rollenbasierte IAM-Zugriffskontrolle verwendet. Verwenden Sie stattdessen Redis OSS Auth, um Benutzer zu authentifizieren.
+ Aktivieren Sie Multi-AZ (Availability Zones).
+ Stellen Sie sicher, dass auf dem Cluster genug Speicher für die zu migrierenden Daten aus der Datenbank verfügbar ist.
+ Stellen Sie sicher, dass Ihr Redis-OSS-Zielcluster keine Daten enthält, bevor Sie mit der ersten Migrationsaufgabe beginnen.
Sie sollten Ihre Sicherheitsanforderungen für die Datenmigration ermitteln, bevor Sie Ihre Cluster-Konfiguration erstellen. DMS unterstützt die Migration zu Zielreplikationsgruppen unabhängig von ihrer Verschlüsselungskonfiguration. Sie können die Verschlüsselung jedoch nur aktivieren oder deaktivieren, wenn Sie Ihre Cluster-Konfiguration erstellen.
## Einschränkungen bei der Verwendung von Redis als Ziel für AWS Database Migration Service
Bei der Verwendung von Redis OSS als Ziel gelten die folgenden Einschränkungen:
+ Da es sich bei Redis OSS um einen No-SQL-Datenspeicher mit Schlüsselwerten handelt, gilt die Redis OSS-Konvention zur Benennung von Schlüsseln, die Sie verwenden sollten, wenn Ihre Quelle eine relationale Datenbank ist. `schema-name.table-name.primary-key`
+ In Redis OSS darf der Schlüsselwert das Sonderzeichen nicht enthalten. `%` Andernfalls überspringt DMS den Datensatz.
+ DMS migriert keine Zeilen, die das Zeichen enthalten. `%`
+ DMS migriert keine Felder, die das `%` Zeichen im Feldnamen enthalten.
+ Der vollständige LOB-Modus wird nicht unterstützt.
+ Eine private Zertifizierungsstelle (CA) wird nicht unterstützt, wenn ElastiCache (Redis OSS) als Ziel verwendet wird.
+ AWS DMS unterstützt keine Quelldaten mit eingebetteten `'\0'` Zeichen, wenn Redis als Zielendpunkt verwendet wird. Daten, die eingebettete `'\0'` Zeichen enthalten, werden beim ersten `'\0'` Zeichen gekürzt.
## Migrieren von Daten aus einer relationalen oder nicht-relationalen Datenbank zu einem Redis OSS-Ziel
Sie können Daten aus jedem SQL- oder NoSQL-Quelldatenspeicher direkt zu einem Redis OSS-Ziel migrieren. Das Einrichten und Starten einer Migration zu einem Redis OSS-Ziel ähnelt jeder Migration von Volllast und Change Data Capture mithilfe der DMS-Konsole oder API. Um eine Datenbankmigration zu einem Redis OSS-Ziel durchzuführen, gehen Sie wie folgt vor.
+ Erstellen Sie eine Replikations-Instance, die alle Migrationsprozesse durchführt. Weitere Informationen finden Sie unter [Erstellen einer Replikations-Instance](CHAP_ReplicationInstance.Creating.md).
+ Geben Sie einen Quellendpunkt an. Weitere Informationen finden Sie unter [Erstellen der Quell- und Zielendpunkte](CHAP_Endpoints.Creating.md).
+ Suchen Sie nach dem DNS-Namen und der Portnummer Ihres Clusters.
+ Laden Sie ein Zertifikatpaket herunter, das Sie zur Überprüfung von SSL-Verbindungen verwenden können.
+ Geben Sie einen Zielendpunkt an, wie unten beschrieben.
+ Erstellen Sie eine oder mehrere Aufgaben, um festzulegen, welche Tabellen und Replikationsprozesse verwendet werden sollen. Weitere Informationen finden Sie unter [Erstellen einer Aufgabe](CHAP_Tasks.Creating.md).
+ Migrieren Sie Daten aus Ihrer Quelldatenbank zu Ihrem Ziel-Cluster.
Sie haben zwei Möglichkeiten, mit einer Datenbankmigration zu beginnen:
1. Sie können die AWS DMS Konsole auswählen und jeden Schritt dort ausführen.
1. Sie können das AWS Command Line Interface (AWS CLI) verwenden. Weitere Informationen zur Verwendung der CLI mit AWS DMS finden Sie unter [AWS CLI for AWS DMS](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html).
**So finden Sie den DNS-Namen und die Portnummer Ihres Clusters**
+ Verwenden Sie den folgenden AWS CLI Befehl, um `replication-group-id` den Namen Ihrer Replikationsgruppe anzugeben.
```
aws elasticache describe-replication-groups --replication-group-id myreplgroup
```
Hier zeigt die Ausgabe den DNS-Namen im Attribut `Address` und die Portnummer im Attribut `Port` des Primärknotens im Cluster.
```
...
"ReadEndpoint": {
"Port": 6379,
"Address": "myreplgroup-
111.1abc1d.1111.uuu1.cache.example.com"
}
...
```
Wenn Sie MemoryDB als Ziel verwenden, verwenden Sie den folgenden AWS CLI Befehl, um eine Endpunktadresse für Ihren Redis OSS-Cluster bereitzustellen.
```
aws memorydb describe-clusters --clusterid clusterid
```
**Laden Sie ein Zertifikatpaket herunter, mit dem SSL-Verbindungen überprüft werden können.**
+ Geben Sie in der Befehlszeile den folgenden `wget`-Befehl ein: Wget ist ein kostenloses GNU-Befehlszeilen-Dienstprogramm, das zum Herunterladen von Dateien aus dem Internet verwendet wird.
```
wget https://s3.aws-api-domain/rds-downloads/rds-combined-ca-bundle.pem
```
Hier `aws-api-domain` wird die Amazon S3 S3-Domain in Ihrer AWS Region vervollständigt, die für den Zugriff auf den angegebenen S3-Bucket und die bereitgestellte rds-combined-ca-bundle .pem-Datei erforderlich ist.
**Um mit der Konsole einen Zielendpunkt zu erstellen AWS DMS**
Dieser Endpunkt ist für Ihr Redis OSS-Ziel bestimmt, das bereits läuft.
+ Wählen Sie im Navigationsbereich **Endpunkte** und anschließend **Endpunkt erstellen** aus. In der folgenden Tabelle sind die Einstellungen beschrieben.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_Target.Redis.html)
Wenn Sie alle Informationen für Ihren Endpunkt bereitgestellt haben, AWS DMS erstellt es Ihren Redis OSS-Zielendpunkt zur Verwendung bei der Datenbankmigration.
Informationen zum Erstellen einer Migrationsaufgabe und zum Starten Ihrer Datenbankmigration finden Sie unter [Erstellen einer Aufgabe](CHAP_Tasks.Creating.md).
## Angeben der Endpunkteinstellungen für Redis OSS als Ziel
Um einen Zielendpunkt zu erstellen oder zu ändern, können Sie die Konsole oder die `CreateEndpoint`- oder `ModifyEndpoint`-API-Vorgänge verwenden.
Geben Sie für ein Redis OSS-Ziel in der AWS DMS Konsole auf der Seite ****Endpoint erstellen oder Endpoint** **modifizieren** die endpunktspezifischen Einstellungen** an.
Wenn Sie die API-Operationen `CreateEndpoint` und `ModifyEndpoint` verwenden, geben Sie Anforderungsparameter für die Option `RedisSettings` an. Das folgende Beispiel zeigt, wie dies über die AWS CLI geschehen kann.
```
aws dms create-endpoint --endpoint-identifier my-redis-target
--endpoint-type target --engine-name redis --redis-settings
'{"ServerName":"sample-test-sample.zz012zz.cluster.eee1.cache.bbbxxx.com","Port":6379,"AuthType":"auth-token",
"SslSecurityProtocol":"ssl-encryption", "AuthPassword":"notanactualpassword"}'
{
"Endpoint": {
"EndpointIdentifier": "my-redis-target",
"EndpointType": "TARGET",
"EngineName": "redis",
"EngineDisplayName": "Redis",
"TransferFiles": false,
"ReceiveTransferredFiles": false,
"Status": "active",
"KmsKeyId": "arn:aws:kms:us-east-1:999999999999:key/x-b188188x",
"EndpointArn": "arn:aws:dms:us-east-1:555555555555:endpoint:ABCDEFGHIJKLMONOPQRSTUVWXYZ",
"SslMode": "none",
"RedisSettings": {
"ServerName": "sample-test-sample.zz012zz.cluster.eee1.cache.bbbxxx.com",
"Port": 6379,
"SslSecurityProtocol": "ssl-encryption",
"AuthType": "auth-token"
}
}
}
```
Die Parameter für `--redis-settings` lauten wie folgt:
+ `ServerName`— (Erforderlich) Typ`string`, gibt den Redis OSS-Cluster an, in den Daten migriert werden, und der sich in derselben VPC befindet.
+ `Port` – (Erforderlich), Typ `number`, der Portwert, der für den Zugriff auf den Endpunkt verwendet wird.
+ `SslSecurityProtocol` – (Optional), gültige Werte sind `plaintext` und `ssl-encryption`. Der Standardwert ist `ssl-encryption`.
Die `plaintext`-Option bietet keine Transport Layer Security (TLS)-Verschlüsselung für den Datenverkehr zwischen Endpunkt und Datenbank.
Verwenden Sie `ssl-encryption`, um eine verschlüsselte Verbindung herzustellen. `ssl-encryption` benötigt keinen ARN der SSL-Zertifizierungsstelle (CA), um das Zertifikat eines Servers zu verifizieren, über die Einstellung `SslCaCertificateArn` kann jedoch optional einer angegeben werden. Wenn kein ARN für eine Zertifizierungsstelle angegeben wird, verwendet DMS die Amazon-Stammzertifizierungsstelle.
Wenn Sie ein lokales Redis OSS-Ziel verwenden, können Sie `SslCaCertificateArn` damit eine öffentliche oder private Zertifizierungsstelle (CA) in DMS importieren und diesen ARN für die Serverauthentifizierung bereitstellen. Eine private CA wird nicht unterstützt, wenn Sie ElastiCache (Redis OSS) als Ziel verwenden.
+ `AuthType`— (Erforderlich) Gibt die Art der Authentifizierung an, die bei der Verbindung mit Redis OSS durchgeführt werden soll. Gültige Werte sind: `none`, `auth-token` und `auth-role`.
Für die `auth-token` Option muss ein *AuthPassword* "angegeben werden, während für die `auth-role` Option die Angabe von" *AuthUserName* "und" *AuthPassword* "erforderlich ist.
# Babelfish als Ziel verwenden für AWS Database Migration Service
Sie können Daten von einer Microsoft SQL Server-Quelldatenbank zu einem Babelfish-Ziel migrieren, indem Sie. AWS Database Migration Service
Babelfish for Aurora PostgreSQL erweitert Ihre Amazon Aurora PostgreSQL kompatible Edition-Datenbank um die Möglichkeit, Datenbankverbindungen von Microsoft SQL Server-Clients zu akzeptieren. Dadurch können Anwendungen, die ursprünglich für SQL Server entwickelt wurden, direkt mit Aurora PostgreSQL arbeiten – mit nur wenigen Codeänderungen im Vergleich zu einer herkömmlichen Migration und ohne Änderung der Datenbanktreiber.
Informationen zu Versionen von Babelfish, die als Ziel AWS DMS unterstützt werden, finden Sie unter. [Ziele für AWS DMS](CHAP_Introduction.Targets.md) Frühere Versionen von Babelfish in Aurora PostgreSQL erfordern ein Upgrade, damit der Babelfish-Endpunkt verwendet werden kann.
**Anmerkung**
Der Aurora-PostgreSQL-Zielendpunkt ist die bevorzugte Methode für die Migration von Daten zu Babelfish. Weitere Informationen finden Sie unter [Verwenden von Babelfish für Aurora PostgreSQL als Ziel](CHAP_Target.PostgreSQL.md#CHAP_Target.PostgreSQL.Babelfish).
Informationen zur Verwendung von Babelfish als Datenbank-Endpunkt finden Sie unter [Babelfish for Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html) im *Benutzerhandbuch für Amazon Aurora*.
## Voraussetzungen für die Verwendung von Babelfish als Ziel für AWS DMS
Sie müssen Ihre Tabellen erstellen, bevor Sie Daten migrieren, um sicherzustellen, dass die richtigen Datentypen und Tabellenmetadaten AWS DMS verwendet werden. Wenn Sie Ihre Tabellen nicht auf dem Ziel erstellen, bevor Sie die Migration ausführen, werden die Tabellen AWS DMS möglicherweise mit falschen Datentypen und Berechtigungen erstellt. AWS DMS Erstellt beispielsweise stattdessen eine Zeitstempelspalte als binär (8) und bietet nicht die erwartete timestamp/rowversion Funktionalität.
**So können Sie Ihre Tabellen vor der Migration vorbereiten und erstellen**
1. Führen Sie Create-Table-DDL-Anweisungen aus, die alle eindeutigen Einschränkungen, Primärschlüssel oder Standardeinschränkungen enthalten.
Fügen Sie keine Einschränkungen hinsichtlich Fremdschlüsseln und keine DDL-Anweisungen für Objekte wie Ansichten, gespeicherte Prozeduren, Funktionen oder Auslöser hinzu. Sie können sie nach der Migration Ihrer Quelldatenbank anwenden.
1. Identifizieren Sie alle Identitätsspalten, berechneten Spalten oder Spalten mit den Datentypen rowversion oder timestamp für Ihre Tabellen. Erstellen Sie anschließend die erforderlichen Transformationsregeln, um bekannte Probleme bei der Ausführung der Migrationsaufgabe zu beheben. Weitere Informationen finden Sie unter [Transformationsregeln und Aktionen](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
1. Identifizieren Sie Spalten mit Datentypen, die Babelfish nicht unterstützt. Ändern Sie dann die betroffenen Spalten in der Zieltabelle, sodass sie unterstützte Datentypen verwenden, oder erstellen Sie eine Transformationsregel, durch die sie während der Migrationsaufgabe entfernt werden. Weitere Informationen finden Sie unter [Transformationsregeln und Aktionen](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
In der folgenden Tabelle sind Quelldatentypen, die von Babelfish nicht unterstützt werden, und der entsprechende empfohlene Zieldatentyp aufgeführt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_Target.Babelfish.html)
**So legen Sie die Aurora-Kapazitätseinheiten (ACUs) für Ihre Aurora PostgreSQL Serverless V2-Quelldatenbank fest**
Sie können die Leistung Ihrer AWS DMS Migrationsaufgabe vor der Ausführung verbessern, indem Sie den ACU-Mindestwert festlegen.
+ Stellen Sie im Fenster mit den **Kapazitätseinstellungen von Severless v2** **Minimum ACUs** auf **2** oder eine angemessene Stufe für Ihren Aurora-DB-Cluster ein.
Weitere Informationen zum Festlegen von Aurora-Kapazitätseinheiten finden Sie unter [Auswählen des Aurora-Serverless-v2-Kapazitätsbereichs für einen Aurora-Cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html) im *Benutzerhandbuch für Amazon Aurora*.
Nachdem Sie Ihre AWS DMS Migrationsaufgabe ausgeführt haben, können Sie den Mindestwert Ihres ACUs auf ein angemessenes Niveau für Ihre Aurora PostgreSQL Serverless V2-Quelldatenbank zurücksetzen.
## Sicherheitsanforderungen bei der Verwendung von Babelfish als Ziel für AWS Database Migration Service
Im Folgenden werden die Sicherheitsanforderungen für die Verwendung AWS DMS mit einem Babelfish-Target beschrieben:
+ Der Name des Administrator-Benutzers (Admin-Benutzer), mit dem die Datenbank erstellt wurde.
+ PSQL-Login und -Benutzer mit den ausreichenden SELECT-, INSERT-, UPDATE-, DELETE- und REFERENCES-Berechtigungen.
## Benutzerberechtigungen für die Verwendung von Babelfish als Ziel für AWS DMS
**Wichtig**
Aus Sicherheitsgründen muss das für die Datenmigration verwendete Benutzerkonto ein registrierter Benutzer in einer Babelfish-Zieldatenbank sein.
Ihr Babelfish-Zielendpunkt erfordert Mindestbenutzerberechtigungen, um eine AWS DMS -Migration ausführen zu können.
**So erstellen Sie einen Login und einen Transact-SQL (T-SQL)-Benutzer mit geringen Berechtigungen**
1. Erstellen Sie einen Login und ein Passwort für die Verbindung mit dem Server.
```
CREATE LOGIN dms_user WITH PASSWORD = 'password';
GO
```
1. Erstellen Sie die virtuelle Datenbank für Ihren Babelfish-Cluster.
```
CREATE DATABASE my_database;
GO
```
1. Erstellen Sie den T-SQL-Benutzer für Ihre Zieldatenbank.
```
USE my_database
GO
CREATE USER dms_user FOR LOGIN dms_user;
GO
```
1. Erteilen Sie für jede Tabelle in Ihrer Babelfish-Datenbank GRANT-Berechtigungen für die Tabellen.
```
GRANT SELECT, DELETE, INSERT, REFERENCES, UPDATE ON [dbo].[Categories] TO dms_user;
```
## Einschränkungen bei der Verwendung von Babelfish als Ziel für AWS Database Migration Service
Die folgenden Einschränkungen gelten, wenn Sie eine Babelfish-Datenbank als Ziel für AWS DMS verwenden:
+ Es wird nur der Tabellenvorbereitungsmodus „**Nichts unternehmen**“ unterstützt.
+ Der Datentyp ROWVERSION erfordert eine Tabellenzuordnungsregel, die den Spaltennamen während der Migrationsaufgabe aus der Tabelle entfernt.
+ Der Datentyp sql\$1variant wird nicht unterstützt.
+ Der vollständige LOB-Modus wird unterstützt. Für die Verwendung von SQL Server als Quellendpunkt muss die Einstellung `ForceFullLob=True` für das SQL Server-Endpunkt-Verbindungsattribut festgelegt werden, damit LOBs sie zum Zielendpunkt migriert werden kann.
+ Für Einstellungen von Replikationsaufgaben gelten die folgenden Einschränkungen:
```
{
"FullLoadSettings": {
"TargetTablePrepMode": "DO_NOTHING",
"CreatePkAfterFullLoad": false,
}.
}
```
+ Die Datentypen TIME (7), DATETIME2 (7) und DATETIMEOFFSET (7) in Babelfish begrenzen den Genauigkeitswert für den Sekundenanteil der Zeit auf 6 Ziffern. Ziehen Sie die Verwendung des Genauigkeitswerts 6 für Ihre Zieltabelle in Betracht, wenn Sie diese Datentypen verwenden. Bei Babelfish-Versionen 2.2.0 und höher ist bei Verwendung von TIME (7) und DATETIME2 (7) die siebte Stelle der Genauigkeit immer Null.
+ Im Modus DO\$1NOTHING prüft DMS, ob die Tabelle bereits vorhanden ist. Wenn die Tabelle nicht im Zielschema vorhanden ist, erstellt DMS die Tabelle auf Grundlage der Quelltabellendefinition und ordnet alle benutzerdefinierten Datentypen ihrem Basisdatentyp zu.
+ Eine AWS DMS Migrationsaufgabe zu einem Babelfish-Ziel unterstützt keine Tabellen mit Spalten, die die Datentypen ROWVERSION oder TIMESTAMP verwenden. Sie können eine Tabellenzuordnungsregel verwenden, die den Spaltennamen während der Übertragung aus der Tabelle entfernt. Im folgenden Beispiel für eine Transformationsregel wird die Tabelle mit dem Namen `Actor` in Ihrer Quelle so transformiert, dass alle Spalten, die mit den Zeichen `col` beginnen, aus der Tabelle `Actor` in Ihrem Ziel entfernt werden.
```
{
"rules": [{
"rule-type": "selection",is
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
}, {
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "remove-column",
"rule-target": "column",
"object-locator": {
"schema-name": "test",
"table-name": "Actor",
"column-name": "col%"
}
}]
}
```
+ Für Tabellen mit Identitäts- oder berechneten Spalten, bei denen die Zieltabellen Namen mit gemischter Groß- und Kleinschreibung wie Kategorien verwenden, müssen Sie eine Transformationsregelaktion erstellen, die die Tabellennamen für Ihre DMS-Aufgabe in Kleinbuchstaben umwandelt. Das folgende Beispiel zeigt, wie die Transformationsregelaktion „**Kleinbuchstaben erstellen**“ mithilfe der Konsole erstellt wird. AWS DMS Weitere Informationen finden Sie unter [Transformationsregeln und Aktionen](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
![\[Babelfish-Transformationsregel\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-babelfish-transform-1.png)
+ Vor Babelfish Version 2.2.0 beschränkte DMS die Anzahl der Spalten, die Sie auf einen Babelfish-Zielendpunkt replizieren konnten, auf zwanzig (20) Spalten. Mit Babelfish 2.2.0 wurde das Limit auf 100 Spalten erhöht. Mit den Babelfish-Versionen 2.4.0 und höher wird die Anzahl der Spalten, die Sie replizieren können, erneut erhöht. Sie können das folgende Codebeispiel für Ihre SQL-Server-Datenbank ausführen, um zu ermitteln, welche Tabellen zu lang sind.
```
USE myDB;
GO
DECLARE @Babelfish_version_string_limit INT = 8000; -- Use 380 for Babelfish versions before 2.2.0
WITH bfendpoint
AS (
SELECT
[TABLE_SCHEMA]
,[TABLE_NAME]
, COUNT( [COLUMN_NAME] ) AS NumberColumns
, ( SUM( LEN( [COLUMN_NAME] ) + 3)
+ SUM( LEN( FORMAT(ORDINAL_POSITION, 'N0') ) + 3 )
+ LEN( TABLE_SCHEMA ) + 3
+ 12 -- INSERT INTO string
+ 12) AS InsertIntoCommandLength -- values string
, CASE WHEN ( SUM( LEN( [COLUMN_NAME] ) + 3)
+ SUM( LEN( FORMAT(ORDINAL_POSITION, 'N0') ) + 3 )
+ LEN( TABLE_SCHEMA ) + 3
+ 12 -- INSERT INTO string
+ 12) -- values string
>= @Babelfish_version_string_limit
THEN 1
ELSE 0
END AS IsTooLong
FROM [INFORMATION_SCHEMA].[COLUMNS]
GROUP BY [TABLE_SCHEMA], [TABLE_NAME]
)
SELECT *
FROM bfendpoint
WHERE IsTooLong = 1
ORDER BY TABLE_SCHEMA, InsertIntoCommandLength DESC, TABLE_NAME
;
```
## Zieldatentypen für Babelfish
Die folgende Tabelle zeigt die Babelfish-Zieldatentypen, die bei der Verwendung unterstützt werden, AWS DMS und die Standardzuweisung von Datentypen. AWS DMS
Weitere Informationen zu AWS DMS Datentypen finden Sie unter. [Datentypen für den AWS Database Migration Service](CHAP_Reference.DataTypes.md)
| AWS DMS Datentyp | Babelfish-Datentyp |
| --- | --- |
| BOOLEAN | TINYINT |
| BYTES | VARBINARY (Länge) |
| DATE | DATE |
| TIME | TIME |
| INT1 | SMALLINT |
| INT2 | SMALLINT |
| INT4 | INT |
| INT8 | BIGINT |
| NUMERIC | NUMERIC (p,s) |
| REAL4 | REAL |
| REAL8 | FLOAT |
| STRING | Wenn die Spalte eine Datums- oder Zeitspalte ist, gehen Sie wie folgt vor: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_Target.Babelfish.html) Wenn die Spalte keine Datums- oder Zeitspalte ist, verwenden Sie VARCHAR (Länge). |
| UINT1 | TINYINT |
| UINT2 | SMALLINT |
| UINT4 | INT |
| UINT8 | BIGINT |
| WSTRING | NVARCHAR(Länge) |
| BLOB | VARBINARY(max) Um diesen Datentyp mit DMS zu verwenden, müssen Sie die Verwendung von BLOBs für eine bestimmte Aufgabe aktivieren. DMS unterstützt BLOB-Datentypen nur in Tabellen, die einen Primärschlüssel enthalten. |
| CLOB | VARCHAR(max) Um diesen Datentyp mit DMS zu verwenden, müssen Sie die Verwendung von CLOBs für eine bestimmte Aufgabe aktivieren. |
| NCLOB | NVARCHAR(max) Um diesen Datentyp mit DMS zu verwenden, müssen Sie die Verwendung von NCLOBs für eine bestimmte Aufgabe aktivieren. Bei CDC unterstützt DMS NCLOB-Datentypen nur in Tabellen, die einen Primärschlüssel enthalten. |
# Verwendung von Amazon Timestream als Ziel für AWS Database Migration Service
Sie können AWS Database Migration Service es verwenden, um Daten von Ihrer Quelldatenbank zu einem Amazon Timestream Timestream-Zielendpunkt zu migrieren, wobei Full Load- und CDC-Datenmigrationen unterstützt werden.
Amazon Timestream ist ein schneller, skalierbarer Serverless-Zeitreihendatenbank-Service, der für die Erfassung großer Datenmengen entwickelt wurde. Zeitreihendaten sind Folgen von Datenpunkten, die über ein Zeitintervall erfasst wurden. Sie werden zur Messung von Ereignissen verwendet, die sich im Laufe der Zeit ändern. Es wird verwendet, um Metriken aus IoT-Anwendungen, -Anwendungen und -Analyseanwendungen zu sammeln, zu speichern und zu analysieren. DevOps Sobald Sie Ihre Daten in Timestream haben, können Sie Trends und Muster in Ihren Daten nahezu in Echtzeit visualisieren und identifizieren. Informationen zu Amazon Timestream finden Sie unter [Was ist Amazon Timestream?](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) im *Amazon-Timestream-Entwicklerhandbuch*.
**Topics**
+ [Voraussetzungen für die Verwendung von Amazon Timestream als Ziel für AWS Database Migration Service](#CHAP_Target.Timestream.Prerequisites)
+ [Aufgabeneinstellungen für vollständige Multithread-Ladevorgänge](#CHAP_Target.Timestream.FLTaskSettings)
+ [Aufgabeneinstellungen für Multithreaded CDC-Ladevorgänge](#CHAP_Target.Timestream.CDCTaskSettings)
+ [Endpunkteinstellungen bei Verwendung von Timestream als Ziel für AWS DMS](#CHAP_Target.Timestream.ConnectionAttrib)
+ [Erstellen und Ändern eines Amazon-Timestream-Zielendpunkts](#CHAP_Target.Timestream.CreateModifyEndpoint)
+ [Verwenden der Objektzuweisung zum Migrieren von Daten zu einem Timestream-Thema](#CHAP_Target.Timestream.ObjectMapping)
+ [Einschränkungen bei der Verwendung von Amazon Timestream als Ziel für AWS Database Migration Service](#CHAP_Target.Timestream.Limitations)
## Voraussetzungen für die Verwendung von Amazon Timestream als Ziel für AWS Database Migration Service
Bevor Sie Amazon Timestream als Ziel für einrichten, stellen Sie sicher AWS DMS, dass Sie eine IAM-Rolle erstellen. Diese Rolle muss AWS DMS den Zugriff auf die Daten ermöglichen, die zu Amazon Timestream migriert werden. Die Mindestanzahl an Zugriffsberechtigungen für die Rolle, die Sie für die Migration zu Timestream verwenden, ist in der folgenden IAM-Richtlinie aufgeführt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDescribeEndpoints",
"Effect": "Allow",
"Action": [
"timestream:DescribeEndpoints"
],
"Resource": "*"
},
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"timestream:ListTables",
"timestream:DescribeDatabase"
],
"Resource": "arn:aws:timestream:us-east-1:123456789012:database/DATABASE_NAME"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"timestream:DeleteTable",
"timestream:WriteRecords",
"timestream:UpdateTable",
"timestream:CreateTable"
],
"Resource": "arn:aws:timestream:us-east-1:123456789012:database/DATABASE_NAME/table/TABLE_NAME"
}
]
}
```
------
Wenn Sie beabsichtigen, alle Tabellen zu migrieren, verwenden Sie `*` for *TABLE\$1NAME* im obigen Beispiel.
Beachten Sie Folgendes zur Verwendung von Timestream als Ziel:
+ Wenn Sie historische Daten mit Zeitstempeln aufnehmen möchten, die älter als ein Jahr sind, empfehlen wir, die Daten mit AWS DMS im .csv-Format in Amazon S3 zu schreiben. Verwenden Sie dann den Stapelladevorgang von Timestream, um die Daten in Timestream aufzunehmen. Weitere Informationen dazu finden Sie unter [Verwenden des Stapelladens in Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/batch-load.html) im [Amazon-Timestream-Entwicklerhandbuch](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
+ Für Volllast-Datenmigrationen von Daten, die weniger als ein Jahr alt sind, empfehlen wir, die Aufbewahrungsdauer der Timestream-Tabelle für den Speicher größer oder gleich dem ältesten Zeitstempel festzulegen. Sobald die Migration abgeschlossen ist, bearbeiten Sie die Speicherdauer der Tabelle zum gewünschten Wert. Gehen Sie beispielsweise wie folgt vor, um Daten zu migrieren, bei denen der älteste Zeitstempel 2 Monate alt ist:
+ Legen Sie die Speicherdauer der Timestream-Zieltabelle auf 2 Monate fest.
+ Starten Sie die Datenmigration mit AWS DMS.
+ Sobald die Datenmigration abgeschlossen ist, ändern Sie den Aufbewahrungszeitraum der Timestream-Zieltabelle auf den gewünschten Wert.
Wir empfehlen, die Speicherkosten vor der Migration anhand der Informationen auf den folgenden Seiten abzuschätzen:
+ [Amazon-Timestream-Preise](https://aws.amazon.com/timestream/pricing)
+ [AWS Preisrechner](https://calculator.aws/#/addService)
+ Für CDC-Datenmigrationen empfehlen wir, den Aufbewahrungszeitraum für den Speicher der Zieltabelle so festzulegen, dass die aufgenommenen Daten innerhalb der Aufbewahrungsgrenzen des Speichers liegen. Weitere Informationen dazu finden Sie unter [Bewährte Verfahren für Schreibvorgänge](https://docs.aws.amazon.com/timestream/latest/developerguide/data-ingest.html) im [Amazon-Timestream-Entwicklerhandbuch](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
## Aufgabeneinstellungen für vollständige Multithread-Ladevorgänge
AWS DMS Unterstützt zur Erhöhung der Geschwindigkeit der Datenübertragung eine Multithread-Migrationsaufgabe mit Volllast zu einem Timestream-Zielendpunkt mit den folgenden Aufgabeneinstellungen:
+ `MaxFullLoadSubTasks` – Geben Sie diese Option an, um die maximale Anzahl von Quelltabellen festzulegen, die parallel geladen werden sollen. DMS lädt jede Tabelle in die entsprechende Amazon-Timestream-Zieltabelle mithilfe einer dedizierten Unteraufgabe. Der Standardwert beträgt 8; der Maximalwert beträgt 49.
+ `ParallelLoadThreads`— Verwenden Sie diese Option, um die Anzahl der Threads anzugeben, die AWS DMS verwendet werden, um jede Tabelle in ihre Amazon Timestream Timestream-Zieltabelle zu laden. Der maximale Wert für ein Timestream-Ziel ist 32. Sie können eine Erhöhung dieses Höchstwerts anfordern.
+ `ParallelLoadBufferSize` – Verwenden Sie diese Option, um die maximale Anzahl der Datensätze anzugeben, die in dem Puffer gespeichert werden sollen, den die Parallellade-Threads zum Laden von Daten in das Amazon-Timestream-Ziel verwenden. Der Standardwert lautet 50. Die maximale Wert ist 1.000. Verwenden Sie diese Einstellung mit `ParallelLoadThreads`; `ParallelLoadBufferSize` ist nur gültig, wenn es mehr als einen Thread gibt.
+ `ParallelLoadQueuesPerThread` – Verwenden Sie diese Option, um die Anzahl der Warteschlangen anzugeben, auf die jeder gleichzeitige Thread zugreift, um Datensätze aus Warteschlangen zu entfernen und eine Stapellast für das Ziel zu generieren. Der Standardwert ist 1. Für Amazon-Timestream-Ziele mit verschiedenen Nutzlastgrößen beträgt der gültige Bereich jedoch 5–512 Warteschlangen pro Thread.
## Aufgabeneinstellungen für Multithreaded CDC-Ladevorgänge
AWS DMS Unterstützt die folgenden Aufgabeneinstellungen, um die CDC-Leistung zu fördern:
+ `ParallelApplyThreads`— Gibt die Anzahl gleichzeitiger Threads an, die während eines CDC-Ladevorgangs AWS DMS verwendet werden, um Datensätze an einen Timestream-Zielendpunkt zu übertragen. Der Standardwert ist 0 und der maximale Wert ist 32.
+ `ParallelApplyBufferSize` – Gibt die maximale Anzahl von Datensätzen an, die in jeder Pufferwarteschlange für gleichzeitige Threads gespeichert werden sollen, um sie während eines CDC-Ladevorgangs an einen Timestream-Zielendpunkt zu übertragen. Der Standardwert ist 100 und der Höchstwert 1 000. Verwenden Sie diese Option, wenn `ParallelApplyThreads` mehrere Threads angibt.
+ `ParallelApplyQueuesPerThread` – Gibt die Anzahl der Warteschlangen an, auf die jeder Thread zugreift, um Datensätze aus Warteschlangen zu entfernen und während des CDC eine Stapellast für einen Timestream-Endpunkt zu generieren. Der Standardwert ist 1 und der maximale Wert 512.
## Endpunkteinstellungen bei Verwendung von Timestream als Ziel für AWS DMS
Sie können Endpunkteinstellungen zur Konfiguration Ihrer Timestream-Zieldatenbank verwenden, ähnlich wie Sie zusätzliche Verbindungsattribute verwenden. Sie geben die Einstellungen an, wenn Sie den Zielendpunkt mithilfe der AWS DMS Konsole oder mithilfe des `create-endpoint` Befehls in [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), mit der `--timestream-settings '{"EndpointSetting": "value", ...}'` JSON-Syntax erstellen.
Die folgende Tabelle zeigt die Endpunkteinstellungen, die Sie mit Timestream als Ziel verwenden können.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_Target.Timestream.html)
## Erstellen und Ändern eines Amazon-Timestream-Zielendpunkts
Nachdem Sie eine IAM-Rolle erstellt und die Mindestanzahl an Zugriffsberechtigungen festgelegt haben, können Sie einen Amazon Timestream Timestream-Zielendpunkt mithilfe der AWS DMS Konsole oder mithilfe des `create-endpoint` Befehls in der mit der [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)`--timestream-settings '{"EndpointSetting": "value", ...}'`JSON-Syntax erstellen.
In den folgenden Beispielen wird erläutert, wie ein Timestream-Zielendpunkt mit der AWS CLI erstellt und geändert wird.
**Befehl „Timestream-Zielendpunkt erstellen“**
```
aws dms create-endpoint —endpoint-identifier timestream-target-demo
--endpoint-type target —engine-name timestream
--service-access-role-arn arn:aws:iam::123456789012:role/my-role
--timestream-settings
{
"MemoryDuration": 20,
"DatabaseName":"db_name",
"MagneticDuration": 3,
"CdcInsertsAndUpdates": true,
"EnableMagneticStoreWrites": true,
}
```
**Befehl „Timestream-Zielendpunkt ändern“**
```
aws dms modify-endpoint —endpoint-identifier timestream-target-demo
--endpoint-type target —engine-name timestream
--service-access-role-arn arn:aws:iam::123456789012:role/my-role
--timestream-settings
{
"MemoryDuration": 20,
"MagneticDuration": 3,
}
```
## Verwenden der Objektzuweisung zum Migrieren von Daten zu einem Timestream-Thema
AWS DMS verwendet Regeln für die Tabellenzuweisung, um Daten aus der Quelle dem Timestream-Zielthema zuzuordnen. Um Daten einem Zielthema zuzuweisen, verwenden Sie eine Art von Tabellenzuweisungsregel, die als Objektzuweisung bezeichnet wird. Mit der Objektzuweisung legen Sie fest, wie Datensätze in der Quelle den in einem Timestream-Thema veröffentlichten Datensätzen zugewiesen werden.
Timestream-Themen verfügen bis auf einen Partitionsschlüssel über keine voreingestellte Struktur.
**Anmerkung**
Sie müssen die Objektzuweisung nicht verwenden. Sie können die reguläre Tabellenzuweisung für verschiedene Transformationen verwenden. Der Partitionsschlüsseltyp folgt jedoch diesen Standardverhaltensweisen:
Der Primärschlüssel wird als Partitionsschlüssel für Volllast verwendet.
Wenn keine Aufgabeneinstellungen für die parallele Anwendung verwendet werden, wird `schema.table` als Partitionsschlüssel für CDC verwendet.
Wenn Aufgabeneinstellungen für parallele Anwendung verwendet werden, wird der Primärschlüssel als Partitionsschlüssel für CDC verwendet.
Um eine Objektzuweisungsregel zu erstellen, legen Sie `rule-type` als `object-mapping` fest. Diese Regel gibt an, welchen Objektzuweisungstyp Sie verwenden möchten. Die Struktur für die Regel lautet wie folgt.
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "id",
"rule-name": "name",
"rule-action": "valid object-mapping rule action",
"object-locator": {
"schema-name": "case-sensitive schema name",
"table-name": ""
}
}
]
}
```
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "1",
"rule-name": "timestream-map",
"rule-action": "map-record-to-record",
"target-table-name": "tablename",
"object-locator": {
"schema-name": "",
"table-name": ""
},
"mapping-parameters": {
"timestream-dimensions": [
"column_name1",
"column_name2"
],
"timestream-timestamp-name": "time_column_name",
"timestream-multi-measure-name": "column_name1or2",
"timestream-hash-measure-name": true or false,
"timestream-memory-duration": x,
"timestream-magnetic-duration": y
}
}
]
}
```
AWS DMS unterstützt derzeit `map-record-to-record` und `map-record-to-document` als einzig gültige Werte für den Parameter. `rule-action` Die `map-record-to-document` Werte `map-record-to-record` und geben an, was AWS DMS standardmäßig mit Datensätzen geschieht, die nicht in der `exclude-columns` Attributliste ausgeschlossen sind. Diese Werte wirken sich in keiner Weise auf die Attributzuweisungen aus.
Verwenden Sie `map-record-to-record` beim Migrieren aus einer relationalen Datenbank zu einem Timestream-Thema. Dieser Regeltyp verwendet den `taskResourceId.schemaName.tableName`-Wert aus der relationalen Datenbank als Partitionsschlüssel in dem Timestream-Thema und erstellt ein Attribut für jede Spalte in der Quelldatenbank. Bei Verwendung wird für jede Spalte in der Quelltabelle`map-record-to-record`, die nicht in der `exclude-columns` Attributliste aufgeführt ist, ein entsprechendes Attribut im Zielthema AWS DMS erstellt. Dieses entsprechende Attribut wird unabhängig davon erstellt, ob diese Quellspalte in einer Attributzuweisung verwendet wird oder nicht.
Eine Möglichkeit, `map-record-to-record` zu verstehen, besteht darin, sich die praktische Anwendung zu veranschaulichen. In diesem Beispiel wird davon ausgegangen, dass Sie mit einer Tabellenzeile einer relationalen Datenbank beginnen, die die folgende Struktur aufweist und die folgenden Daten enthält.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Um diese Informationen von einem Schema mit dem Namen `Test` zu einem Timestream-Thema zu migrieren, erstellen Sie Regeln, um die Daten dem Zielthema zuzuweisen. Die folgende Regel veranschaulicht die Zuweisung.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToTimestream",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
}
}
]
}
```
Nachfolgend wird das resultierende Datensatzformat bei Verwendung unserer Beispieldaten in dem Timestream-Zielthema für ein bestimmtes Timestream-Thema und einen bestimmten Partitionsschlüssel (in diesem Fall `taskResourceId.schemaName.tableName`) illustriert.
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
## Einschränkungen bei der Verwendung von Amazon Timestream als Ziel für AWS Database Migration Service
Bei der Verwendung von Amazon Timestream als Ziel gelten die folgenden Einschränkungen:
+ **Dimensionen und Zeitstempel:** Timestream verwendet die Dimensionen und Zeitstempel in den Quelldaten wie einen zusammengesetzten Primärschlüssel und ermöglicht Ihnen auch nicht, diese Werte zu ändern. Dies bedeutet: Wenn Sie den Zeitstempel oder die Dimensionen für einen Datensatz in der Quelldatenbank ändern, versucht die Timestream-Datenbank, einen neuen Datensatz zu erstellen. Es ist also möglich, dass, wenn Sie die Dimension oder den Zeitstempel eines Datensatzes so ändern, dass sie denen eines anderen vorhandenen Datensatzes entsprechen, die Werte des anderen Datensatzes AWS DMS aktualisiert werden, anstatt einen neuen Datensatz zu erstellen oder den vorherigen entsprechenden Datensatz zu aktualisieren.
+ **DDL-Befehle:** Die aktuelle Version von unterstützt AWS DMS `CREATE TABLE` nur `DROP TABLE` DDL-Befehle.
+ **Einschränkungen bei Datensätzen:** Timestream hat Einschränkungen für Datensätze wie Datensatzgröße und Maßgröße. Weitere Informationen dazu finden Sie unter [Kontingente](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) im [Amazon-Timestream-Entwicklerhandbuch](https://docs.aws.amazon.com/).
+ **Löschen von Datensätzen und Nullwerten:** Timestream unterstützt das Löschen von Datensätzen nicht. AWS DMS Löscht die entsprechenden Felder in den Datensätzen in der Timestream-Zieldatenbank, um die Migration von Datensätzen zu unterstützen, die aus der Quelle gelöscht wurden. AWS DMS ändert die Werte in den Feldern des entsprechenden Zieldatensatzes mit **0** für numerische Felder, **Null** für Textfelder und **falsch** für boolesche Felder.
+ Timestream als Ziel unterstützt keine Quellen, die keine relationalen Datenbanken (RDBMS) sind.
+ AWS DMS unterstützt Timestream nur als Ziel in den folgenden Regionen:
+ USA Ost (Nord-Virginia)
+ USA Ost (Ohio)
+ USA West (Oregon)
+ Europa (Irland)
+ Europa (Frankfurt)
+ Asien-Pazifik (Sydney)
+ Asien-Pazifik (Tokio)
+ Timestream als Ziel unterstützt die Einstellung `TargetTablePrepMode` auf `TRUNCATE_BEFORE_LOAD` nicht. Wir empfehlen, `DROP_AND_CREATE` für diese Einstellung zu verwenden.
# Verwendung von Amazon RDS for Db2 und IBM Db2 LUW als Ziel für AWS DMS
Mit () können Sie Daten von einer Db2-LUW-Datenbank auf eine Amazon RDS for Db2- oder eine lokale Db2-Datenbank migrieren. AWS Database Migration Service AWS DMS
Informationen zu Versionen von Db2 LUW, die als Ziel unterstützt werden, AWS DMS finden Sie unter. [Ziele für AWS DMS](CHAP_Introduction.Targets.md)
Sie können Secure Sockets Layer (SSL) verwenden, um Verbindungen zwischen Ihrem Db2 LUW-Endpunkt und der Replikations-Instance zu verschlüsseln. Weitere Informationen zur Verwendung von SSL mit einem Db2-LUW-Endpunkt finden Sie unter [Verwenden von SSL mit AWS Database Migration Service](CHAP_Security.SSL.md).
## Einschränkungen bei der Verwendung von Db2 LUW als Ziel für AWS DMS
Die folgenden Einschränkungen gelten bei der Verwendung der Db2 LUW-Datenbank als Ziel für. AWS DMS Zu Einschränkungen bei der Verwendung von Db2 LUW als Quelle siehe [Einschränkungen bei der Verwendung von Db2 LUW als Quelle für AWS DMS](CHAP_Source.DB2.md#CHAP_Source.DB2.Limitations).
+ AWS DMS unterstützt nur Db2 LUW als Ziel, wenn die Quelle entweder Db2 LUW oder Db2 for z/OS ist.
+ Die Verwendung von Db2 LUW als Ziel unterstützt keine Replikationen mit vollständigem LOB-Modus.
+ Die Verwendung von Db2 LUW als Ziel unterstützt den XML-Datentyp in der Vollladephase nicht. Dies ist eine Einschränkung des IBM dbload-Dienstprogramms. Weitere Informationen finden Sie unter [Das Hilfsprogramm dbload](https://www.ibm.com/docs/en/informix-servers/14.10?topic=utilities-dbload-utility) in der Dokumentation von *IBM Informix Server*.
+ AWS DMS kürzt BLOB-Felder mit Werten, die dem doppelten Anführungszeichen („) entsprechen. Dies ist eine Einschränkung des IBM dbload-Dienstprogramms.
+ AWS DMS unterstützt die Option paralleles Vollladen bei der Migration zu einem Db2-LUW-Ziel in DMS-Version 3.5.3 nicht. Diese Option ist ab DMS-Version 3.5.4 oder höher verfügbar.
## Endpunkteinstellungen bei Verwendung von Db2 LUW als Ziel für AWS DMS
Sie können Endpunkteinstellungen zum Konfigurieren Ihrer Db2-LUW-Zieldatenbank verwenden, ähnlich wie Sie zusätzliche Verbindungsattribute verwenden. Sie geben die Einstellungen an, wenn Sie den Zielendpunkt mithilfe der AWS DMS Konsole oder mithilfe des `create-endpoint` Befehls in [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), mit der `--ibm-db2-settings '{"EndpointSetting": "value", ...}'` JSON-Syntax erstellen.
Die folgende Tabelle zeigt die Endpunkteinstellungen, die Sie mit Db2 LUW als Ziel verwenden können.
| Name | Description |
| --- | --- |
| `KeepCsvFiles` | Wenn der Wert true ist, werden alle CSV-Dateien, die zur Datenreplikation verwendet wurden, auf dem Db2-LUW-Ziel AWS DMS gespeichert. DMS verwendet diese Dateien zur Analyse und Problembehandlung.. |
| `LoadTimeout` | Die Zeitspanne (in Millisekunden), bevor bei Vorgängen, die von DMS auf dem Db2-Ziel ausgeführt werden, ein AWS DMS Timeout eintritt. Der Standardwert ist 1 200 (20 Minuten). |
| `MaxFileSize` | Gibt die maximale Größe (in KB) der .csv-Dateien zum Übertragen von Daten zu Db2 LUW an. |
| `WriteBufferSize` | Die Größe (in KB) des In-Memory-Datei-Schreibpuffers, der beim Generieren von .csv-Dateien auf der lokalen Festplatte in der DMS-Replikations-Instance verwendet wird. Der Standardwert ist 1 024 (1 MB). |