Skip to content

Commit

Permalink
Merge pull request #5667 from EnterpriseDB/docs/edits_to_migration_to…
Browse files Browse the repository at this point in the history
…olkit_pr5803

Edits to Migration Toolkit PR5803
  • Loading branch information
gvasquezvargas authored May 22, 2024
2 parents 3ab29f2 + c0573cc commit 6061db7
Show file tree
Hide file tree
Showing 4 changed files with 29 additions and 30 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ Migration Toolkit also allows you to migrate database objects and data to an EDB
- On EDB Postgres Advanced Server, use the `-copyViaDBLinkOra` option to enable the `dblink_ora` module.
- Use the `-connRetryCount <connection_attempts>` option to specify the number of retry attempts to perform if the target database connection is lost during data migration.
- Use the `-connRetryInterval <seconds>` option to specify the seconds to wait before each target database reconnection attempt during a data migration.
- Use the `-abortConnOnFailure <true/false>` option to specify if to abort the migration when all target database reconnection attempts during a data migration fail.
- Use the `-abortConnOnFailure <true/false>` option to specify whether to abort the migration when all target database reconnection attempts fail during a data migration.
The default is `true`, which aborts the session if the connection fails after the the specified `-connRetryCount` threshold.
- Use the `-pgIdleTxSessionTimeOut <seconds>` to override the value of the PostgreSQL or EDB Postgres Advanced Server `idle_in_transaction_session_timeout` configuration option in the MTK connection session.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -422,37 +422,37 @@ Specify each entry in the file on a separate line in a key=value pair. The left

## Connection retry options

Whenever there is a connection failure with the target database during a data migration, Migration Tookit automatically attempts to reconnect to the
Whenever there's a connection failure with the target database during a data migration, Migration Tookit attempts to reconnect to the
target database to ensure the migration completes without skipping any tables. When the connection is reestablished,
Migration Toolkit restarts or resumes the data copy for the table that was being migrated when the connection was lost and then performs the data copy for the remaining tables.
Migration Toolkit restarts or resumes the data copy for the table that was being migrated when the connection was lost. It then performs the data copy for the remaining tables.

Migration Toolkit resumes the migration based on the mode that it was using to migrate the data:

- If Migration Toolkit was using Copy API to migrate the data, it continues copying data from the last failed row.
Copy API is compatible with PostgreSQL and EDB Postgres Advanced Server as target databases.

- In other data migration modes, Migration Toolkit truncates the data on the target table and re-copies the entire failed table.
- In other data migration modes, Migration Toolkit truncates the data on the target table and recopies the entire failed table.

!!!note Scope and limitations

Database scope: The connection retry capability allows Migration Toolkit to reconnect to the target database.
Retry attempts for issues with the source database are not supported.
Retry attempts for issues with the source database aren't supported.

Migration scope: This capability allows Migration Toolkit to retry migrating data.
Retry attempts for issues with the schema migration are not supported.
Retry attempts for issues with the schema migration aren't supported.

Modality scope: This reconnection capability is available with the data migration mode (`-dataOnly`).
It is also available when you run a migration **without** specifying either the `-dataOnly` or `-schemaOnly` options.
It's also available when you run a migration without specifying either the `-dataOnly` or `-schemaOnly` options.
!!!

You can specify several connection retry options:

`-connRetryCount [<connection_attempts>]`

Use the `-connRetryCount` option to specify the number of retry attempts to perform in case the target database connection fails.
The `[<connection_attempts>]` value must be a number between 0 and 50, the default is 3 retry attempts.
Use the `-connRetryCount` option to specify the number of retry attempts to perform if the target database connection fails.
The `[<connection_attempts>]` value must be a number between 0 and 50. The default is 3 retry attempts.

Since the retry applies to the migration of data, it is not compatible with the `-schemaOnly` option.
Since the retry applies to the migration of data, it isn't compatible with the `-schemaOnly` option.

Example:

Expand All @@ -463,10 +463,10 @@ $ ./runMTK.sh -connRetryCount 2 -dataOnly -tables dept,emp,jobhist public
`-connRetryInterval [<seconds>]`

Use the `-connRetryInterval` option to specify the seconds to wait before each subsequent reconnection attempt
in case the target database connection fails.
The `[<seconds>]` value must be a number between 0 and 900, the default is 30 seconds.
if the target database connection fails.
The `[<seconds>]` value must be a number between 0 and 900. The default is 30 seconds.

Since the retry applies to the migration of data, it is not compatible with the `-schemaOnly` option.
Since the retry applies to the migration of data, it isn't compatible with the `-schemaOnly` option.

Example:

Expand All @@ -476,12 +476,12 @@ $ ./runMTK.sh -connRetryCount 2 -connRetryInterval 50 -dataOnly -tables dept,emp

