Prácticas recomendadas para Amazon RDS - Amazon Relational Database Service

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Prácticas recomendadas para Amazon RDS

Descubra las prácticas recomendadas para trabajar con Amazon RDS. A medida que se identifiquen nuevas prácticas recomendadas, se actualizará esta sección.

nota

Para ver recomendaciones frecuentes para Amazon RDS, consulte Uso de recomendaciones de Amazon RDS.

Directrices operativas básicas de Amazon RDS

A continuación se detallan las directrices operativas básicas que se deben seguir al trabajar con Amazon RDS. El Acuerdo de nivel de servicios de Amazon RDS requiere que se sigan estas directrices:

  • Monitorice el uso de la memoria, la CPU y el almacenamiento. Amazon CloudWatch se puede configurar para notificar cuándo cambian los patrones de uso o cuándo se está llegando al límite de capacidad de la implementación con el fin de mantener el rendimiento y la disponibilidad del sistema.

  • Escale la instancia de base de datos cuando se esté acercando a los límites de la capacidad de almacenamiento. Debe tener búfer de almacenamiento y de memoria para asumir incrementos imprevistos de la demanda de las aplicaciones.

  • Habilite las copias de seguridad automáticas y configure la ventana de copia de seguridad para que se produzca durante el momento diario en el que más bajen las IOPS de escritura. Es entonces cuando una copia de seguridad es menos perjudicial para el uso de la base de datos.

  • Si la carga de trabajo de la base de datos requiere más E/S de la aprovisionada, la recuperación tras una conmutación por error o tras un error de la base de datos será lenta. Para incrementar la capacidad de E/S de una instancia de base de datos, lleve a cabo una de las acciones siguientes o todas ellas:

    • Migre a una clase de instancia de base de datos distinta con una alta capacidad de E/S.

    • Convierta desde el almacenamiento magnético al almacenamiento de uso general o de IOPS provisionadas en función del incremento que necesite. Para obtener información acerca de los tipos de almacenamiento disponibles, consulte Tipos de almacenamiento de Amazon RDS.

      Si convierte a almacenamiento de IOPS provisionadas, asegúrese de que también usa una clase de instancia de base de datos que se haya optimizado para las IOPS provisionadas. Para obtener información acerca de las IOPS provisionadas, consulte Almacenamiento de SSD de IOPS provisionadas.

    • Si ya está usando almacenamiento de IOPS provisionadas, aprovisione capacidad de rendimiento adicional.

  • Si la aplicación cliente almacena en caché los datos del Servicio de nombres de dominio (DNS) de las instancias de base de datos, defina un valor de tiempo de vida (TTL) de menos de 30 segundos. Como la dirección IP subyacente de una instancia de base de datos puede cambiar tras una conmutación por error, almacenar datos DNS en la caché durante un periodo de tiempo largo puede llevar a errores de conexión si la aplicación intenta conectarse a una dirección IP que ya no esté en servicio.

  • Pruebe la conmutación por error para su instancia de base de datos para entender cuánto tarda el proceso en su caso de uso particular y para asegurarse de que la aplicación que accede a su instancia de base de datos puede conectarse automáticamente a la nueva instancia de base de datos después de que ocurra una conmutación por error.

Recomendaciones de RAM de las instancias de base de datos

Una práctica recomendada de rendimiento de Amazon RDS consiste en asignar suficiente RAM para que el conjunto de trabajo resida casi por completo en la memoria. El conjunto de trabajo son los datos e índices que se usan con frecuencia en su instancia. Cuanto más use la instancia de base de datos, más crecerá el conjunto de trabajo.

Para saber si el conjunto de trabajo está en la memoria casi en su totalidad, compruebe la métrica ReadIOPS (usando Amazon CloudWatch) mientras la instancia de base de datos está sometida a carga. El valor de ReadIOPS debe ser pequeño y estable. Si el escalado de la clase de instancia de base de datos a una clase con más RAM da como resultado una disminución brusca de ReadIOPS, el conjunto de trabajo no está contenido en la memoria casi por completo. Siga escalando hasta que ReadIOPS no se reduzca bruscamente después de una operación de escalado o hasta que ReadIOPS se reduzca muy poco. Para obtener más información acerca de la monitorización de las métricas de las instancias de base de datos, consulte Visualización de métricas de una instancia de base de datos.

Uso del monitoreo mejorado para identificar los problemas del sistema operativo

