Seleccione sus preferencias de cookies

Usamos cookies esenciales y herramientas similares que son necesarias para proporcionar nuestro sitio y nuestros servicios. Usamos cookies de rendimiento para recopilar estadísticas anónimas para que podamos entender cómo los clientes usan nuestro sitio y hacer mejoras. Las cookies esenciales no se pueden desactivar, pero puede hacer clic en “Personalizar” o “Rechazar” para rechazar las cookies de rendimiento.

Si está de acuerdo, AWS y los terceros aprobados también utilizarán cookies para proporcionar características útiles del sitio, recordar sus preferencias y mostrar contenido relevante, incluida publicidad relevante. Para aceptar o rechazar todas las cookies no esenciales, haga clic en “Aceptar” o “Rechazar”. Para elegir opciones más detalladas, haga clic en “Personalizar”.

Preferencias
Contacte con nosotros
Comentarios
AWS Documentation
Cree una cuenta AWS
Solución de problemas para la actualización Aurora MySQL en el lugar - Amazon Aurora

Solución de problemas para la actualización Aurora MySQL en el lugar

PDFRSS

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:

  1. Modifique el parámetro de base de datos default_tmp_storage_engine por InnoDB.

  2. Reinicie el clúster de base de datos.

  3. Tras reiniciar, confirme que el parámetro de base de datos default_tmp_storage_engine se haya establecido en InnoDB. Utilice el siguiente comando:

    show global variables like 'default_tmp_storage_engine';

  4. Asegúrese de no crear ninguna tabla temporal que utilice el motor de almacenamiento MyISAM. Le recomendamos que ponga en pausa la carga de trabajo de la base de datos y no cree ninguna conexión nueva a la base de datos, ya que la actualizará pronto.

  5. Vuelva a intentar la actualización in situ.
Se ha eliminado el usuario maestro Aurora cancela la actualización.
importante

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:

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).

¿Necesita ayuda?

PrivacidadTérminos del sitioPreferencias de cookies
© 2025, Amazon Web Services, Inc o sus afiliados. Todos los derechos reservados.