-
Notifications
You must be signed in to change notification settings - Fork 515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Migration Assistant Type Mapping documentation #9164
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,189 @@ | ||
--- | ||
layout: default | ||
title: Handling type mapping deprecation | ||
nav_order: 60 | ||
parent: Planning your migration | ||
grand_parent: Migration phases | ||
redirect_from: | ||
- /migration-assistant/migration-phases/handling-type-mapping-deprecation/ | ||
--- | ||
|
||
# Handling type mapping deprecation | ||
|
||
During a migration from Elasticsearch versions 6.x and before, you may have used the type mapping feature. This page provides a cookbook of different scenarios and templates that can be used to handle these deprecations. | ||
|
||
## Understanding type mapping deprecation | ||
|
||
Elasticsearch indices created prior to 6.x could contain multiple types per index. This feature has been deprecated and removed in newer versions of Elasticsearch and OpenSearch. Because of this, during migrations, you may need to specify the behavior to occur when migrating items that used type mappings. For more details, refer to [Elasticsearch's official documentation on the removal of mapping types](https://www.elastic.co/guide/en/elasticsearch/reference/7.10/removal-of-types.html). | ||
Check failure on line 17 in _migration-assistant/migration-phases/planning-your-migration/handling-type-mapping-deprecation.md
|
||
|
||
## Handling type mapping deprecation | ||
|
||
To handle type mapping deprecation, you can leverage the built in TypeMappingsSanitizationTransformer. This transformer can be used to transform the data (metadata, documents, requests) and update the behavior accordingly. | ||
|
||
### Using the TypeMappingsSanitizationTransformer | ||
|
||
1. Navigate to the bootstrap box and open the `cdk.context.json` with vim. | ||
2. Add/Update the key `reindexFromSnapshotExtraArgs` to include `--doc-transformer-config-file /shared-logs-output/transformation.json`. [^1] | ||
Check failure on line 26 in _migration-assistant/migration-phases/planning-your-migration/handling-type-mapping-deprecation.md
|
||
3. Add/Update the key `trafficReplayerExtraArgs` to include `--transformer-config-file /shared-logs-output/transformation.json`. [^1] | ||
Check failure on line 27 in _migration-assistant/migration-phases/planning-your-migration/handling-type-mapping-deprecation.md
|
||
4. Deploy/redeploy the Migration Assistant. | ||
5. Navigate to the Migration Assistant console. | ||
6. Create a file with `vim /shared-logs-output/transformation.json`. [^1] | ||
Check failure on line 30 in _migration-assistant/migration-phases/planning-your-migration/handling-type-mapping-deprecation.md
|
||
7. Add your transformation configuration to the file (see examples below). | ||
Check warning on line 31 in _migration-assistant/migration-phases/planning-your-migration/handling-type-mapping-deprecation.md
|
||
8. When running metadata migration, run with the additional parameter `console metadata migrate --transformer-config-file /shared-logs-output/transformation.json`.[^1] | ||
Check failure on line 32 in _migration-assistant/migration-phases/planning-your-migration/handling-type-mapping-deprecation.md
|
||
9. If the transformation configuration is updated, backfill/replayer will need to be stopped and restarted to apply the changes. | ||
|
||
[^1]: The `/shared-logs-output` mount will soon be relocated with a new mountpoint on the container for the EFS volume. | ||
Check failure on line 35 in _migration-assistant/migration-phases/planning-your-migration/handling-type-mapping-deprecation.md
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we remove, what action would a reader of the document take with this note? |
||
|
||
### Configuration Options | ||
Check failure on line 37 in _migration-assistant/migration-phases/planning-your-migration/handling-type-mapping-deprecation.md
|
||
|
||
The TypeMappingsSanitizationTransformer supports several strategies for handling type mappings: | ||
|
||
1. **Route to Separate Indices**: Split different types into their own indices | ||
Check failure on line 41 in _migration-assistant/migration-phases/planning-your-migration/handling-type-mapping-deprecation.md
|
||
2. **Merge Types**: Combine multiple types into a single index | ||
3. **Drop Types**: Selectively migrate only specific types | ||
4. **Keep Original Structure**: Maintain the same index name while conforming to new type standards | ||
|
||
### Example Configurations | ||
|
||
Here are some common scenarios and their corresponding configurations: | ||
|
||
#### 1. Route Different Types to Separate Indices | ||
|
||
If you have an index `activity` with types `user` and `post` that you want to split into separate indices: | ||
|
||
```json | ||
[ | ||
{ | ||
"TypeMappingsSanitizationTransformerProvider": { | ||
"staticMappings": { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we drop this node, so its just a list of indices and the types to be mapped? |
||
"activity": { | ||
"user": "new_users", | ||
"post": "new_posts" | ||
} | ||
}, | ||
"sourceProperties": { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we remove the version here? Maybe I am missing how it is valuable for a user to pick a different version |
||
"version": { | ||
"major": 6, | ||
"minor": 8 | ||
} | ||
} | ||
} | ||
} | ||
] | ||
``` | ||
|
||
This will: | ||
- Route documents with type `user` to the `new_users` index | ||
- Route documents with type `post` to the `new_posts` index | ||
|
||
#### 2. Merge All Types into One Index | ||
|
||
To combine multiple types into a single index: | ||
|
||
```json | ||
[ | ||
{ | ||
"TypeMappingsSanitizationTransformerProvider": { | ||
"staticMappings": { | ||
"activity": { | ||
"user": "combined_activity", | ||
"post": "combined_activity" | ||
Comment on lines
+89
to
+90
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we simplify this name to |
||
} | ||
}, | ||
"sourceProperties": { | ||
"version": { | ||
"major": 6, | ||
"minor": 8 | ||
} | ||
} | ||
} | ||
} | ||
] | ||
``` | ||
|
||
#### 3. Drop Specific Types | ||
|
||
To migrate only specific types and drop others: | ||
|
||
```json | ||
[ | ||
{ | ||
"TypeMappingsSanitizationTransformerProvider": { | ||
"staticMappings": { | ||
"activity": { | ||
"user": "users_only", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So any types that are included will be dropped? That seems like an easy thing to get wrong or mistype, do we have a way to preflight this and warn users what they are doing if its by accident or is there a way we can make this more intention? {
"{index-name}": {
"mappedTypes": {
"users": "users_only"
},
"droppedTypes": [
"post"
]
}
} |
||
} | ||
}, | ||
"sourceProperties": { | ||
"version": { | ||
"major": 6, | ||
"minor": 8 | ||
} | ||
} | ||
} | ||
} | ||
] | ||
``` | ||
This configuration will only migrate documents of type `user` and ignore other types in the `activity` index. | ||
|
||
### 4. Keep original structure | ||
|
||
To migrate only specific types and keep the original structure: | ||
|
||
```json | ||
[ | ||
{ | ||
"TypeMappingsSanitizationTransformerProvider": { | ||
"regexMappings": [ | ||
[ | ||
"(.*)", | ||
".*", | ||
"$1" | ||
] | ||
Comment on lines
+138
to
+142
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please add names property names to signal what these mean |
||
], | ||
"sourceProperties": { | ||
"version": { | ||
"major": 6, | ||
"minor": 8 | ||
} | ||
} | ||
} | ||
} | ||
] | ||
``` | ||
|
||
This is equivalent to the merge all types into one index rule but using a pattern-based routing strategy. | ||
|
||
### Defaults | ||
|
||
When no regex mappings are specified, the transformer will default to the following behavior: | ||
|
||
```json | ||
{ | ||
"regexMappings": [ | ||
["(.+)", "_doc", "$1"], | ||
["(.+)", "(.+)", "$1_$2"] | ||
], | ||
} | ||
``` | ||
|
||
This has the effect of retaining the index name for es 6+ created indices while comibining the type and index name for es 5.x created indices. If you wish to retain the index name for es 5.x created indices, please use the `staticMappings` option or override the type mappings using the `regexMappings` option similar to the `Keep original structure` | ||
Check warning on line 170 in _migration-assistant/migration-phases/planning-your-migration/handling-type-mapping-deprecation.md
|
||
|
||
### Limitations | ||
|
||
- The transformer cannot be used prior to Elasticsearch 6.x. | ||
- Within the replayer, the transformer only supports a subset of requests that may be replayed with types, in particular: | ||
- PUT/POST /{index}/{type}/{id} | ||
- PUT/POST /{index}/{type}/ | ||
- GET /{index}/{type}/{id} | ||
- PUT/POST /_bulk | ||
- PUT/POST /{index} | ||
Comment on lines
+176
to
+180
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Lets turn this into a table with a leading column for the operation name such as |
||
- Within the replayer, create index split is not supported. | ||
- Note: This is only impactful on ES 5.x since multi type index creation is not supported on ES 6.x. | ||
Comment on lines
+181
to
+182
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Lets frame this like the other operations so its easier to see. If it is a known gap, we should proactively create a github issue that folks could comment / vote on and we'd leave a link here in the docs. |
||
|
||
### Important Notes | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. these important notes are at the bottom, lets see if we can better integrate them into the workflow. |
||
|
||
- After ES 6, documents either have no type or are forced to use the type `_doc` | ||
- When migrating from ES 6, some type context might not be available (e.g., during RFS operations) | ||
- The transformer can handle both explicit type mappings and pattern-based routing | ||
- Changes to the transformation configuration require restarting backfill/replayer operations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we supply an empty file at this location and adjust our defaults to pull from this location - that would shorten what a user need to do? We are adding a lot of steps that look very similar and are easy to do incorrectly.