Cuando el monitoreo mejorado está habilitado, Amazon RDS proporciona métricas en tiempo real para el sistema operativo (SO) en el que se ejecuta la instancia de base de datos. Puede ver las métricas de su instancia de base de datos en la consola o usar la salida JSON de la monitorización mejorada de Amazon CloudWatch Logs en el sistema de monitorización que prefiera. Para obtener más información acerca de la monitorización mejorada, consulte Monitorización mejorada

Uso de métricas para identificar los problemas de rendimiento

Para identificar los problemas de desempeño causados por la falta de recursos y otros cuellos de botella frecuentes, puede monitorizar las métricas disponibles para la instancia de base de datos de Amazon RDS.

Visualización de métricas de rendimiento

Debe monitorizar las métricas de desempeño con frecuencia para ver los valores medios, máximos y mínimos de diversos intervalos de tiempo. De este modo podrá identificar cuándo se degrada el rendimiento. También puede definir alarmas de Amazon CloudWatch para umbrales de métricas concretos si desea recibir alertas cuando se alcancen.

Para solucionar los problemas de rendimiento, es importante conocer el rendimiento de referencia del sistema. Cuando se configura una nueva instancia de base de datos y se ejecuta con una carga de trabajo típica, se deben capturar los valores medio, máximo y mínimo de todas las métricas de desempeño en diversos intervalos (por ejemplo, una hora, 24 horas, una semana, dos semanas) para tener una idea de lo que es normal. Ayuda a obtener comparaciones para las horas con picos y valles de funcionamiento. Puede usar esta información para saber cuándo cae el desempeño por debajo de los niveles estándar.

Para ver las métricas de desempeño

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

  2. En el panel de navegación, elija Databases (Bases de datos) y seleccione una instancia de base de datos.

  3. Elija Monitoring (Monitorización). Se muestran las ocho primeras métricas de desempeño. De manera predeterminada, las métricas muestran información del día actual.

  4. Use los botones numerados de la esquina superior derecha para recorrer las métricas adicionales o elija ajustar la configuración para ver más métricas.

  5. Seleccione una métrica de rendimiento para ajustar el intervalo de tiempo con el fin de ver los datos de un día distinto del actual. Puede cambiar los valores Statistic, Time Range y Period para ajustar la información mostrada. Por ejemplo, para ver los valores máximos de una métrica para cada día de las dos últimas semanas, defina Statistic como Maximum, Time Range como Last 2 Weeks y Period como Day.

    nota

    Al cambiar los valores Statistic, Time Range y Period, se cambian para todas las métricas. Los valores actualizados se conservan el resto de la sesión o hasta que vuelva a cambiarlos.

También puede ver las métricas de rendimiento usando la interfaz de línea de comandos (CLI) o la API. Para obtener más información, consulte Visualización de métricas de una instancia de base de datos.

Para definir una alarma de CloudWatch

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

  2. En el panel de navegación, elija Databases (Bases de datos) y seleccione una instancia de base de datos.

  3. Seleccione Logs & events (Registros y eventos).

  4. En la sección CloudWatch alarms (Alarmas de CloudWatch), elija Create alarm (Crear alarma).

    
                            Cuadro de diálogo Create Alarm (Crear alarma)
  5. En Send notifications (Enviar notificaciones), elija Yes (Sí) y en Send notifications to (Enviar notificaciones a), elija New email or SMS topic (Nuevo correo electrónico o tema de SMS).

  6. En Topic name (Nombre de tema), escriba un nombre para la notificación y en With these recipients (Con estos destinatarios), escriba una lista separada por comas de direcciones de correo electrónico y números de teléfono.

  7. En Metric (Métrica), seleccione la estadística de alarmas y métrica que definir.

  8. Para Threshold (Umbral), especifique si la métrica debe ser mayor que, menor que o igual que el umbral y especifique el valor del umbral.

  9. En Evaluation period (Período de evaluación), seleccione el período de evaluación de la alarma y en períodos consecutivos de , elija el período durante el que desea que el umbral se deba haber alcanzado para disparar la alarma.

  10. En Name of alarm (Nombre de la alarma), escriba un nombre para la alarma.

  11. Elija Create Alarm.

La alarma aparece en la sección CloudWatch alarms (Alarmas de CloudWatch).

Evaluación de las métricas de rendimiento

Una instancia de base de datos tiene varias categorías de métricas diferentes, y la forma de determinar los valores aceptables depende de la métrica.

CPU

  • Utilización de la CPU: porcentaje de la capacidad de procesamiento del equipo que está en uso.