`-abortConnOnFailure` [true/false]`

Specify if to abort the migration if all the reconnection attempts failed.
Specify whether to abort the migration if all the reconnection attempts failed.

Set the `-abortConnOnFailure` to `false`, to skip migrating the failed table and proceed to the next table.
The default is `true`, which aborts the session if the connection fails after the the specified `-connRetryCount` threshold.
To skip migrating the failed table and proceed to the next table, set the `-abortConnOnFailure` to `false`.
The default is `true`, which aborts the session if the connection fails after the specified `-connRetryCount` threshold.

Since the retry applies to the migration of data, it is not compatible with the `-schemaOnly` option.
Since the retry applies to the migration of data, it isn't compatible with the `-schemaOnly` option.

Example:

Expand All @@ -493,7 +493,7 @@ $ ./runMTK.sh -connRetryCount 2 -connRetryInterval 50 -abortConnOnFailure false

Specify the PostgreSQL or EDB Postgres Advanced Server `idle_in_transaction_session_timeout`, which defines the time after which
the database terminates the session when a migration transaction is in idle state.
The `[<seconds>]` value should be greater than 0, and the default is 180 seconds.
`[<seconds>]` is a value greater than 0. The default is 180 seconds.

Example:

Expand Down
21 changes: 10 additions & 11 deletions product_docs/docs/migration_toolkit/55/11_questions.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -66,25 +66,24 @@ Migration scope: This capability allows Migration Toolkit to retry migrating dat
Retry attempts for issues with the schema migration are currently not supported.

Modality scope: This reconnection capability is available with the data migration mode (`-dataOnly`).
It is also available for the data migration step when you run a migration **without** specifying either the `-dataOnly` and `-schemaOnly` options.
It's also available for the data migration step when you run a migration without specifying either the `-dataOnly` and `-schemaOnly` options.

**What do I do if there is an error during a data migration that results in the data for one or more of my tables not being fully migrated?**
**What do I do if there's an error during a data migration that results in the data for one or more of my tables not being fully migrated?**

If Migration Toolkit is not able to reconnect successfully and one or more of the tables were not
If Migration Toolkit can't reconnect successfully and one or more of the tables weren't
fully migrated, restart the entire data migration (with the `-dataOnly` option) or configure Migration Toolkit
to migrate only the tables that were not fully migrated in the previous run. Note that you can use the `connRetryCount`,
to migrate only the tables that weren't fully migrated in the previous run. You can use `connRetryCount`,
`connRetryInterval`, and `abortConnOnFailure` to alter the retry configuration options.

If the source database was accepting write transactions while the previous Migration Toolkit data migration was in process,
the full (all tables) data migration should be performed again to ensure that data migrated to the destination database is in a
perform the full (all tables) data migration again to ensure that data migrated to the destination database is in a
consistent state.

If it can be confirmed that no write transactions were performed on the source database while the previous migration was being performed,
then it should be safe to migrate only those tables that had not been fully migrated.
If you can confirm that no write transactions were performed on the source database while the previous migration was being performed,
then it's safe to migrate only those tables that weren't fully migrated.

**What do I do if there is an error during a schema migration that results in not all of my schema objects being fully migrated?**
**What do I do if there's an error during a schema migration that results in not all of my schema objects being fully migrated?**

Unfortunately, reconnection for schema migration errors is not supported at this time. If Migration Toolkit is not able to migrate all
Unfortunately, reconnection for schema migration errors isn't supported at this time. If Migration Toolkit can't migrate all
schemas, restart the entire schema migration again (with the `-schemaOnly` option), or configure Migration Toolkit to migrate only
the schemas that were not fully migrated in the previous run.

the schemas that weren't fully migrated in the previous run.
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ New features, enhancements, bug fixes, and other changes in Migration Toolkit 55
|--------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|
| Enhancement | Added the ability to automatically attempt to reconnect to the target database and resume or restart the data migration of the table that was being migrated when the connection was lost. | |
| Enhancement | Migration Toolkit now allows the migration of stored `procedure` objects from a source PostgreSQL to a target PostgreSQL database. | |
| Enhancement | The exclude object capability (`-exclude` with a set of options) now supports the exclusion of subsets of `Sequences`, `Procedures`, `Functions`, `Packages`, `Synonyms`, and `Queues` from the migration. | #99271 / 31314 |
| Enhancement | The exclude object capability (`-exclude` with a set of options) now supports excluding the subsets of `Sequences`, `Procedures`, `Functions`, `Packages`, `Synonyms`, and `Queues` from the migration. | #99271 / 31314 |
| Enhancement | The connection sessions initiated by Migration Toolkit are now identifiable with an application name. This facilitates the debugging of issues relevant to a source or target database. | |
| Enhancement | Migration Toolkit now logs the names of missing tables as part of the error message when one or more tables are missing from the source database. | #98134 / 30362 |
| Bug&nbsp;fix | Fixed an issue that caused migration failures for Oracle tables containing a numeric column with an empty default clause. | #100987 / 32874 |
Expand Down

0 comments on commit 6061db7

Please sign in to comment.