' for the table to apply all the pending DDL updates. Then try the upgrade again."
}
]
}
```
La comprobación previa indica que la tabla `test.test` tiene operaciones de DDL rápido pendientes.
Para poder continuar con la actualización, puede volver a crear la tabla y, a continuación, volver a intentar la actualización.
Antes de volver a crear los espacios de tablas, consulte la sección [Online DDL operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html) en la documentación de MySQL para conocer los efectos del bloqueo y el movimiento de datos en las transacciones en primer plano.
```
mysql> optimize table test.test;
+-----------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------+----------+----------+-------------------------------------------------------------------+
| test.test | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.test | optimize | status | OK |
+-----------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.04 sec)
```
Después de volver a crear la tabla, la comprobación previa se realiza correctamente.
```
{
"id": "auroraFODUpgradeCheck",
"title": "Check for artifacts related to Aurora fast DDL feature",
"status": "OK",
"detectedProblems": []
}
```
**auroraGetDanglingFulltextIndex**
**Nivel de comprobación previa: error**
**Tablas con referencia de índice `FULLTEXT` colgante**
En las versiones anteriores a MySQL 5.6.26, era posible que, tras eliminar un índice de búsqueda de texto completo, las columnas ocultas `FTS_DOC_ID` y `FTS_DOC_ID_INDEX` quedaran huérfanas. Para obtener más información, consulte [Bug \$176012](https://bugs.mysql.com/bug.php?id=76012).
Si ha creado tablas en versiones anteriores de MySQL en las que esto haya ocurrido, puede provocar un error en las actualizaciones a la versión 3 de Aurora MySQL. Esta comprobación previa verifica que no existan índices de texto completo huérfanos o “colgantes” en el clúster de base de datos antes de actualizar a MySQL 8.0. Si se produce un error en esta comprobación previa, vuelva a crear todas las tablas que incluyan esos índices de texto completo colgantes.
**Ejemplo de salida:**
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.table_with_fts_index",
"description": "Table `test.table_with_fts_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
}
]
},
```
La comprobación previa indica que hay un error en la tabla `test.table_with_fts_index` porque incluye un índice de texto completo colgante. Para permitir que se continúe con la actualización, vuelva a crear la tabla para eliminar las tablas auxiliares del índice de texto completo. Utilice `OPTIMIZE TABLE test.table_with_fts_index` o `ALTER TABLE test.table_with_fts_index, ENGINE=INNODB`.
Después de volver a crear la tabla, se aprueba la comprobación previa.
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForDatafilePathInconsistency**
**Nivel de comprobación previa: error**
**Comprobación de si hay incoherencias relacionadas con la ruta de archivo `ibd`**
Esta comprobación previa se aplica únicamente a la versión 3.03.0 y anteriores de Aurora MySQL. Si detecta un error con esta comprobación previa, actualice a la versión 3.04 o versiones posteriores de Aurora MySQL.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForDatafilePathInconsistency",
"title": "Check for inconsistency related to ibd file path.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForFtsSpaceIdZero**
**Nivel de comprobación previa: error**
**Comprobación del índice de texto completo con el ID de espacio como cero**
En MySQL, al añadir un [índice de texto completo](https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html) a una tabla de InnoDB, se crean varios espacios de tabla de índices auxiliares. Debido a un [error](https://bugs.mysql.com/bug.php?id=72132) en las versiones anteriores de MySQL, que se ha corregido en la versión 5.6.20, era posible que estas tablas de índices auxiliares se crearan en el [espacio de tablas del sistema](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace), en lugar de hacerlo en su propio espacio de tablas de InnoDB.
Si existe alguno de estos espacios de tablas auxiliares, se producirá un error en la actualización. Vuelva a crear los índices de texto completo mencionados en el error de comprobación previa y, a continuación, vuelva a intentar la actualización.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.fts_space_zero_check",
"description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
}
]
},
```
La comprobación previa indica que hay un error en la tabla `test.fts_space_zero_check`, ya que tiene tablas auxiliares de búsqueda de texto completo (FTS) en el espacio de tablas del sistema.
Después de eliminar y volver a crear los índices de FTS asociados a esta tabla, la comprobación previa se realizará correctamente.
Antes de volver a crear los espacios de tablas, consulte la sección [Partitioning operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-partitioning) en la documentación de MySQL para comprender los efectos del bloqueo y el movimiento de datos en las transacciones en primer plano.
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForIncompleteXATransactions**
**Nivel de comprobación previa: error**
**Comprobación de si las transacciones de XA están preparadas**
Mientras se ejecuta el proceso de actualización de la versión principal, es esencial que la instancia de base de datos de la versión 2 de Aurora MySQL se [cierre por completo](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown). Esto garantiza que todas las transacciones se confirmen o se reviertan y que InnoDB haya purgado todos los registros de deshacer. Como la reversión de las transacciones es necesaria, si la base de datos tiene alguna [transacción de XA](https://dev.mysql.com/doc/refman/5.7/en/xa.html) preparada, puede impedir que se cierre por completo. Por este motivo, si se detecta alguna transacción de XA preparada, no se podrá continuar con la actualización hasta que se tomen medidas para confirmarla o revertirla.
Para obtener más información sobre cómo detectar transacciones de XA preparadas con `XA RECOVER`, consulte la sección [XA Transaction SQL Statements](https://dev.mysql.com/doc/refman/5.7/en/xa-statements.html) en la documentación de MySQL. Para obtener más información sobre los estados de las transacciones de XA, consulte la sección [XA Transaction States](https://dev.mysql.com/doc/refman/5.7/en/xa-states.html) en la documentación de MySQL.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForIncompleteXATransactions",
"title": "Pre-checks for XA Transactions in prepared state.",
"status": "OK",
"description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions."
}
]
}
```
Esta comprobación previa indica que hay un error porque hay transacciones preparadas que deben confirmarse o revertirse.
Tras iniciar sesión en la base de datos, puede consultar la tabla [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) y el resultado `XA RECOVER` para obtener más información.
Antes de confirmar o revertir una transacción, le recomendamos que revise la [documentación de MySQL](https://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html) y los requisitos de la aplicación.
```
mysql> select trx_started,
trx_mysql_thread_id,
trx_id,trx_state,
trx_operation_state,
trx_rows_modified,
trx_rows_locked
from
information_schema.innodb_trx;
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| trx_started | trx_mysql_thread_id | trx_id | trx_state | trx_operation_state | trx_rows_modified | trx_rows_locked |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| 2024-08-12 01:09:39 | 0 | 2849470 | RUNNING | NULL | 1 | 0 |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
1 row in set (0.00 sec)
mysql> xa recover;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data |
+----------+--------------+--------------+--------+
| 1 | 6 | 0 | xatest |
+----------+--------------+--------------+--------+
1 row in set (0.00 sec)
```
En este caso, revertimos la transacción preparada.
```
mysql> XA ROLLBACK 'xatest';
Query OK, 0 rows affected (0.00 sec)
v
mysql> xa recover;
Empty set (0.00 sec)
```
Una vez que se ha revertido la transacción de XA, la comprobación previa se realizará correctamente.
```
{
"id": "auroraUpgradeCheckForIncompleteXATransactions",
"title": "Pre-checks for XA Transactions in prepared state.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInstanceLimit**
**Nivel de comprobación previa: error**
**Comprobación de si la clase de instancia actual admite la actualización**
Por el momento, no se puede ejecutar una actualización local desde la versión 2.12.0 o 2.12.1 de Aurora MySQL, donde la [clase de instancia de base de datos](Concepts.DBInstanceClass.md) de escritor sea db.r6i.32xlarge. En este caso, la comprobación previa devuelve un error. Para poder continuar con la actualización, puede cambiar la clase de la instancia de base de datos a db.r6i.24xlarge o a una inferior. También puede actualizar a la versión 2.12.2 de Aurora MySQL, o una versión posterior, donde db.r6i.32xlarge admite la actualización local a la versión 3 de Aurora MySQL.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForInstanceLimit",
"title": "Checks if upgrade is supported on the current instance class",
"status": "OK",
"description": "Upgrade from Aurora Version 2.12.0 and 2.12.1 may fail for 32.xl and above instance class.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Upgrade is not supported on this instance size for Aurora MySql Version 2.12.1. Before upgrading to Aurora MySql 3, please consider either: 1. Changing the instance class to 24.xl or lower. -or- 2. Upgrading to patch version 2.12.2 or higher."
}
]
},
```
La comprobación previa devuelve un error porque la instancia de base de datos de escritor utiliza la clase de instancia db.r6i.32xlarge y se ejecuta en la versión 2.12.1 de Aurora MySQL.
**auroraUpgradeCheckForInternalUsers**
**Nivel de comprobación previa: error**
**Comprobación de si hay usuarios internos de la versión 8.0**
Esta comprobación previa se aplica únicamente a la versión 3.03.0 y anteriores de Aurora MySQL. Si detecta un error con esta comprobación previa, actualice a la versión 3.04 o versiones posteriores de Aurora MySQL.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForInternalUsers",
"title": "Check for 8.0 internal users.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForMasterUser**
**Nivel de comprobación previa: error**
**Comprobación de si existe el usuario maestro de RDS**
MySQL 8 ha añadido un nuevo modelo de privilegios con soporte de [rol](https://dev.mysql.com/doc/refman/8.0/en/roles.html) y [privilegios dinámicos](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#static-dynamic-privileges) para hacer que la administración de privilegios sea más fácil y detallada. Como parte de este cambio, Aurora MySQL ha introducido el nuevo `rds_superuser_role`, que se otorga automáticamente al usuario maestro de la base de datos al actualizar de la versión 2 a la versión 3 de Aurora MySQL.
Para obtener más información sobre los roles y privilegios asignados al usuario maestro en Aurora MySQL, consulte [Privilegios de la cuenta de usuario maestro](UsingWithRDS.MasterAccounts.md). Para obtener más información sobre el modelo de privilegios basado en roles de la versión 3 de Aurora MySQL, consulte [Modelo de privilegios basado en roles](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
Esta comprobación previa verifica que el usuario maestro existe en la base de datos. Si el usuario maestro no existe, se producirá un error en la comprobación previa. Para poder continuar con la actualización, vuelva a crear el usuario maestro. Para ello, restablezca la contraseña del usuario maestro o cree manualmente el usuario. A continuación, vuelva a intentar la actualización. Para obtener más información sobre cómo restablecer la contraseña del usuario maestro, consulte [Cambio de la contraseña del usuario maestro de la base de datos](Aurora.Modifying.md#Aurora.Modifying.Password).
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForMasterUser",
"title": "Check if master user exists",
"status": "OK",
"description": "Throws error if master user has been dropped!",
"documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Your Master User on host '%' has been dropped. To proceed with the upgrade, recreate the master user `reinvent` on default host '%'"
}
]
}
```
Tras restablecer la contraseña del usuario maestro, se aprobará la comprobación previa y podrá volver a intentar la actualización.
En el siguiente ejemplo se utiliza la AWS CLI para restablecer la contraseña. Los cambios de contraseña se aplican inmediatamente.
```
aws rds modify-db-cluster \
--db-cluster-identifier my-db-cluster \
--master-user-password my-new-password
```
A continuación, la comprobación previa se realiza correctamente.
```
{
"id": "auroraUpgradeCheckForMasterUser",
title": "Check if master user exists",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForPrefixIndexOnGeometryColumns**
**Nivel de comprobación previa: error**
**Comprobación de si hay columnas geométricas en los índices de prefijos**
A partir de la [versión 8.0.12 de MySQL](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-12.html#mysqld-8-0-12-spatial-support), ya no se puede crear un índice [con prefijo](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) en una columna con el tipo de datos [GEOMETRY](https://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html). Para obtener más información, consulte [WL\$111808](https://dev.mysql.com/worklog/task/?id=11808).
Si existe alguno de estos índices, se producirá un error en la actualización. Para resolver el problema, elimine los índices con prefijo de `GEOMETRY` en las tablas mencionadas en el error de la comprobación previa.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"description": "Consider dropping the prefix Indexes of geometry columns and restart the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.geom_index_prefix",
"description": "Table `test`.`geom_index_prefix` has an index `LatLon` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `LatLon` ON `test`.`geom_index_prefix`;"
}
]
}
```
La comprobación previa indica que hay un error porque la tabla `test.geom_index_prefix` incluye un índice con un prefijo en una columna `GEOMETRY`.
Tras eliminar este índice, la comprobación previa se realizará correctamente.
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForSpecialCharactersInProcedures**
**Nivel de comprobación previa: error**
**Comprobación de si hay incoherencias relacionadas con los caracteres especiales en los procedimientos almacenados**
En las versiones anteriores a MySQL 8.0, los nombres de bases de datos, los nombres de tablas y otros objetos correspondían a los archivos del directorio de datos, como, por ejemplo, los metadatos basados en archivos. Como parte de la actualización a MySQL 8.0, todos los objetos de la base de datos se migran a las nuevas tablas del diccionario de datos interno que se almacenan en el esquema de `mysql` para admitir el [Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) recientemente implementado. Como parte de la migración de los procedimientos almacenados, la definición y el cuerpo del procedimiento se validan a medida que se van incorporando al nuevo diccionario de datos.
En las versiones anteriores a MySQL 8, era posible, en algunos casos, crear rutinas almacenadas o insertar directamente en la tabla `mysql.proc` procedimientos que incluían caracteres especiales. Por ejemplo, se podía crear un procedimiento almacenado que incluyera un comentario con el [carácter de espacio no divisible](https://en.wikipedia.org/wiki/Non-breaking_space) y no compatible `\xa0`. Si se detecta alguno de estos procedimientos, se producirá un error en la actualización.
Esta comprobación previa valida que los cuerpos y las definiciones de los procedimientos almacenados no incluyan dichos caracteres. Para poder continuar con la actualización, vuelva a crear estos procedimientos almacenados sin ningún carácter oculto ni especial.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"description": "Following procedure(s) has special characters inconsistency.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "information_schema.routines",
"description": "Data Dictionary Metadata is inconsistent for the procedure `get_version_proc` in the database `test` due to usage of special characters in procedure body. To avoid that, drop and recreate the procedure without any special characters before proceeding with the Upgrade."
}
]
}
```
La comprobación previa indica que el clúster de base de datos incluye un procedimiento denominado `get_version_proc` en la base de datos de `test` que incluye caracteres especiales en el cuerpo del procedimiento.
Tras eliminar y volver a crear el procedimiento almacenado, la comprobación previa se realiza correctamente, lo que permite continuar con la actualización.
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForSysSchemaObjectTypeMismatch**
**Nivel de comprobación previa: error**
**Comprobación de si el tipo de objeto no coincide con el esquema `sys`**
El [esquema sys](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html) es un conjunto de objetos y vistas en una base de datos de MySQL que ayuda a los usuarios a solucionar problemas, optimizar y supervisar las instancias de base de datos. Al realizar una actualización de la versión principal de la versión 2 a la versión 3 de Aurora MySQL, las vistas del esquema `sys` se vuelven a crear y actualizar a las nuevas definiciones de la versión 3 de Aurora MySQL.
Como parte de la actualización, si algún objeto del esquema `sys` se define mediante motores de almacenamiento (`sys_config/BASE TABLE` en [INFORMATION\$1SCHEMA.TABLES](https://dev.mysql.com/doc/refman/5.7/en/information-schema-tables-table.html)) y no mediante vistas, se producirá un error en la actualización. Estas tablas pueden encontrarse en la tabla `information_schema.tables`. Este no es el comportamiento esperado, pero en algunos casos puede ocurrir debido a un error del usuario.
Esta comprobación previa valida todos los objetos del esquema `sys` para garantizar que utilizan las definiciones de tabla correctas y que las vistas no se definen erróneamente como tablas de InnoDB o MyISAM. Para resolver el problema, corrija manualmente los objetos devueltos cambiándoles el nombre o eliminándolos. A continuación, vuelva a intentar la actualización.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"description": "Database contains objects with type mismatch for sys schema.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "sys.waits_global_by_latency",
"description": "Your object sys.waits_global_by_latency has a type mismatch. To fix the inconsistency we recommend to rename or remove the object before upgrading (use RENAME TABLE command). "
}
]
}
```
La comprobación previa indica que la vista [sys.waits\$1global\$1by\$1latency](https://dev.mysql.com/doc/refman/5.7/en/sys-waits-global-by-latency.html) del esquema `sys` presenta una discrepancia de tipos que impide que se continúe con la actualización.
Tras iniciar sesión en la instancia de base de datos, puede ver que este objeto se define como una tabla de InnoDB, cuando debería ser una vista.
```
mysql> show create table sys.waits_global_by_latency\G
*************************** 1. row ***************************
Table: waits_global_by_latency
Create Table: CREATE TABLE `waits_global_by_latency` (
`events` varchar(128) DEFAULT NULL,
`total` bigint(20) unsigned DEFAULT NULL,
`total_latency` text,
`avg_latency` text,
`max_latency` text
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
```
Para resolver este problema, podemos eliminar y volver a crear la vista con la [definición correcta](https://github.com/mysql/mysql-server/blob/mysql-5.7.44/scripts/sys_schema/views/p_s/waits_global_by_latency.sql) o cambiarle el nombre. Durante el proceso de actualización, se creará automáticamente con la definición de tabla correcta.
```
mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)
```
Una vez hecho esto, se aprueba la comprobación previa.
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForViewColumnNameLength**
**Nivel de comprobación previa: error**
**Comprobación del límite superior del nombre de columna en la vista**
La [longitud máxima permitida de un nombre de columna](https://dev.mysql.com/doc/refman/5.7/en/identifier-length.html) en MySQL es de 64 characters. En las versiones anteriores a MySQL 8.0, en algunos casos era posible crear una vista con un nombre de columna de más de 64 caracteres. Si existe alguna de estas vistas en la instancia de la base de datos, se mostrará un error de comprobación previa y no se realizará correctamente la actualización. Para poder continuar con la actualización, debe volver a crear las vistas en cuestión, asegurándose de que la longitud de sus columnas sea inferior a 64 caracteres. A continuación, vuelva a intentar la actualización.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"description": "Following view(s) has column(s) with length greater than 64.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.colname_view_test.col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad",
"description": "View `test`.`colname_view_test`has column `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` with invalid column name length. To avoid Upgrade errors, view should be altered by renaming the column name so that its length is not 0 and doesn't exceed 64."
}
]
}
```
La comprobación previa indica que la vista `test.colname_view_test` incluye una columna `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` que supera la longitud máxima permitida de 64 caracteres.
Si observamos la definición de la vista, podemos ver la columna problemática.
```
mysql> desc `test`.`colname_view_test`;
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| col1 | varchar(20) | YES | | NULL | |
| col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad | int(11) | YES | | NULL | |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
```
Para poder continuar con la actualización, vuelva a crear la vista y asegúrese de que la longitud de la columna no supere los 64 caracteres.
```
mysql> drop view `test`.`colname_view_test`;
Query OK, 0 rows affected (0.01 sec)
mysql> create view `test`.`colname_view_test`(col1, col2_nopad) as select inf, fodcol from test;
Query OK, 0 rows affected (0.01 sec)
mysql> desc `test`.`colname_view_test`;
+------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| col1 | varchar(20) | YES | | NULL | |
| col2_nopad | int(11) | YES | | NULL | |
+------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
```
Una vez hecho esto, la comprobación previa se realizará correctamente.
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckIndexLengthLimitOnTinyColumns**
**Nivel de comprobación previa: error**
**Comprobación de si hay tablas con índices definidos con una longitud de prefijo superior a 255 bytes en columnas pequeñas**
Al crear un índice en una columna con un [tipo de datos binario](https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html) en MySQL, debe añadir una longitud de [prefijo](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) en la definición del índice. En las versiones anteriores a MySQL 8.0, en algunos casos era posible especificar una longitud de prefijo superior al tamaño máximo permitido para estos tipos de datos. Un ejemplo son las columnas `TINYTEXT` y `TINYBLOB`, en las que el tamaño máximo de datos permitido es de 255 bytes, pero se permitían prefijos de índice mayores. Para obtener más información, consulte la sección [InnoDB limits](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) en la documentación de MySQL.
Si esta comprobación previa no se realiza correctamente, elimine el índice problemático o reduzca la longitud del prefijo de las columnas `TINYTEXT` y `TINYBLOB` del índice a menos de 255 bytes. A continuación, vuelva a intentar la actualización.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"description": "Prefix length of the indexes defined on tiny columns cannot exceed 255 bytes. With utf8mb4 char set, this limits the prefix length supported upto 63 characters only. A larger prefix length was allowed in MySQL5.7 using innodb_large_prefix parameter. This parameter is deprecated in MySQL 8.0.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html, https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.tintxt_prefixed_index.col1",
"description": "Index 'PRIMARY' on tinytext/tinyblob column `col1` of table `test.tintxt_prefixed_index` is defined with prefix length exceeding 255 bytes. Reduce the prefix length to <=255 bytes depending on character set used. For utf8mb4, it should be <=63."
}
]
}
```
La comprobación previa indica que hay un error en la tabla `test.tintxt_prefixed_index`, ya que tiene un índice `PRIMARY` con un prefijo superior a 255 bytes en una columna TINYTEXT o TINYBLOB.
Si observamos la definición de esta tabla, podemos ver que la clave principal tiene el prefijo 65 en la columna `TINYTEXT` `col1`. Dado que la tabla se define mediante el conjunto de caracteres `utf8mb4`, que almacena 4 bytes por carácter, el prefijo supera el límite de 255 bytes.
```
mysql> show create table `test`.`tintxt_prefixed_index`\G
*************************** 1. row ***************************
Table: tintxt_prefixed_index
Create Table: CREATE TABLE `tintxt_prefixed_index` (
`col1` tinytext NOT NULL,
`col2` tinytext,
`col_id` tinytext,
PRIMARY KEY (`col1`(65))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC
1 row in set (0.00 sec)
```
Si se modifica el prefijo del índice a 63 mientras se utiliza el conjunto de caracteres `utf8mb4`, se podrá continuar con la actualización.
```
mysql> alter table `test`.`tintxt_prefixed_index` drop PRIMARY KEY, ADD PRIMARY KEY (`col1`(63));
Query OK, 0 rows affected (0.04 sec)
Records: 0 Duplicates: 0 Warnings: 0
```
Una vez hecho esto, la comprobación previa se realizará correctamente.
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable**
**Nivel de comprobación previa: error**
**Comprobación de la incoherencia de los metadatos de InnoDB que faltan en la tabla `mysql.host`**
Se trata de una comprobación previa exclusivamente interna llevada a cabo por el servicio de RDS. Los errores se gestionarán automáticamente en la actualización y pueden omitirse de forma segura.
Si detecta algún error con esta comprobación previa, abra un caso con [AWS Support](https://aws.amazon.com/support) para solicitar que se resuelva la incoherencia de los metadatos. También puede volver a intentar la actualización. Para ello, debe realizar un volcado lógico y, a continuación, restaurar a un nuevo clúster de base de datos que ejecute la versión 3 de Aurora MySQL.
**auroraUpgradeCheckForInvalidUtf8mb3ColumnComments**
**Nivel de comprobación previa: error**
**Comprobación de si hay comentarios de columnas utf8mb3 no válidos**
Esta comprobación previa identifica las tablas que contienen comentarios de columnas con una codificación de caracteres utf8mb3 no válida. En MySQL 8.0, se aplica una validación más estricta a la codificación de caracteres en los metadatos, incluidos los comentarios de las columnas. Si algún comentario de columna contiene caracteres que no son válidos en el conjunto de caracteres utf8mb3, la actualización producirá un error.
La causa más común de este problema es la presencia de caracteres que no pertenecen a BMP (Plano Básico Multilingüe) en los comentarios de las columnas. Los caracteres que no pertenecen al BMP requieren codificación UTF-8 de 4 bytes (utf8mb4), pero utf8mb3 solo admite secuencias de 3 bytes, que no pueden representar estos caracteres.
Para resolver este problema, debe modificar los comentarios de las columnas para eliminar o reemplazar los caracteres que no pertenezcan al BMP antes de intentar la actualización. Puede usar la instrucción `ALTER TABLE` para actualizar los comentarios de las columnas.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.t2",
"description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
}
```
La comprobación previa indica que la tabla `test.t2` contiene caracteres utf8mb3 no válidos en uno o más comentarios de columna, específicamente debido a la presencia de caracteres que no son del BMP.
Para resolver este problema, puede identificar las columnas problemáticas y actualizar sus comentarios. Primero, examine la estructura de la tabla para identificar las columnas con comentarios:
```
mysql> SHOW CREATE TABLE test.t2\G
```
Una vez que haya identificado las columnas con comentarios problemáticos, actualícelas mediante la instrucción `ALTER TABLE`. Por ejemplo:
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';
```
Alternativamente, puede eliminar el comentario por completo:
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';
```
Tras actualizar todos los comentarios problemáticos de las columnas, se aprobará la comprobación previa y la actualización podrá continuar:
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
Antes de modificar los comentarios de las columnas, asegúrese de que cualquier código de aplicación o documentación que se base en estos comentarios se actualice en consecuencia. Considere la posibilidad de migrar al conjunto de caracteres utf8mb4 para mejorar la compatibilidad con Unicode si la aplicación requiere caracteres que no sean del BMP.
## Advertencias
Las siguientes comprobaciones previas generan advertencias cuando se produce un error en la comprobación previa, pero se puede continuar con la actualización.
**Topics**
+ [Comprobaciones previas de MySQL que informan de advertencias](#precheck-descriptions-warnings.mysql)
+ [Comprobaciones previas de Aurora MySQL que informan de advertencias](#precheck-descriptions-warnings.aurora)
### Comprobaciones previas de MySQL que informan de advertencias
Las siguientes comprobaciones previas proceden de Community MySQL:
+ [defaultAuthenticationPlugin](#defaultAuthenticationPlugin)
+ [maxdbFlagCheck](#maxdbFlagCheck)
+ [mysqlDollarSignNameCheck](#mysqlDollarSignNameCheck)
+ [reservedKeywordsCheck](#reservedKeywordsCheck)
+ [utf8mb3Check](#utf8mb3Check)
+ [zeroDatesCheck](#zeroDatesCheck)
**defaultAuthenticationPlugin**
**Nivel de comprobación previa: advertencia**
**Aspectos a tener en cuenta sobre el nuevo complemento de autenticación predeterminado**
En MySQL 8.0, se ha introducido el complemento de autenticación `caching_sha2_password`, que proporciona un cifrado de contraseñas más seguro y un mejor rendimiento que el complemento obsoleto `mysql_native_password`. En el caso de la versión 3 de Aurora MySQL, el complemento de autenticación predeterminado que se usa para los usuarios de bases de datos es `mysql_native_password`.
Esta comprobación previa advierte que este complemento se eliminará y se cambiará el predeterminado en una futura versión principal. Plantéese la posibilidad de evaluar la compatibilidad de los clientes y usuarios de la aplicación antes de realizar este cambio.
Para obtener más información, consulte la sección [caching\$1sha2\$1password Compatibility Issues and Solutions](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues) en la documentación de MySQL.
**Ejemplo de salida:**
```
{
"id": "defaultAuthenticationPlugin",
"title": "New default authentication plugin considerations",
"description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection authentication). However, it also has compatibility implications that may affect existing MySQL installations. If your MySQL installation must serve pre-8.0 clients and you encounter compatibility issues after upgrading, the simplest way to address those issues is to reconfigure the server to revert to the previous default authentication plugin (mysql_native_password). For example, use these lines in the server option file:\n\n[mysqld]\ndefault_authentication_plugin=mysql_native_password\n\nHowever, the setting should be viewed as temporary, not as a long term or permanent solution, because it causes new accounts created with the setting in effect to forego the improved authentication security.\nIf you are using replication please take time to understand how the authentication plugin changes may impact you.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication"
},
```
**maxdbFlagCheck**
**Nivel de comprobación previa: advertencia**
**Uso de un indicador de `MAXDB` obsoleto de `sql_mode`**
En MySQL 8.0, se han [eliminado](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) una serie de opciones de variables del sistema [sql\$1mode](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode); una de ellos era `MAXDB`. Esta comprobación previa examina todas las sesiones actualmente conectadas, junto con las rutinas y los desencadenadores, para garantizar que ninguna de ellas tenga el parámetro `sql_mode` establecido en ninguna combinación que incluya `MAXDB`.
**Ejemplo de salida:**
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"description": "Warning: The following DB objects have the obsolete MAXDB option persisted for sql_mode, which will be cleared during the upgrade. It can potentially change the datatype DATETIME into TIMESTAMP if it is used inside object's definition, and this in turn can change the behavior in case of dates earlier than 1970 or later than 2037. If this is a concern, please redefine these objects so that they do not rely on the MAXDB flag before running the upgrade.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.maxdb_stored_routine",
"description": "PROCEDURE uses obsolete MAXDB sql_mode",
"dbObjectType": "Routine"
}
]
}
```
La comprobación previa indica que la rutina `test.maxdb_stored_routine` incluye una opción `sql_mode` no compatible.
Tras iniciar sesión en la base de datos, podrá ver la definición de rutina en la que `sql_mode` incluye `MAXDB`.
```
> SHOW CREATE PROCEDURE test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,MAXDB,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
Para resolver el problema, vuelva a crear el procedimiento después de configurar el parámetro `sql_mode` correcto en el cliente.
Según la [documentación de MySQL](https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html), MySQL almacena la configuración de `sql_mode` que está en vigor cuando se crea o modifica una rutina. Siempre ejecuta la rutina con esta configuración, independientemente de la configuración de `sql_mode` cuando se inicia la rutina.
Antes de cambiar `sql_mode`, consulte la sección [Server SQL Modes](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html) en la documentación de MySQL. Evalúe detenidamente cualquier posible impacto que esto pueda tener en la aplicación.
Vuelva a crear el procedimiento sin el parámetro `sql_mode` no compatible.
```
mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
-> SQL SECURITY DEFINER
-> BEGIN
-> SELECT * FROM test;
-> END$$
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
La comprobación previa se realiza correctamente.
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"detectedProblems": []
}
```
**mysqlDollarSignNameCheck**
**Nivel de comprobación previa: advertencia**
**Comprobación de si el uso de signos de dólar únicos está obsoleto en los nombres de objetos**
A partir de la [versión 8.0.32 de MySQL](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-32.html#mysqld-8-0-32-deprecation-removal), el uso del signo de dólar (`$`) como primer carácter de un identificador sin comillas está obsoleto. Si tiene algún esquema, tabla, vista, columna o rutina que incluya un `$` como primer carácter, esta comprobación previa mostrará una advertencia. Si bien esta advertencia no impide que se lleve a cabo la actualización, le recomendamos que tome medidas para resolverlo lo antes posible. A partir de [MySQL 8.4](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html), cualquier identificador de este tipo devolverá un error de sintaxis en lugar de una advertencia.
**Ejemplo de salida:**
```
{
"id": "mysqlDollarSignNameCheck",
"title": "Check for deprecated usage of single dollar signs in object names",
"status": "OK",
"description": "Warning: The following objects have names with deprecated usage of dollar sign ($) at the begining of the identifier. To correct this warning, ensure, that names starting with dollar sign, also end with it, similary to quotes ($example$). ",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.$deprecated_syntx",
"description": " name starts with $ sign."
}
]
},
```
La comprobación previa muestra una advertencia porque la tabla `$deprecated_syntx` del esquema `test` incluye un `$` como primer carácter.
**reservedKeywordsCheck**
**Nivel de comprobación previa: advertencia**
**Uso de objetos de base de datos con nombres que entran en conflicto con las nuevas palabras clave reservadas**
Esta comprobación es similar a la de [routineSyntaxCheck](#routineSyntaxCheck), ya que comprueba el uso de objetos de base de datos cuyos nombres entran en conflicto con las nuevas palabras clave reservadas. Aunque no impiden las actualizaciones, es necesario evaluar detenidamente las advertencias.
**Ejemplo de salida:**
Si utilizamos el ejemplo anterior con la tabla denominada `except`, la comprobación previa mostrará una advertencia:
```
{
"id": "reservedKeywordsCheck",
"title": "Usage of db objects with names conflicting with new reserved keywords",
"status": "OK",
"description": "Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.",
"documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.except",
"description": "Table name",
"dbObjectType": "Table"
}
]
}
```
Esta advertencia le permite saber que es posible que haya que revisar algunas consultas de la aplicación. Si las consultas de la aplicación no [aplican correctamente caracteres de escape a los literales de cadena](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html), es posible que se produzcan errores después de actualizar a MySQL 8.0. Revise las aplicaciones para confirmar esto y compruébelas con un clon o una instantánea del clúster de base de datos de Aurora MySQL que se ejecute en la versión 3.
Ejemplo de una consulta de aplicación a la que no se le hayan aplicado caracteres de escape que no se realizará tras la actualización:
```
SELECT * FROM escape;
```
Ejemplo de una consulta de aplicación a la que se le hayan aplicado correctamente caracteres de escape que se realizará tras la actualización:
```
SELECT * FROM 'escape';
```
**utf8mb3Check**
**Nivel de comprobación previa: advertencia**
**Uso del conjunto de caracteres `utf8mb3`**
En MySQL 8.0, el conjunto de caracteres `utf8mb3` está obsoleto y se eliminará en una futura versión principal de MySQL. Esta comprobación previa se implementa para emitir una advertencia si se detecta algún objeto de la base de datos que utilice este conjunto de caracteres. Si bien esto no impedirá que se continúe con la actualización, le recomendamos encarecidamente que piense en migrar las tablas al conjunto de caracteres `utf8mb4`, que es el predeterminado a partir de MySQL 8.0. Para obtener más información sobre [utf8mb3](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html) y [utf8mb4](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html), consulte [Converting between 3-byte and 4-byte Unicode character sets](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) en la documentación de MySQL.
**Ejemplo de salida:**
```
{
"id": "utf8mb3",
"title": "Usage of utf8mb3 charset",
"status": "OK",
"description": "Warning: The following objects use the deprecated utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support. The utf8mb3 character is subject to removal in the future.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.t1.col1",
"description": "column's default character set: utf8",
"dbObjectType": "Column"
},
{
"level": "Warning",
"dbObject": "test.t1.col2",
"description": "column's default character set: utf8",
"dbObjectType": "Column"
}
]
}
```
Para resolver este problema, vuelva a crear los objetos y las tablas a los que se ha hecho referencia. Para obtener más información y conocer los requisitos previos antes de hacerlo, consulte la sección [Converting between 3-byte and 4-byte Unicode character sets](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) en la documentación de MySQL.
**zeroDatesCheck**
**Nivel de comprobación previa: advertencia**
**Valores cero de fecha, fecha y hora y marca de tiempo**
MySQL ahora aplica reglas más estrictas con respecto al uso de valores cero en las columnas de fecha, fecha y hora y marca de tiempo. Le recomendamos que utilice los modos `NO_ZERO_IN_DATE` y `NO_ZERO_DATE SQL` junto con el modo `strict`, ya que se fusionarán con el modo `strict` en una versión futura de MySQL.
Si la configuración de `sql_mode` de alguna de las conexiones de la base de datos, en el momento de ejecutar la comprobación previa, no incluye estos modos, aparecerá una advertencia en la comprobación previa. Es posible que los usuarios aún puedan insertar los valores de fecha, fecha y hora y marca de tiempo que incluyan valores cero. Sin embargo, recomendamos encarecidamente sustituir los valores cero por valores válidos, ya que su comportamiento podría cambiar en el futuro y puede que no funcionen correctamente. Como se trata de una advertencia, no impedirá las actualizaciones, pero le recomendamos que empiece a planificar las medidas necesarias.
**Ejemplo de salida:**
```
{
"id": "zeroDatesCheck",
"title": "Zero Date, Datetime, and Timestamp values",
"status": "OK",
"description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
"documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "global.sql_mode",
"description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
},
{
"level": "Warning",
"dbObject": "session.sql_mode",
"description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
}
]
}
```
### Comprobaciones previas de Aurora MySQL que informan de advertencias
Las siguientes comprobaciones previas son específicas de Aurora MySQL:
+ [auroraUpgradeCheckForRollbackSegmentHistoryLength](#auroraUpgradeCheckForRollbackSegmentHistoryLength)
+ [auroraUpgradeCheckForUncommittedRowModifications](#auroraUpgradeCheckForUncommittedRowModifications)
**auroraUpgradeCheckForRollbackSegmentHistoryLength**
**Nivel de comprobación previa: advertencia**
**Comprueba si la longitud de la lista del historial de segmentos de reversión del clúster es alta**
Tal y como se ha mencionado en [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions), mientras se ejecuta el proceso de actualización de la versión principal, es esencial que la instancia de base de datos de la versión 2 de Aurora MySQL [se cierre por completo](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown). Esto garantiza que todas las transacciones se confirmen o se reviertan y que InnoDB haya purgado todos los registros de deshacer.
Si el clúster de base de datos tiene una longitud de la lista del historial (HLL) de segmentos de reversión larga, puede prolongarse el tiempo que InnoDB tarda en completar la purga de los registros de deshacer, lo que provoca un tiempo de inactividad prolongado durante el proceso de actualización de la versión principal. Si la comprobación previa detecta que la HLL del clúster de base de datos es larga, se generará una advertencia. Si bien esto no impide que se continúe con la actualización, le recomendamos que supervise de cerca la HLL del clúster de base de datos. Al mantenerla en niveles bajos, se reducirá el tiempo de inactividad necesario durante una actualización de la versión principal. Para obtener más información sobre la supervisión de HLL, consulte [La longitud de la lista de historial de InnoDB ha aumentado de forma significativa](proactive-insights.history-list.md).
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForRollbackSegmentHistoryLength",
"title": "Checks if the rollback segment history length for the cluster is high",
"status": "OK",
"description": "Rollback Segment History length is greater than 1M. Upgrade may take longer time.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "information_schema.innodb_metrics",
"description": "The InnoDB undo history list length('trx_rseg_history_len') is 82989114. Upgrade may take longer due to purging of undo information for old row versions."
}
]
}
```
La comprobación previa devuelve una advertencia porque ha detectado que la HLL de deshacer de InnoDB era larga en el clúster de la base de datos (82989114). Aunque se continúe con la actualización, en función de la cantidad de operaciones de deshacer que se deba purgar, puede prolongar el tiempo de inactividad necesario durante el proceso de actualización.
Le recomendamos que [investigue las transacciones abiertas](proactive-insights.history-list.md) en el clúster de base de datos antes de ejecutar la actualización en producción para asegurarse de que la HLL se mantenga en un tamaño manejable.
**auroraUpgradeCheckForUncommittedRowModifications**
**Nivel de comprobación previa: advertencia**
**Comprueba si hay muchas modificaciones de fila sin confirmar**
Tal y como se ha mencionado en [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions), mientras se ejecuta el proceso de actualización de la versión principal, es esencial que la instancia de base de datos de la versión 2 de Aurora MySQL [se cierre por completo](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown). Esto garantiza que todas las transacciones se confirmen o se reviertan y que InnoDB haya purgado todos los registros de deshacer.
Si el clúster de base de datos tiene transacciones que han modificado un gran número de filas, esto puede prolongar el tiempo que InnoDB tarda en completar la reversión de esta transacción como parte del proceso de cierre completo. Si la comprobación previa detecta transacciones de larga duración, con un gran número de filas modificadas en el clúster de base de datos, se generará una advertencia. Si bien esto no impide que se continúe con la actualización, le recomendamos que supervise de cerca el tamaño de las transacciones activas del clúster de la base de datos. Al mantenerla en niveles bajos, se reducirá el tiempo de inactividad necesario durante una actualización de la versión principal.
**Ejemplo de salida:**
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"description": "Database contains uncommitted row changes greater than 10M. Upgrade may take longer time.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "information_schema.innodb_trx",
"description": "The database contains 11000000 uncommitted row change(s) in 1 transaction(s). Upgrade may take longer due to transaction rollback."
}
]
},
```
La comprobación previa indica que el clúster de base de datos incluye una transacción con 11 000 000 de cambios de fila no confirmados que deberán revertirse durante el proceso de cierre completo. La actualización continuará, pero para reducir el tiempo de inactividad durante el proceso de actualización, le recomendamos que lo supervise e investigue antes de ejecutar la actualización en los clústeres de producción.
Para ver las transacciones activas en la instancia de base de datos de escritor, puede utilizar la tabla [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html). La siguiente consulta en la instancia de base de datos de escritor muestra las transacciones actuales, el tiempo de ejecución, el estado y las filas modificadas del clúster de la base de datos.
```
# Example of uncommitted transaction
mysql> SELECT trx_started,
TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
trx_mysql_thread_id AS show_processlist_connection_id,
trx_id,
trx_state,
trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| trx_started | seconds_trx_has_been_running | show_processlist_connection_id | trx_id | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| 2024-08-12 18:32:52 | 1592 | 20041 | 52866130 | RUNNING | 11000000 |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
1 row in set (0.01 sec)
# Example of transaction rolling back
mysql> SELECT trx_started,
TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
trx_mysql_thread_id AS show_processlist_connection_id,
trx_id,
trx_state,
trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| trx_started | seconds_trx_has_been_running | show_processlist_connection_id | trx_id | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| 2024-08-12 18:32:52 | 1719 | 20041 | 52866130 | ROLLING BACK | 10680479 |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
1 row in set (0.01 sec)
```
Una vez confirmada o revertida la transacción, la comprobación previa ya no mostrará ninguna advertencia. Consulte la documentación de MySQL y hable con el equipo de aplicaciones antes de revertir cualquier transacción grande, ya que la reversión puede tardar algún tiempo en completarse, según el tamaño de la transacción.
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"detectedProblems": []
},
```
Para obtener más información sobre la optimización de la administración de transacciones de InnoDB y el posible impacto al ejecutar y revertir transacciones de gran tamaño en instancias de bases de datos de MySQL, consulte la sección [Optimizing InnoDB Transaction Management](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) en la documentación de MySQL.
## Avisos
La siguiente comprobación previa genera un aviso cuando se produce un error en ella, pero se puede continuar con la actualización.
**sqlModeFlagCheck**
**Nivel de comprobación previa: aviso**
**Uso de indicadores de `sql_mode` obsoletos**
Además de `MAXDB`, se ha [eliminado](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) una serie de otras opciones de `sql_mode`: `DB2`, `MSSQL`, `MYSQL323`, `MYSQL40`, `ORACLE`, `POSTGRESQL`, `NO_FIELD_OPTIONS`, `NO_KEY_OPTIONS` y `NO_TABLE_OPTIONS`. A partir de MySQL 8.0, ninguno de estos valores se puede asignar a la variable del sistema `sql_mode`. Si esta comprobación previa detecta sesiones abiertas con esta configuración de `sql_mode`, asegúrese de que los grupos de parámetros de la instancia de base de datos y del clúster de base de datos, así como las aplicaciones y configuraciones del cliente, estén actualizados para deshabilitarlos. Para obtener más información, consulte la [documentación de MySQL](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html).
**Ejemplo de salida:**
```
{
"id": "sqlModeFlagCheck",
"title": "Usage of obsolete sql_mode flags",
"status": "OK",
"detectedProblems": []
}
```
Para resolver alguno de estos errores de comprobación previa, consulte [maxdbFlagCheck](#maxdbFlagCheck).
## Errores, advertencias o avisos
La siguiente comprobación previa puede devolver un error, una advertencia o un aviso en función del resultado de la comprobación previa.
**checkTableOutput**
**Nivel de comprobación previa: error, advertencia o aviso**
**Problemas notificados por el comando `check table x for upgrade`**
Antes de iniciar la actualización a la versión 3 de Aurora MySQL, se ejecuta `check table for upgrade` en cada tabla de los esquemas de usuarios del clúster de la base de datos. Esta comprobación previa no es la misma que la de [checkTableMysqlSchema](#checkTableMysqlSchema).
El comando `check table for upgrade` examina las tablas para detectar posibles problemas que puedan surgir durante una actualización a una versión más reciente de MySQL. Ejecutar este comando antes de intentar una actualización puede ayudar a identificar y resolver cualquier incompatibilidad con antelación, lo que facilita el proceso de actualización propiamente dicho.
Este comando realiza varias comprobaciones en cada tabla, como, por ejemplo:
+ Verifica que los metadatos y la estructura de la tabla sean compatibles con la versión de MySQL de destino
+ Comprueba si hay alguna característica obsoleta o eliminada que se utilice en la tabla
+ Garantiza que la tabla se pueda actualizar correctamente sin que se pierdan datos
A diferencia de otras comprobaciones previas, puede devolver un error, una advertencia o un aviso en función del resultado de `check table`. Si esta comprobación previa devuelve alguna tabla, revísela detenidamente, junto con el código de devolución y el mensaje antes de iniciar la actualización. Para obtener más información, consulte la sección [CHECK TABLE statement](https://dev.mysql.com/doc/refman/5.7/en/check-table.html) en la documentación de MySQL.
A continuación, ofrecemos un ejemplo de error y un ejemplo de advertencia.
**Ejemplo de error:**
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.parent",
"description": "Table 'test.parent' doesn't exist"
}
]
},
```
La comprobación previa indica que hay un error porque la tabla `test.parent` no existe.
El archivo `mysql-error.log` de la instancia de base de datos de escritor muestra que hay un error de clave externa.
```
2024-08-13T15:32:10.676893Z 62 [Warning] InnoDB: Load table `test`.`parent` failed, the table has missing foreign key indexes. Turn off 'foreign_key_checks' and try again.
2024-08-13T15:32:10.676905Z 62 [Warning] InnoDB: Cannot open table test/parent from the internal data dictionary of InnoDB though the .frm file for the table exists.
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
```
Inicie sesión en la instancia de base de datos de escritor y ejecute `show engine innodb status\G` para obtener más información sobre el error de clave externa.
```
mysql> show engine innodb status\G
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
2024-08-13 15:33:33 0x14ef7b8a1700 INNODB MONITOR OUTPUT
=====================================
.
.
.
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2024-08-13 15:32:10 0x14ef6dbbb700 Error in foreign key constraint of table test/child:
there is no index in referenced table which would contain
the columns as the first columns, or the data types in the
referenced table do not match the ones in table. Constraint:
,
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
The index in the foreign key in table is p_name_idx
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html for correct foreign key definition.
.
.
```
El mensaje `LATEST FOREIGN KEY ERROR` indica que a la restricción de clave externa `fk_pname` de la tabla `test.child`, que hace referencia a la tabla `test.parent`, le falta un índice o el tipo de datos no coincide. La documentación de MySQL sobre [las restricciones de claves externas](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html) establece que las columnas a las que se hace referencia en una clave externa deben tener un índice asociado y las columnas principales o secundarias deben usar el mismo tipo de datos.
Para verificar si esto se debe a la falta de un índice o a que el tipo de datos no coincide, inicie sesión en la base de datos y compruebe las definiciones de la tabla deshabilitando temporalmente la variable de sesión [foreign\$1key\$1checks](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html#foreign-key-checks). Después de hacerlo, podemos ver que la restricción secundaria en cuestión (`fk_pname`) utiliza `p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL` para hacer referencia a la tabla principal `name varchar(20) NOT NULL`. La tabla principal utiliza `DEFAULT CHARSET=utf8`, pero la columna `p_name` de la tabla secundaria utiliza `latin1`, por lo que se produce un error de incoherencia entre los tipos de datos.
```
mysql> show create table parent\G
ERROR 1146 (42S02): Table 'test.parent' doesn't exist
mysql> show create table child\G
*************************** 1. row ***************************
Table: child
Create Table: CREATE TABLE `child` (
`id` int(11) NOT NULL,
`p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `p_name_idx` (`p_name`),
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> set foreign_key_checks=0;
Query OK, 0 rows affected (0.00 sec)
mysql> show create table parent\G
*************************** 1. row ***************************
Table: parent
Create Table: CREATE TABLE `parent` (
`name` varchar(20) NOT NULL,
PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> show create table child\G
*************************** 1. row ***************************
Table: child
Create Table: CREATE TABLE `child` (
`id` int(11) NOT NULL,
`p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `p_name_idx` (`p_name`),
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
```
Para resolver este problema, podemos cambiar la tabla secundaria para que use el mismo conjunto de caracteres que la tabla principal o cambiar la tabla principal para que use el mismo conjunto de caracteres que la tabla secundaria. En este caso, dado que la tabla secundaria usa explícitamente `latin1` en la definición de columna `p_name`, ejecutamos `ALTER TABLE` para modificar el conjunto de caracteres a `utf8`.
```
mysql> alter table child modify p_name varchar(20) character set utf8 DEFAULT NULL;
Query OK, 0 rows affected (0.06 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> flush tables;
Query OK, 0 rows affected (0.01 sec)
```
Después de hacerlo, se aprueba la comprobación previa y se puede continuar con la actualización.
**Ejemplo de advertencia:**
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.orders",
"description": "Trigger test.orders.delete_audit_trigg does not have CREATED attribute."
}
]
}
```
La comprobación previa muestra una advertencia para el desencadenador `delete_audit_trigg` de la tabla `test.orders`, ya que no tiene el atributo `CREATED`. Según la sección [Checking Version Compatibility](https://dev.mysql.com/doc/refman/5.7/en/check-table.html#check-table-version-compatibility) de la documentación de MySQL, este mensaje es informativo y se muestra para los desencadenadores creados en las versiones anteriores a MySQL 5.7.2.
Dado que se trata de una advertencia, no impide que se lleve a cabo la actualización. Sin embargo, si desea resolver el problema, puede volver a crear el desencadenador en cuestión, y la comprobación previa se realizará correctamente sin ningún tipo de advertencia.
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": []
},
```
# Pasos para realizar una actualización local
También le recomendamos que revise el material de referencia en [Cómo funciona la actualización de la versión principal en el lugar Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence).
Realice cualquier planificación y prueba previas a la actualización, tal y como se describe en [Planificación de una actualización de versión principal para un clúster Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Planning).
## Consola
En el ejemplo siguiente se actualiza el clúster de base de datos `mydbcluster-cluster` a la versión Aurora MySQL 3.04.1.
**Para actualizar la versión principal de un clúster de base de datos Aurora MySQL**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Si utilizó un grupo de parámetros personalizado con el clúster de base de datos original, cree un grupo de parámetros compatible con la nueva versión principal. Realice los ajustes necesarios en los parámetros de configuración del nuevo grupo de parámetros. Para obtener más información, consulte [Cómo afectan las actualizaciones en el lugar a los grupos de parámetros de un clúster](#AuroraMySQL.Upgrading.ParamGroups).
1. En el panel de navegación, seleccione **Databases (Bases de datos)**.
1. En la lista, elija el clúster de base de datos que desea modificar.
1. Elija **Modify**.
1. Para **Version** (Versión), elija una nueva versión principal de Aurora.
También le recomendamos que utilice la versión secundaria de la versión principal. A continuación, elegimos la versión predeterminada actual.
![\[Actualización in situ de un clúster de base de datos Aurora MySQL de la versión 2 a la versión 3\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/ams-upgrade-v2-v3.png)
1. Elija **Continue**.
1. En la página siguiente, especifique cuándo realizar la actualización. Seleccione **During the next scheduled maintenance window (Durante la siguiente ventana de mantenimiento programado)** o **Immediately (Inmediatamente)**.
1. (Opcional) Examine periódicamente la página **Events** (Eventos) de la consola RDS durante la actualización. Esto le ayuda a supervisar el progreso de la actualización e identificar cualquier problema. Si la actualización encuentra algún problema, consulte [Solución de problemas para la actualización Aurora MySQL en el lugar](AuroraMySQL.Upgrading.Troubleshooting.md) para conocer los pasos a seguir.
1. Si creó un nuevo grupo de parámetros al inicio de este procedimiento, asocie el grupo de parámetros personalizados con el clúster actualizado. Para obtener más información, consulte [Cómo afectan las actualizaciones en el lugar a los grupos de parámetros de un clúster](#AuroraMySQL.Upgrading.ParamGroups).
**nota**
Para realizar este paso, deberá reiniciar el clúster de nuevo para aplicar el nuevo grupo de parámetros.
1. (Opcional) Después de completar las pruebas posteriores a la actualización, elimine la instantánea manual que Aurora creó al comienzo de la actualización.
## AWS CLI
Para actualizar la versión principal de un clúster de base de datos de Aurora MySQL, utilice el comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) de la AWS CLI con los siguientes parámetros requeridos:
+ `--db-cluster-identifier`
+ `--engine-version`
+ `--allow-major-version-upgrade`
+ `--apply-immediately` o `--no-apply-immediately`
Si el clúster utiliza algún grupo de parámetros personalizados, incluya también una o ambas opciones:
+ `--db-cluster-parameter-group-name`, si el clúster utiliza un grupo de parámetros de clúster personalizado
+ `--db-instance-parameter-group-name`, si alguna instancia del clúster utiliza un grupo de parámetros de base de datos personalizado
En el ejemplo siguiente se actualiza el clúster de base de datos `sample-cluster` a la versión Aurora MySQL 3.04.1. La actualización se realiza inmediatamente, en lugar de esperar la siguiente ventana de mantenimiento.
**Example**
Para Linux, macOS o Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 8.0.mysql_aurora.3.04.1 \
--allow-major-version-upgrade \
--apply-immediately
```
En Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 8.0.mysql_aurora.3.04.1 ^
--allow-major-version-upgrade ^
--apply-immediately
```
Puede combinar otros comandos de CLI con `modify-db-cluster` para crear un proceso automatizado de extremo a extremo para realizar y verificar actualizaciones. Para obtener más información y ejemplos, consulte [Tutorial de actualización de Aurora MySQL en el lugar](AuroraMySQL.Upgrading.Tutorial.md).
**nota**
Si el clúster forma parte de una base de datos global Aurora, el procedimiento de actualización en el lugar es ligeramente diferente. Se llama a la operación de comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) en lugar de `modify-db-cluster`. Para obtener más información, consulte [Actualizaciones mayores en el lugar para bases de datos globales](#AuroraMySQL.Upgrading.GlobalDB).
## API de RDS
Para actualizar la versión principal de un clúster de base de datos Aurora MySQL, utilice la operación de la API de RDS [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) con los siguientes parámetros requeridos:
+ `DBClusterIdentifier`
+ `Engine`
+ `EngineVersion`
+ `AllowMajorVersionUpgrade`
+ `ApplyImmediately` (establecido en `true` o `false`)
**nota**
Si el clúster forma parte de una base de datos global Aurora, el procedimiento de actualización en el lugar es ligeramente diferente. Se llama a la operación [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalClusterParameterGroup.html) en lugar de `ModifyDBCluster`. Para obtener más información, consulte [Actualizaciones mayores en el lugar para bases de datos globales](#AuroraMySQL.Upgrading.GlobalDB).
## Cómo afectan las actualizaciones en el lugar a los grupos de parámetros de un clúster
Los grupos de parámetros de Aurora tienen diferentes conjuntos de opciones de configuración para los clústeres compatibles con MySQL 5.7 u 8.0. Al realizar una actualización en el centro, el clúster actualizado y todas sus instancias deben utilizar los grupos de parámetros de clúster e instancia correspondientes.
Es posible que el clúster y las instancias usen los grupos de parámetros predeterminados compatibles con la versión 5.7. Si es así, el clúster y la instancia actualizados comienzan con los grupos predeterminados de parámetros compatibles con 8.0. Si su clúster e instancias utilizan algún grupo de parámetros personalizado, asegúrese de crear los correspondientes grupos de parámetros compatibles con 8.0. También asegúrese de especificarlos durante el proceso de actualización.
**nota**
Para la mayoría de las configuraciones de parámetros, puede elegir el grupo de parámetros personalizado en dos puntos. Esto es al crear el clúster o asociar el grupo de parámetros al clúster más adelante.
Sin embargo, si utiliza una configuración no predeterminada para el parámetro `lower_case_table_names`, debe configurar el grupo de parámetros personalizado con esta configuración de antemano. A continuación, especifique el grupo de parámetros durante la restauración de instantáneas para la creación de clúster. Cualquier cambio en el parámetro `lower_case_table_names` no tiene efecto después de crear el clúster.
Le recomendamos que utilice la misma configuración para `lower_case_table_names` cuando actualice de la versión 2 de Aurora MySQL a la versión 3.
Con una base de datos global de Aurora basada en Aurora MySQL, no se puede realizar una actualización local desde la versión 2 a la versión 3 de Aurora MySQL si el parámetro `lower_case_table_names` está activado. Para obtener más información sobre los métodos que puede utilizar, consulte [Actualizaciones de la versión principal](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major).
**importante**
Si especifica algún grupo de parámetros personalizado durante el proceso de actualización, asegúrese de reiniciar manualmente el clúster una vez finalizada la actualización. Al hacerlo, el clúster comienza a usar la configuración de parámetros personalizados.
## Cambios en las propiedades del clúster entre versiones de Aurora MySQL
Cuando actualice de la versión 2 a la versión 3 de Aurora MySQL, asegúrese de comprobar cualquier aplicación o script que utilice para configurar o administrar clústeres e instancias de base de datos de Aurora MySQL.
Además, cambie el código que manipula los grupos de parámetros para tener en cuenta el hecho de que los nombres de grupos de parámetros predeterminados son diferentes para los clústeres compatibles con 5.7 y 8.0. Los nombres de los grupos de parámetros predeterminados para los clústeres de las versiones 2 y 3 de Aurora MySQL son `default.aurora-mysql5.7` y `default.aurora-mysql8.0`, respectivamente.
Por ejemplo, es posible que tenga código como el siguiente que se aplique al clúster antes de una actualización.
```
# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1
```
Después de actualizar la versión principal del clúster, modifique ese código de la siguiente manera.
```
# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1
```
## Actualizaciones mayores en el lugar para bases de datos globales
Para una base de datos global de Aurora, actualice el clúster de la base de datos global. Aurora actualiza automáticamente todos los clústeres al mismo tiempo y se asegura de que todos ejecuten la misma versión del motor. Este requisito se debe a que cualquier cambio en las tablas del sistema, formatos de archivo de datos, etc., se replican automáticamente en todos los clústeres secundarios.
Siga las instrucciones en [Cómo funciona la actualización de la versión principal en el lugar Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence). Cuando especifique qué actualizar, asegúrese de elegir el clúster de base de datos global en lugar de uno de los clústeres que contiene.
Si utiliza la Consola de administración de AWS, elija el elemento con el rol **Global database** (Base de datos global).
![\[Actualización del clúster de base de datos global\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-major-upgrade-global-cluster.png)
Si utiliza la AWS CLI o la API de RDS, inicie el proceso de actualización llamando al comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) o la operación [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html). Se usa uno de estos en lugar de `modify-db-cluster` o `ModifyDBCluster`.
**nota**
No puede especificar un grupo de parámetros personalizado para el clúster de base de datos global mientras realiza una actualización importante de la versión de esa base de datos global de Aurora. Cree grupos de parámetros personalizados en cada región del clúster global. A continuación, aplíquelos manualmente a los clústeres regionales después de la actualización.
Para actualizar la versión principal de un clúster de base de datos global de Aurora MySQL, utilice el comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) de la AWS CLI con los siguientes parámetros requeridos:
+ `--global-cluster-identifier`
+ `--engine aurora-mysql`
+ `--engine-version`
+ `--allow-major-version-upgrade`
En el ejemplo siguiente se actualiza el clúster de base de datos global a la versión 2.10.2 de Aurora MySQL.
**Example**
Para Linux, macOS o Unix:
```
aws rds modify-global-cluster \
--global-cluster-identifier global_cluster_identifier \
--engine aurora-mysql \
--engine-version 5.7.mysql_aurora.2.10.2 \
--allow-major-version-upgrade
```
En Windows:
```
aws rds modify-global-cluster ^
--global-cluster-identifier global_cluster_identifier ^
--engine aurora-mysql ^
--engine-version 5.7.mysql_aurora.2.10.2 ^
--allow-major-version-upgrade
```
## Consideraciones sobre el Backtrack
Si el clúster que actualizó tenía habilitada la característica Backtrack, no podrá realizar un retroceso del clúster actualizado a una hora anterior a la actualización.
# Tutorial de actualización de Aurora MySQL en el lugar
En los siguientes ejemplos de Linux se muestra cómo se pueden realizar los pasos generales del procedimiento de actualización en el lugar utilizando AWS CLI.
Este primer ejemplo crea un clúster de base de datos Aurora que ejecuta una versión 2.x de Aurora MySQL. El clúster incluye una instancia de base de datos de escritura y una instancia de base de datos de lector. El comando `wait db-instance-available` se detiene hasta que la instancia de base de datos del escritor esté disponible. Ese es el momento en que el clúster está listo para ser actualizado.
```
aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
--db-cluster-version 5.7.mysql_aurora.2.11.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
--db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
Las versiones de Aurora MySQL 3.x en las que puede actualizar el clúster dependen de la versión 2.x en la que se está ejecutando actualmente el clúster y en la Región de AWS donde se encuentra el clúster. El primer comando, con `--output text`, solo muestra la versión de destino disponible. El segundo comando muestra la salida JSON completa de la respuesta. En esa respuesta, puede ver detalles como el valor `aurora-mysql` que utiliza para el parámetro `engine`. También puede ver el hecho de que la actualización a 3.04.0 es una actualización de la versión principal.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.2 \
--query '*[].[ValidUpgradeTarget]'
...
{
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.3.04.0",
"Description": "Aurora MySQL 3.04.0 (compatible with MySQL 8.0.28)",
"AutoUpgrade": false,
"IsMajorVersionUpgrade": true,
"SupportedEngineModes": [
"provisioned"
],
"SupportsParallelQuery": true,
"SupportsGlobalDatabases": true,
"SupportsBabelfish": false,
"SupportsIntegrations": false
},
...
```
En este ejemplo, se muestra que si ingresa un número de versión de destino que no es un destino de actualización válido para el clúster, Aurora no realiza la actualización. Aurora tampoco realiza una actualización de versión principal, a menos que incluya el parámetro `--allow-major-version-upgrade`. De esta manera, no puede realizar accidentalmente una actualización que tenga el potencial de requerir pruebas exhaustivas y cambios en el código de su aplicación.
```
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.11.2 with requested version 5.7.mysql_aurora.2.09.2.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --apply-immediately --allow-major-version-upgrade
{
"DBClusterIdentifier": "mynewdbcluster",
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2"
}
```
El estado del clúster y las instancias de base de datos asociadas tardan unos minutos en cambiar a `upgrading`. Los números de versión del clúster y de las instancias de base de datos solo cambian cuando finaliza la actualización. De nuevo, puede utilizar el comando `wait db-instance-available` para que la instancia de base de datos de escritor espere hasta que finalice la actualización antes de continuar.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.11.2
aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
--query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
"DBInstanceIdentifier": "mynewdbcluster-instance1",
"DBInstanceStatus": "upgrading"
}
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
En este punto, el número de versión del clúster coincide con el especificado para la actualización.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.04.0
```
En el ejemplo anterior se realizó una actualización inmediata especificando el parámetro `--apply-immediately`. Para permitir que la actualización se realice en un momento conveniente cuando no se espera que el clúster esté ocupado, puede especificar el parámetro `--no-apply-immediately`. Al hacerlo, la actualización se iniciará durante la siguiente ventana de mantenimiento del clúster. La ventana de mantenimiento define el período durante el cual se pueden iniciar las operaciones de mantenimiento. Es posible que una operación de larga duración no finalice durante el período de mantenimiento. Por lo tanto, no necesita definir una ventana de mantenimiento más grande, incluso si espera que la actualización pueda tardar mucho tiempo.
En el ejemplo siguiente, se actualiza un clúster que inicialmente ejecuta la versión 2.11.2 de Aurora MySQL. En la salida de `describe-db-engine-versions`, los valores `False` y `True` representan la propiedad `IsMajorVersionUpgrade`. Desde la versión 2.11.2, puede actualizar a otras versiones 2.\$1. Esas actualizaciones no se consideran actualizaciones de versión principales, por lo que no requieren una actualización in situ. La actualización local solo está disponible para las actualizaciones a las versiones 3.\$1 que se muestran en la lista.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
--query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text
5.7.mysql_aurora.2.11.3 False
5.7.mysql_aurora.2.11.4 False
5.7.mysql_aurora.2.11.5 False
5.7.mysql_aurora.2.11.6 False
5.7.mysql_aurora.2.12.0 False
5.7.mysql_aurora.2.12.1 False
5.7.mysql_aurora.2.12.2 False
5.7.mysql_aurora.2.12.3 False
8.0.mysql_aurora.3.04.0 True
8.0.mysql_aurora.3.04.1 True
8.0.mysql_aurora.3.04.2 True
8.0.mysql_aurora.3.04.3 True
8.0.mysql_aurora.3.05.2 True
8.0.mysql_aurora.3.06.0 True
8.0.mysql_aurora.3.06.1 True
8.0.mysql_aurora.3.07.1 True
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --no-apply-immediately --allow-major-version-upgrade
...
```
Cuando se crea un clúster sin una ventana de mantenimiento especificada, Aurora selecciona un día aleatorio de la semana. En este caso, el comando `modify-db-cluster` se envía un lunes. Por lo tanto, cambiamos la ventana de mantenimiento para que sea el martes por la mañana. Todas las horas se representan en la zona horaria UTC. El periodo `tue:10:00-tue:10:30` se corresponde a las 2:00-2:30 h, hora del Pacífico. El cambio en la ventana de mantenimiento surte efecto inmediatamente.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"sat:08:20-sat:08:50"
]
]
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"tue:10:00-tue:10:30"
]
]
```
En el siguiente ejemplo se muestra cómo obtener un informe de los eventos generados por la actualización. El argumento `--duration` representa el número de minutos para recuperar la información del evento. Este argumento es necesario porque, de forma predeterminada, `describe-events` solo devuelve eventos de la última hora.
```
aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
"Events": [
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "DB cluster created",
"EventCategories": [
"creation"
],
"Date": "2022-11-17T01:24:11.093000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing online pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:08.450000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:59.519000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:00:22.318000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Cloning volume.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:01:45.428000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:02:25.141000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:23.036000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Upgrading database objects.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:48.208000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster major version has been upgraded",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:10:28.999000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
}
]
}
```
# Determinación del motivo de los errores en una actualización de la versión principal de Aurora MySQL
En el [tutorial](AuroraMySQL.Upgrading.Tutorial.md), la actualización de Aurora MySQL versión 2 a la versión 3 se realizó correctamente. Pero si la actualización hubiera fallado, querría saber por qué.
Puede empezar por utilizar el comando `describe-events` de la AWS CLI para ver los eventos del clúster de base de datos. En este ejemplo, se muestran los eventos de `mydbcluster` de las últimas 10 horas.
```
aws rds describe-events \
--source-type db-cluster \
--source-identifier mydbcluster \
--duration 600
```
En este caso, se produjo un error en la comprobación previa de la actualización.
```
{
"Events": [
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster engine version upgrade started.",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:22.846000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
},
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the
upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:24.373000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
}
]
}
```
Para diagnosticar la causa exacta del problema, examine los registros de la base de datos de la instancia de base de datos de escritor. Cuando se produce un fallo en una actualización a Aurora MySQL versión 3, la instancia de escritor contiene un archivo de registro con el nombre `upgrade-prechecks.log`. En este ejemplo se muestra cómo detectar la presencia de ese registro y, luego, descargarlo en un archivo local para su análisis.
```
aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
--query '*[].[LogFileName]' --output text
error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log
aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
--log-file-name upgrade-prechecks.log \
--starting-token 0 \
--output text >upgrade_prechecks.log
```
El archivo `upgrade-prechecks.log` está en formato JSON. Lo descargamos con la opción `--output text` para evitar codificar la salida JSON dentro de otro contenedor JSON. Para las actualizaciones a la versión 3 de Aurora MySQL, este registro siempre incluye ciertos mensajes informativos y de advertencia. Solo incluye mensajes de error si no se puede actualizar. Si se actualiza correctamente, el archivo de registro ya no se produce.
Para resumir todos los errores y mostrar los campos de objeto y descripción asociados, puede ejecutar el comando `grep -A 2 '"level": "Error"'` en el contenido del archivo `upgrade-prechecks.log`. Al hacerlo, se muestra cada línea de error y las dos líneas posteriores. Estas contienen el nombre del objeto de base de datos correspondiente e instrucciones sobre cómo corregir el problema.
```
$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'
"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
```
En este ejemplo, puede ejecutar el siguiente comando de SQL en la tabla infractora para intentar solucionar el problema, o bien puede volver a crear la tabla sin el índice pendiente.
```
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
```
A continuación, vuelva a intentar la actualización.
# Solución de problemas para la actualización Aurora MySQL en el lugar
Utilice las siguientes sugerencias para solucionar problemas con las actualizaciones in situ de Aurora MySQL. Estas sugerencias no se aplican a los clústeres de base de datos de Aurora Serverless.
| Motivo por el que la actualización en el lugar se cancela o se ralentiza | Efecto | Solución para permitir que la actualización en el lugar se complete dentro de la ventana de mantenimiento |
| --- | --- | --- |
| La réplica entre regiones de Aurora asociadas aún no cuenta con revisión | Aurora cancela la actualización. | Actualice la réplica entre regiones de Aurora e inténtelo de nuevo. |
| El clúster tiene transacciones XA en el estado preparado | Aurora cancela la actualización. | Confirme o revierta todas las transacciones XA preparadas. |
| El clúster está procesando cualquier declaración de lenguaje de definición de datos (DDL) | Aurora cancela la actualización. | Considere la posibilidad de esperar y realizar la actualización una vez finalizadas todas las instrucciones DDL. |
| El clúster tiene cambios no confirmados para muchas filas | Esto puede llevar mucho tiempo. | El proceso de actualización revierte los cambios no confirmados. El indicador para esta condición es el valor de `TRX_ROWS_MODIFIED` en la `INFORMATION_SCHEMA.INNODB_TRX` tabla. Considere la posibilidad de realizar la actualización solo después de que todas las transacciones grandes se hayan confirmado o deshecho. |
| El clúster tiene un gran número de registros de deshacer | Esto puede llevar mucho tiempo. | Incluso si las transacciones no confirmadas no afectan a un gran número de filas, pueden implicar un gran volumen de datos. Por ejemplo, puede que esté insertando BLOBs grandes. Aurora no detecta ni genera automáticamente un evento para este tipo de actividad de transacción. El indicador de esta condición es la longitud de la lista de historial (HLL). El proceso de actualización revierte los cambios no confirmados. Puede comprobar el HLL en la salida del comando SQL `SHOW ENGINE INNODB STATUS` o directamente mediante la siguiente consulta SQL: SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
También puede monitorizar la métrica `RollbackSegmentHistoryListLength` en Amazon CloudWatch. Considere la posibilidad de realizar la actualización solo después de que la HLL sea menor. |
| El clúster está en el proceso de confirmar una transacción de registro binario grande | Esto puede llevar mucho tiempo. | El proceso de actualización espera hasta que se apliquen los cambios en el registro binario. Más transacciones o instrucciones DDL podrían comenzar durante este período, lo que ralentiza aún más el proceso de actualización. Programe el proceso de actualización cuando el clúster no esté ocupado con la generación de cambios de reproducción de registros binarios. Aurora no detecta ni genera automáticamente un evento para esta condición. |
| Inconsistencias en el esquema causadas por la eliminación o la corrupción de un archivo | Aurora cancela la actualización. | Cambie el motor de almacenamiento predeterminado para las tablas temporales de MyISAM a InnoDB. Siga estos pasos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html) |
| Se ha eliminado el usuario maestro | Aurora cancela la actualización. | No elimine el usuario maestro. Sin embargo, si por alguna razón elimina el usuario maestro, restáurelo mediante los siguientes comandos SQL: CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES,
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT,
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;
|
Para obtener más información sobre la solución de problemas que provocan el error de las comprobaciones previas a la actualización, consulte los siguientes blogs:
+ [Lista de verificación de actualización de Amazon Aurora MySQL versión 2 (compatible con MySQL 5.7) a la versión 3 (compatible con MySQL 8.0), parte 1](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-1/)
+ [Lista de verificación de actualización de Amazon Aurora MySQL versión 2 (compatible con MySQL 5.7) a la versión 3 (compatible con MySQL 8.0), parte 2](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2/)
Puede utilizar los siguientes pasos para realizar sus propias comprobaciones de algunas de las condiciones de la tabla anterior. De esta forma, puede programar la actualización en un momento en que sepa que la base de datos se encuentra en un estado en el que la actualización puede completarse correctamente y rápidamente.
+ Puede comprobar si hay transacciones XA abiertas ejecutando la instrucción `XA RECOVER`. A continuación, puede confirmar o revertir las transacciones XA antes de iniciar la actualización.
+ Puede comprobar si hay instrucciones DDL ejecutando una instrucción `SHOW PROCESSLIST` y buscando las instrucciones `CREATE`, `DROP`, `ALTER`, `RENAME` y `TRUNCATE` en la salida. Permita que todas las instrucciones DDL finalicen antes de iniciar la actualización.
+ Puede comprobar el número total de filas no confirmadas consultando la tabla `INFORMATION_SCHEMA.INNODB_TRX`. La tabla contiene una fila para cada transacción. La columna `TRX_ROWS_MODIFIED` contiene el número de filas modificadas o insertadas por la transacción.
+ Puede verificar la longitud de la lista de historial de InnoDB ejecutando la instrucción `SHOW ENGINE INNODB STATUS SQL` y buscando el `History list length` en la salida. También puede comprobar el valor directamente ejecutando la siguiente consulta:
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
La longitud de la lista de historial corresponde a la cantidad de información de deshacer almacenada por la base de datos para implementar el control de concurrencia multiversión (MVCC).
# Limpieza posterior a la actualización para Aurora MySQL versión 3
Una vez que haya terminado de actualizar cualquier clúster de Aurora MySQL versión 2 a Aurora MySQL versión 3, puede realizar estas otras acciones de limpieza:
+ Cree nuevas versiones compatibles con MySQL 8.0 de cualquier grupo de parámetros personalizados. Aplique los valores de parámetros personalizados necesarios a los nuevos grupos de parámetros.
+ Actualice las alarmas de CloudWatch, los scripts de configuración, etc. para utilizar los nuevos nombres para cualquier métrica cuyos nombres se hayan visto afectados por cambios de idioma inclusivos. Para ver una lista de estas métricas, consulte [Cambios de idioma inclusivos para Aurora MySQL versión 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
+ Actualice cualquier plantilla CloudFormation para utilizar los nuevos nombres para cualquier parámetro de configuración cuyos nombres se hayan visto afectados por cambios de idioma inclusivos. Para obtener una lista completa de estos parámetros, consulte [Cambios de idioma inclusivos para Aurora MySQL versión 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
## Índices espaciales
Después de actualizar a Aurora MySQL versión 3, verifique si necesita eliminar o volver a crear objetos e índices relacionados con los índices espaciales. Antes de MySQL 8.0, Aurora podía optimizar las consultas espaciales utilizando índices que no contenían un identificador de recursos espaciales (SRID). Aurora MySQL versión 3 solo utiliza índices espaciales que contienen SRID. Durante una actualización, Aurora elimina automáticamente cualquier índice espacial sin SRID e imprime mensajes de advertencia en el registro de la base de datos. Si observa estos mensajes de advertencia, cree nuevos índices espaciales con SRID después de la actualización. Para obtener más información sobre los cambios en las funciones espaciales y los tipos de datos de MySQL 8.0, consulte [Cambios en MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html) en el *Manual de referencia de MySQL*.