Memoria

  • Memoria que se puede liberar: cuánta RAM está disponible en la instancia de base de datos en megabytes. La línea roja de las métricas de la pestaña de monitorización está marcada en el 75 % para las métricas de CPU, memoria y almacenamiento. Si el consumo de memoria de instancia supera con frecuencia esta línea, significa que debe verificar la carga de trabajo o actualizar la instancia.

  • Uso del espacio de intercambio: cuánto espacio de intercambio usa la instancia de base de datos en megabytes.

Espacio en disco

  • Espacio de almacenamiento disponible: cuánto espacio en disco no usa actualmente la instancia de base de datos en megabytes.

Operaciones de entrada y salida

  • IOPS de lectura, IOPS de escritura: número medio de operaciones de lectura o escritura en disco por segundo.

  • Latencia de lectura, latencia de escritura: tiempo medio de una operación de lectura o escritura en milisegundos.

  • Rendimiento de lectura, rendimiento de escritura: número medio de megabytes leídos o escritos en el disco por segundo.

  • Profundidad de la cola: número de operaciones de E/S que están esperando para la lectura o escritura en el disco.

Tráfico de red

  • Rendimiento de recepción de la red, rendimiento de transmisión de la red: velocidad del tráfico de red de entrada y salida de la instancia de base de datos en megabytes por segundo.

Conexiones a base de datos

  • Conexiones a base de datos: número de sesiones cliente que están conectadas a la instancia de base de datos.

Para obtener descripciones individuales más detalladas de cada métrica de rendimiento disponible, consulte Monitorización con Amazon CloudWatch.

En general, los valores aceptables para las métricas de desempeño dependen del aspecto de la referencia y de lo que hace la aplicación. Investigue las variaciones coherentes o de las tendencias con respecto a la referencia. La siguiente sección ofrece algunas sugerencias sobre tipos concretos de métricas:

  • Consumo elevado de CPU o RAM: unos valores elevados de consumo de CPU o RAM pueden ser adecuados si se ajustan a los objetivos de su aplicación (de rendimiento o simultaneidad, por ejemplo) y son los esperados.

  • Consumo de espacio en disco: investigue el consumo de espacio en el disco si el espacio utilizado está por sistema alrededor o por encima del 85 % del espacio total disponible en el disco. Compruebe si es posible eliminar datos de la instancia o archivar los datos en un sistema diferente para liberar espacio.

  • Tráfico de red: para el tráfico de red, hable con el administrador de su sistema para saber cuál es el rendimiento esperado para la red de su dominio y para su conexión a Internet. Investigue el tráfico de red si el rendimiento es por sistema inferior al esperado.

  • Conexiones a bases de datos: valore la posibilidad de restringir las conexiones a las bases de datos si ve que hay un alto número de conexiones de usuarios junto con una reducción en el rendimiento y el tiempo de respuesta de la instancia. El mejor número de conexiones de usuarios para su instancia de base de datos variará en función de la clase de instancia y de la complejidad de las operaciones que se estén llevando a cabo. Puede determinar el número de conexiones a bases de datos asociando la instancia de base de datos con un grupo de parámetros en el que el parámetro User Connections se haya establecido en un valor distinto de 0 (ilimitadas). Puede utilizar un grupo de parámetros existente o crear uno nuevo. Para obtener más información, consulte Trabajo con los grupos de parámetros de base de datos.

  • Métricas de IOPS: los valores esperados para las métricas de IOPS dependen de la especificación del disco y la configuración del servidor, así que debe usar su referencia para conocer los valores típicos. Investigue si los valores son por sistema diferentes de los de la referencia. Para un desempeño óptimo de IOPS, asegúrese de que el conjunto de trabajo típico se ajuste a la memoria para minimizar las operaciones de lectura y escritura.

Si hay problemas con cualquier métrica de desempeño, una de las primeras cosas que debe hacer para mejorar el desempeño es ajustar las consultas más frecuentes y más caras para ver si eso reduce la presión existente en los recursos del sistema. Para obtener más información, consulte Ajuste de consultas

Si las consultas se ajustan y el problema persiste, considere la posibilidad de actualizar su Clases de instancia de base de datos de Amazon RDS a una con más cantidad del recurso (CPU, RAM, espacio en disco, ancho de banda de red, capacidad de E/S) relacionado con el problema que se está experimentando.

Ajuste de consultas

Una de las formas más eficaces de mejorar el desempeño de la instancia de base de datos es ajustar las consultas más utilizadas y que más recursos consumen para que ejecutarlas resulte más económico.

Ajuste de consultas de MySQL

Vaya a Optimizing SELECT Statements en la documentación de MySQL para obtener más información acerca de la forma de escribir consultas para mejorar el rendimiento. También puede ir a MySQL Performance Tuning and Optimization Resources para ver otros recursos relacionados con el ajuste de las consultas.

