sql >> Base de Datos >  >> RDS >> Database

Alterar en la tabla grande en la solución RDS para mostrar el error completo

Alter en Big Table en RDS Solución a error de tabla llena. Tomemos un ejemplo, las tablas que tienen un tamaño muy grande (~> 100 GB a 600 GB). Modificar en tablas tan grandes requiere mucha memoria y CPU. Cuando intenta modificar la consulta en una de las tablas, aparece "ERROR 1114 (HY000):tabla llena ” error…

¿Por qué ocurrió este problema a pesar de que el volumen de almacenamiento de Amazon Aurora crecerá automáticamente hasta 64 TB?

Primero, entenderemos el almacenamiento en RDS Aurora. Hay 2 tipos de almacenamiento en Aurora. Almacén de instancias es el almacenamiento local donde se almacenan los objetos temporales y el almacenamiento principal para datos Por lo tanto, cuando ejecuta ALTER en una tabla, generará una tabla temporal y RDS aurora usará el almacenamiento de instancias para almacenar la tabla temporal. Para su instancia, que es la instancia db.r3.large, tiene 1 × 32 GB de almacenamiento local, por lo que si sus objetos temporales en la instancia llegan a ser más grandes que este tamaño, obtendrá el error "tabla llena". Además, el límite de almacenamiento local es diferente del volumen de almacenamiento total. disponible para su instancia de Aurora y, según el uso de su base de datos, su volumen de almacenamiento de Amazon Aurora crecerá automáticamente, hasta 64 TB, en incrementos de 10 GB.

Alter en la mesa grande en RDS  solución al error completo de la tabla

  1. Para solucionar el problema, puede ampliar la instancia para obtener más almacenamiento local para ejecutar su ALTER, modificar la tabla y luego reducir el tipo de instancia. Esto da como resultado un tiempo de inactividad mientras se actualiza/reduce el tipo de instancia.
  2. También puede usar:comando "pt-online-schema-change", si usa este comando, la tabla original aún está disponible para usar sin tiempo de inactividad o sin bloqueo de mesa.
Si no puede permitirse el lujo de tener ningún tiempo de inactividad en el sistema, utilice el comando pt-online-schema-change en lugar de escalar la instancia. Sin embargo, la documentación de pt-online-schema-change  dice, debemos hacer una copia de seguridad antes de ejecutar este comando. Por lo tanto, para evitar bloqueos de tablas y fallas durante el cambio de la tabla de producción, puede probar este comando en una copia exacta de la base de datos de la aplicación, con el mismo tipo de instancia de RDS. Además, intente agregar una gran carga de escritura en la tabla para imitar el tráfico . Para lograr esto, cree un script bash que inserte continuamente una nueva fila en la tabla. Para obtener una copia rápida y exacta de su base de datos actual, tome una instantánea de RDS DB y restáurela desde la instantánea para realizar pruebas.  Antes de ejecutar este comando, debemos establecer log_bin_trust_function_creators en 1 en el grupo de parámetros RDS DB. Una vez que haya terminado con el proceso ALTER, puede cambiar la variable a "0" nuevamente.
Resultados:
Si modifica la tabla con pt -cambio-de-esquema-en-línea  comando en  una mesa que tiene un tamaño de 35-40 GB, entonces puede tomar cerca de 30 horas.

Por qué usar el comando pt-online-schema-change y por qué habilitarlo  “log_bin_trust_function_creators”  en el grupo de parámetros de base de datos? ?

pt-online-schema-change  no bloquea la mesa. Este comando crea disparadores en la tabla original. Pero para esto, necesita privilegios de superusuario. cuando usa el procedimiento de almacenamiento, obtendrá el error:
# 1419:no tiene el privilegio SUPER y el registro binario está habilitado (*podría* usar la variable menos segura log_bin_trust_function_creators
Motivo:  Este error ocurre en las instancias de RDS cuando intenta utilizar "Procedimientos almacenados". Pronto descubrirá que otorgar el superprivilegio a un usuario no funcionará. Entonces, la única forma de hacer que las cosas funcionen es establecer log_bin_trust_function_creators en 1.   Según los documentos de Percona: La conclusión es que la creación de disparadores en un servidor con registros binarios habilitados requiere un usuario con privilegios SUPER (lo cual es imposible en Amazon RDS). El mensaje de error especifica la solución. Necesitamos habilitar la variable en el grupo de parámetros de base de datos "log_bin_trust_function_creators". Habilitarlo es como decirle al servidor: “Confío en los disparadores y las funciones de los usuarios habituales, y en que no causarán problemas, así que permita que mis usuarios los creen”. Dado que la funcionalidad de la base de datos no cambiará, se trata de confiar en sus usuarios. log_bin_trust_function_creators es una variable global que se puede cambiar dinámicamente. Tratando de encontrar más detalles sobre "Super_priv", cuando verifique los permisos de los usuarios en la tabla de usuarios de la base de datos MySQL. podría ver que Super_priv no está configurado para nadie excepto para el usuario rdsadmin. 
MySQL> select User,Super_priv from user;
+-----------+------------+
| User | Super_priv |
+-----------+------------+
| rdsadmin | Y |
| root | N |
| dbuser | N |
+-----------+------------+
3 rows in set (0.00 sec)

Aquí, "root" es el usuario maestro y "dbuser" es el usuario de la base de datos. Estos usuarios los creamos nosotros y el usuario "rdsadmin" lo crea automáticamente AWS, al que no tenemos acceso. Amazon utiliza rdsadmin MySQL para trabajos de mantenimiento y administración.

Este es el final del tutorial, cómo modificar en la tabla grande en la solución RDS para mostrar el error completo.