Ajuste de consultas de Oracle

Vaya a Database SQL Tuning Guide en la documentación de Oracle para obtener más información acerca de la escritura y el análisis de consultas para mejorar el desempeño.

Ajuste de consultas de SQL Server

Vaya a Analyzing a Query en la documentación de SQL Server para mejorar las consultas para las instancias de base de datos de SQL Server. También puede usar las vistas de administración de datos (DMV) relacionadas con la ejecución, los índices y las operaciones de E/S que se describen en la documentación de Dynamic Management Views and Functions para solucionar los problemas de las consultas de SQL Server.

Un aspecto habitual del ajuste de consultas es la creación de índices eficaces. Puede usar el Asistente para la optimización del motor de base de datos para obtener posibles mejoras de los índices para su instancia de base de datos. Para obtener más información, consulte Análisis de la carga de trabajo de una base de datos de una instancia de base de datos de Amazon RDS con el Asistente para la optimización de SQL Server.

Ajuste de consultas de PostgreSQL

Vaya a Using EXPLAIN en la documentación de PostgreSQL para ver cómo se analiza un plan de consulta. Puede utilizar esta información para modificar una consulta o las tablas subyacentes con el fin de mejorar el desempeño de las consultas. También puede ir a Controlling the Planner with Explicit JOIN Clauses para ver sugerencias relativas a la especificación de uniones en las consultas para optimizar el rendimiento.

Ajuste de consultas de MariaDB

Vaya a Query Optimizations en la documentación de MariaDB para obtener más información acerca de la forma de escribir consultas para mejorar el rendimiento.

Prácticas recomendadas para trabajar con motores de almacenamiento de MySQL

Tanto el tamaño de las tablas como el número de tablas de una base de datos MySQL pueden afectar al rendimiento.

Tamaño de las tablas

Normalmente, las restricciones del sistema operativo relativas al tamaño de los archivos determinan el tamaño máximo efectivo de las tablas para las bases de datos MySQL. Por tanto, los límites generalmente no están determinados por restricciones internas de MySQL.

En una instancia de base de datos de MySQL, evite que las tablas de la base de datos crezcan demasiado. Aunque el límite de almacenamiento general es de 64 TiB, los límites de almacenamiento aprovisionado restringen el tamaño máximo de un archivo de tabla de MySQL a 16 TiB. Divida las tablas grandes para que los tamaños de archivo estén claramente por debajo del límite de 16 TiB. Este método también puede mejorar el desempeño y el tiempo de recuperación. Para obtener más información, consulte Límites de tamaño de archivo de MySQL en Amazon RDS.

Las tablas muy grandes (de más de 100 GB de tamaño) pueden afectar negativamente al rendimiento tanto de las lecturas como de las escrituras (incluidas las instrucciones de lenguaje de manipulación de datos o DML y especialmente las instrucciones lenguaje de definición de datos o DDL). Que haya índices en tablas grandes puede aumentar considerablemente el rendimiento de SELECT, pero también puede deteriorar el rendimiento de las instrucciones DML. Las instrucciones DDL, como ALTER TABLE, pueden ser considerablemente más lentas con las tablas grandes, pues con esas operaciones es posible que en algunos casos se reconstruya completamente una tabla. Con estas instrucciones DDL es posible que las tablas se bloqueen durante la duración de la operación.

La cantidad de memoria que requiere MySQL para lecturas y escrituras depende de las tablas que se impliquen en las operaciones. Es una práctica recomendada tener al menos suficiente RAM para mantener los índices de las tablas que se utilicen activamente. Para determinar cuáles son las diez tablas e índices más grandes de una base de datos, utilice la siguiente consulta:

SELECT CONCAT(table_schema, '.', table_name), CONCAT(ROUND(table_rows / 1000000, 2), 'M') rows, CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), 'G') DATA, CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), 'G') idx, CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), 'G') total_size, ROUND(index_length / data_length, 2) idxfrac FROM information_schema.TABLES ORDER BY data_length + index_length DESC LIMIT 10;

Número de tablas

Mientras que el sistema de archivos subyacente puede tener un límite en cuanto al número de archivos que representan tablas, MySQL no tiene límites respecto del número de tablas. Sin embargo, el número total de tablas que haya en el motor de almacenamiento de InnoDB de MySQL puede contribuir al deterioro del rendimiento, independientemente del tamaño que tengan esas tablas. Para limitar el efecto del sistema operativo, puede distribuir las tablas entre varias bases de datos en la misma instancia de base de datos MySQL. Si lo hace, se podría limitar el número de archivos que hay en un directorio, pero no se resolverá el problema general.

Si hay deterioro del rendimiento debido a un número de tablas grande (más de 10 000), es a causa de que MySQL está trabajando con archivos de almacenamiento, que incluye abrirlos y cerrarlos. Para atender esta cuestión, puede aumentar el tamaño de los parámetros table_open_cache y table_definition_cache. Sin embargo, aumentar los valores de esos parámetros podría aumentar considerablemente la cantidad de memoria que utiliza MySQL e incluso podría agotar toda la memoria disponible. Para obtener más información, consulte How MySQL Opens and Closes Tables, en la documentación de MySQL.

Además, que haya demasiadas tablas puede afectar considerablemente el tiempo de inicio de MySQL. Es posible que afecte la posibilidad de que haya un apagado y un reinicio perfectos, así como una recuperación ante bloqueos, especialmente en versiones anteriores a MySQL 8.0.

Recomendamos tener menos de 10 000 tablas en total distribuidas entre todas las bases de datos de una instancia de base de datos. Para un caso de uso con un número de tablas grande en una base de datos MySQL, consulte One Million Tables in MySQL 8.0.

Motor de almacenamiento

Las características de recuperación a un momento dado y restauración de instantáneas de Amazon RDS para MySQL requieren un motor de almacenamiento que pueda recuperarse si han ocurrido bloqueos y solo son compatibles con el motor de almacenamiento de InnoDB. Aunque MySQL admite varios motores de almacenamiento con diversas capacidades, no todos están optimizados para la recuperación en caso de bloqueo y la durabilidad de los datos. Por ejemplo, el motor de almacenamiento de MyISAM no admite la recuperación fiable tras bloqueo y podría impedir que la restauración a un momento dado o la restauración de instantáneas funcionen según lo previsto. Esto podría traducirse en datos perdidos o dañados cuando MySQL se reinicia después de un bloqueo.

InnoDB es el motor de almacenamiento recomendado y admitido para las instancias de base de datos de MySQL en Amazon RDS. Las instancias de base de datos de InnoDB también se pueden migrar a Aurora, mientras que las instancias de MyISAM no se pueden migrar. Sin embargo, MyISAM funciona mejor que InnoDB si se requiere una capacidad intensiva de búsqueda de texto completo. Si a pesar de ello quiere usar MyISAM con Amazon RDS, seguir los pasos que se describen en Copias de seguridad automatizadas con motores de almacenamiento de MySQL no compatibles puede resultar útil en algunas situaciones para la funcionalidad de restauración de instantáneas.

Si desea convertir tablas de MyISAM en tablas de InnoDB, puede utilizar el proceso que se describe en la documentación de MySQL. MyISAM e InnoDB tienen diferentes fortalezas y debilidades, por lo que debe evaluar a fondo el impacto de este cambio en sus aplicaciones antes de realizarlo.

Además, Amazon RDS no admite el motor de almacenamiento federado para MySQL.

Prácticas recomendadas para trabajar con motores de almacenamiento de MariaDB

Tanto el tamaño de las tablas como el número de tablas de una base de datos de MariaDB pueden afectar al rendimiento.

Tamaño de las tablas

Normalmente, las restricciones del sistema operativo relativas al tamaño de los archivos determinan el tamaño máximo efectivo de las tablas para las bases de datos de MariaDB. Por tanto, los límites generalmente no están determinados por restricciones internas de MariaDB.

En una instancia de base de datos de MariaDB, evite que las tablas de la base de datos aumenten demasiado de tamaño. Aunque el límite de almacenamiento general es 64 TiB, debido a los límites de almacenamiento aprovisionado el tamaño máximo de un archivo de tabla de MariaDB se restringe a 16 TiB. Divida las tablas grandes para que los tamaños de archivo estén claramente por debajo del límite de 16 TiB. Este método también puede mejorar el desempeño y el tiempo de recuperación.

Las tablas muy grandes (de más de 100 GB de tamaño) pueden afectar negativamente al rendimiento tanto de las lecturas como de las escrituras (incluidas las instrucciones de lenguaje de manipulación de datos o DML y especialmente las instrucciones lenguaje de definición de datos o DDL). Que haya índices en tablas grandes puede aumentar considerablemente el rendimiento de SELECT, pero también puede deteriorar el rendimiento de las instrucciones DML. Las instrucciones DDL, como ALTER TABLE, pueden ser considerablemente más lentas con las tablas grandes, pues con esas operaciones es posible que en algunos casos se reconstruya completamente una tabla. Con estas instrucciones DDL es posible que las tablas se bloqueen durante la duración de la operación.

La cantidad de memoria que requiere MariaDB para lecturas y escrituras depende de las tablas que se impliquen en las operaciones. Es una práctica recomendada tener al menos suficiente RAM para mantener los índices de las tablas que se utilicen activamente. Para determinar cuáles son las diez tablas e índices más grandes de una base de datos, utilice la siguiente consulta:

SELECT CONCAT(table_schema, '.', table_name), CONCAT(ROUND(table_rows / 1000000, 2), 'M') rows, CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), 'G') DATA, CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), 'G') idx, CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), 'G') total_size, ROUND(index_length / data_length, 2) idxfrac FROM information_schema.TABLES ORDER BY data_length + index_length DESC LIMIT 10;

Número de tablas

Mientras que el sistema de archivos subyacente puede tener un límite en cuanto al número de archivos que representan tablas, MariaDB no tiene límites respecto del número de tablas. Sin embargo, el número total de tablas que haya en el motor de almacenamiento de InnoDB de MariaDB puede contribuir al deterioro del rendimiento, independientemente del tamaño que tengan esas tablas. Para limitar el efecto del sistema operativo, puede distribuir las tablas entre varias bases de datos en la misma instancia de base de datos de MariaDB. Si lo hace, se podría limitar el número de archivos que hay en un directorio, pero no se resolverá el problema general.

Si hay deterioro del rendimiento debido a un número de tablas grande (más de 10 000), es a causa de que MariaDB está trabajando con archivos de almacenamiento, que incluye abrirlos y cerrarlos. Para atender esta cuestión, puede aumentar el tamaño de los parámetros table_open_cache y table_definition_cache. Sin embargo, aumentar los valores de esos parámetros podría aumentar considerablemente la cantidad de memoria que utiliza MariaDB e incluso podría agotar toda la memoria disponible. Para obtener más información, consulte Optimizing table_open_cache, en la documentación de MariaDB.

Además, que haya demasiadas tablas puede afectar considerablemente el tiempo de inicio de MariaDB. Es posible que afecte la posibilidad de que haya un apagado y un reinicio perfectos, así como una recuperación ante bloqueos. Recomendamos tener menos de 10 000 tablas en total distribuidas entre todas las bases de datos de una instancia de base de datos.

Motor de almacenamiento

Las características de restauración a un momento dado y restauración de instantáneas de Amazon RDS para MariaDB requieren un motor de almacenamiento que pueda recuperarse en caso de bloqueo. Aunque MariaDB admite varios motores de almacenamiento con diversas capacidades, no todos están optimizados para la recuperación en caso de bloqueo y la durabilidad de los datos. Por ejemplo, aunque Aria es un sustituto a prueba de bloqueos para MyISAM, también podría impedir que la restauración a un momento dado o la restauración de instantáneas funcionen según lo previsto. Esto podría traducirse en datos perdidos o dañados cuando MariaDB se reinicia después de un bloqueo. InnoDB (para la versión 10.2 y superiores) y XtraDB (para las versiones 10.0 y 10.1) son los motores de almacenamiento recomendados y admitidos para las instancias de base de datos de MariaDB en Amazon RDS. Si a pesar de ello quiere usar Aria con Amazon RDS, seguir los pasos que se describen en Copias de seguridad automatizadas con motores de almacenamiento de MariaDB no compatibles puede resultar útil en algunas situaciones para la funcionalidad de restauración de instantáneas.

Si desea convertir tablas de MyISAM en tablas de InnoDB, puede utilizar el proceso que se resume en la documentación de MariaDB. MyISAM e InnoDB tienen diferentes fortalezas y debilidades, por lo que debe evaluar a fondo el impacto de este cambio en sus aplicaciones antes de realizarlo.

Prácticas recomendadas para trabajar con Oracle

Para obtener información sobre las prácticas recomendadas para trabajar con Amazon RDS para Oracle, consulte Prácticas recomendadas para ejecutar Oracle Database en Amazon Web Services.

Un taller virtual de AWS 2020 incluyó una presentación sobre la ejecución de bases de datos Oracle de producción en Amazon RDS. Puede ver aquí un vídeo de la presentación:

Prácticas recomendadas para trabajar con PostgreSQL

Dos áreas importantes en las que puede mejorar el desempeño con PostgreSQL en Amazon RDS son la carga de datos en una instancia de base de datos y el uso de la característica autovacuum de PostgreSQL. Las siguientes secciones tratan algunas de las prácticas recomendadas para esas áreas.

Carga de datos en una instancia de base de datos de PostgreSQL

Cuando se cargan datos en una instancia de base de datos de PostgreSQL en Amazon RDS, se debe modificar la configuración de la instancia de base de datos y los valores del grupo de parámetros de base de datos para optimizar la eficiencia de la importación de los datos en su instancia de base de datos.

Modifique la configuración de su instancia de base de datos como se indica a continuación:

  • Deshabilite las copias de seguridad de la instancia de base de datos (defina backup_retention como 0)

  • Deshabilite el uso de varias zonas de disponibilidad

Modifique el grupo de parámetros de base de datos para incluir la siguiente configuración. Debe probar la configuración de los parámetros para encontrar los ajustes más eficientes para su instancia de base de datos:

  • Aumente el valor del parámetro maintenance_work_mem. Para obtener más información acerca de los parámetros de consumo de recursos de PostgreSQL, consulte la documentación de PostgreSQL.

  • Aumente el valor de los parámetros checkpoint_segments u checkpoint_timeout para reducir el número de escrituras en el log wal.

  • Deshabilite el parámetro synchronous_commit (no desactive FSYNC).

  • Deshabilite el parámetro autovacuum de PostgreSQL.

  • Asegúrese de que ninguna de las tablas que está importando esté sin registrar. Los datos almacenados en tablas sin registrar pueden perderse durante una conmutación por error. Para obtener más información, consulte el apartado de CREACIÓN DE TABLA SIN REGISTRAR.

Use los comandos pg_dump -Fc (comprimido) o pg_restore -j (paralelo) con estos ajustes.

Una vez finalizada la operación de carga, devuelva la instancia de base de datos y los parámetros de base de datos a su configuración normal.

Trabajo con la característica autovacuum de PostgreSQL

La característica autovacuum de las bases de datos de PostgreSQL es una función cuyo uso se recomienda para mantener la instancia de base de datos de PostgreSQL en buen estado. Autovacuum automatiza la ejecución de los comandos VACUUM y ANALYZE. El uso de autovacuum es requerido por PostgreSQL, no impuesto por Amazon RDS, y es esencial para un buen desempeño. La característica está habilitada de manera predeterminada para todas las nuevas instancias de base de datos de PostgreSQL en Amazon RDS, y los parámetros de configuración relacionados se definen correctamente de forma predeterminada.

El administrador de la base de datos debe conocer y entender esta operación de mantenimiento. Para obtener la documentación de PostgreSQL sobre autovacuum, consulte Routine Vacuuming.

Autovacuum no es una operación que no consuma recursos, pero funciona en segundo plano y deja a las operaciones del usuario toda la capacidad posible. Cuando está habilitado, autovacuum busca las tablas en las que se ha insertado, actualizado o eliminado un número elevado de tuplas. También protege contra la pérdida de los datos muy antiguos debida al reinicio de los ID de transacciones. Para obtener más información, consulte Preventing Transaction ID Wraparound Failures.

Autovacuum no se debe entender como una operación de alto consumo que se puede reducir para mejorar el desempeño. Por el contrario, las tablas con una velocidad alta de actualizaciones y eliminaciones se deteriorarán con rapidez si no se ejecuta autovacuum.

importante

No ejecutar autovacuum puede llevar a una interrupción para realizar una operación de vacío mucho más intrusiva. Cuando una instancia de base de datos de PostgreSQL en Amazon RDS deja de estar disponible por un uso excesivamente conservador de autovacuum, la base de datos de PostgreSQL se cierra para protegerse. En ese punto, Amazon RDS debe realizar un vacío completo en modo de un usuario directamente en la instancia de base de datos, lo que puede suponer una interrupción de varias horas. Por ello, es recomendable no desactivar autovacuum, que está habilitado de manera predeterminada.

Los parámetros de autovacuum determinan cuándo y con qué intensidad funciona autovacuum. Los parámetros autovacuum_vacuum_threshold y autovacuum_vacuum_scale_factor determinan cuándo se ejecuta autovacuum. Los parámetros autovacuum_max_workers, autovacuum_nap_time, autovacuum_cost_limit y autovacuum_cost_delay determinan la intensidad con la que trabaja autovacuum. Para obtener más información acerca de autovacuum, de cuándo se ejecuta y de los parámetros que requiere, consulte la documentación de PostgreSQL.

La siguiente consulta muestra el número de tuplas "muertas" en una tabla denominada table1:

PROMPT> select relname, n_dead_tup, last_vacuum, last_autovacuum from pg_catalog.pg_stat_all_tables where n_dead_tup > 0 and relname =  'table1';

Los resultados de la consulta serán similares a los siguientes:

relname | n_dead_tup | last_vacuum | last_autovacuum ---------+------------+-------------+----------------- tasks | 81430522 | | (1 row)

Prácticas recomendadas para trabajar con SQL Server

Entre las prácticas recomendadas para un despliegue Multi-AZ con una instancia de base de datos de SQL Server se incluyen las siguientes:

  • Use los eventos de base de datos de Amazon RDS para monitorizar las conmutaciones por error. Por ejemplo, puede recibir una notificación en un mensaje de texto o un correo electrónico cuando se produzca una conmutación por error de una instancia de base de datos. Para obtener más información acerca de los eventos de Amazon RDS, consulte Uso de las notificaciones de eventos de Amazon RDS.

  • Si su aplicación almacena en caché los valores DNS, defina el tiempo de vida (TTL) en menos de 30 segundos. Definir TTL en este valor es una práctica recomendada en caso de que se produzca una conmutación por error, una situación en la que la dirección IP podría cambiar y el valor en caché podría dejar de estar en servicio.

  • Es recomendable que no habilite los modos siguientes porque desactivan el registro de transacciones, que es necesario para el uso de varias zonas de disponibilidad:

    • Modo de recuperación simple

    • Modo sin conexión

    • Modo de solo lectura

  • Pruebe para determinar cuánto tiempo se tarda en completar la conmutación por error de la instancia de base de datos. El tiempo de la conmutación por error puede variar en función del tipo de base de datos, la clase de instancia y el tipo de almacenamiento utilizado. También debe probar la capacidad de su aplicación para seguir trabajando si se produce una conmutación por error.

  • Para acortar el tiempo necesario para la conmutación por error, debe hacer lo siguiente:

    • Compruebe que tiene asignadas las IOPS provisionadas necesarias para su carga de trabajo. Los valores de E/S inadecuados pueden alargar los tiempos de conmutación por error. La recuperación de la base de datos requiere E/S.

    • Use transacciones más pequeñas. La recuperación de bases de datos se basa en las transacciones, de modo que si divide las transacciones grandes en varias transacciones más pequeñas, el tiempo de conmutación por error debería acortarse.

  • Tenga en cuenta que, durante una conmutación por error, habrá latencias elevadas. Como parte del proceso de conmutación por error, Amazon RDS replica automáticamente los datos en una nueva instancia en espera. Esta replicación significa que los nuevos datos se confirman en dos instancias de base de datos diferentes, con lo que podría haber latencia hasta que la instancia de base de datos haya alcanzado el ritmo de la nueva instancia de base de datos principal.

  • Implemente sus aplicaciones en todas las zonas de disponibilidad. Si una zona de disponibilidad deja de funcionar, las aplicaciones de las otras zonas de disponibilidad seguirán estando disponibles.

Cuando trabaje con una implementación Multi-AZ de SQL Server, recuerde que Amazon RDS crea réplicas para todas las bases de datos de SQL Server de su instancia. Si no desea que determinadas bases de datos tengan réplicas secundarias, configure una instancia de base de datos independiente que no use Multi-AZ para esas bases de datos.

Vídeo sobre prácticas recomendadas deAmazon RDS SQL Server

La conferencia de AWS re:Invent de 2019 incluyó una presentación sobre nuevas características y prácticas recomendadas para trabajar con SQL Server en Amazon RDS. Puede ver aquí un vídeo de la presentación:

Trabajo con los grupos de parámetros de base de datos

Es recomendable que pruebe los cambios de los grupos de parámetros de base de datos en una instancia de base de datos de prueba antes de aplicarlos en las instancias de base de datos de producción. Si se configuran de forma incorrecta los parámetros del motor de base de datos de un grupo de parámetros de base de datos, pueden producirse efectos adversos no deseados, como la degradación del desempeño y la inestabilidad del sistema. Tenga cuidado siempre que modifique los parámetros del motor de base de datos y cree una copia de seguridad de la instancia de base de datos antes de modificar un grupo de parámetros de base de datos.

Para obtener información acerca del procedimiento para realizar la copia de seguridad de la instancia de base de datos, consulte Copia de seguridad y restauración de una instancia de base de datos de Amazon RDS.

Vídeo de presentación de nuevas características de Amazon RDS y prácticas recomendadas

La conferencia AWS re:Invent de 2019 incluyó una presentación sobre nuevas características y prácticas recomendadas de Amazon RDS para monitorear, analizar y ajustar el rendimiento de la base de datos mediante RDS. Puede ver aquí un vídeo de la presentación: