Preguntas frecuentes de Amazon Aurora
Aspectos generales
¿Qué es Amazon Aurora?
Amazon Aurora es un servicio de base de datos relacional moderno que ofrece rendimiento y alta disponibilidad a gran escala, ediciones de código abierto totalmente compatibles con MySQL y PostgreSQL y una amplia gama de herramientas para desarrolladores para crear aplicaciones sin servidor y controladas por machine learning (ML).
Aurora ofrece un sistema de almacenamiento distribuido, tolerante a errores y de recuperación automática que está desacoplado de los recursos de computación y que escala verticalmente de forma automática hasta 128 TiB por instancia de base de datos. Proporciona alto rendimiento y disponibilidad con hasta 15 réplicas de lectura de baja latencia, recuperación a un momento dado, generación de copias de seguridad continua en Amazon Simple Storage Service (Amazon S3) y replicación en tres zonas de disponibilidad (AZ).
Además, Aurora es un servicio completamente administrado que automatiza las tareas de administración que consumen mucho tiempo, como el aprovisionamiento de hardware, la configuración de la base de datos, la aplicación de parches y las copias de seguridad, mientras brinda la seguridad, la disponibilidad y la fiabilidad de las bases de datos comerciales por una décima parte del costo.
¿Amazon Aurora es compatible con MySQL?
Amazon Aurora es directamente compatible con las bases de datos de código abierto de MySQL existentes y agrega compatibilidad para los lanzamientos nuevos de forma periódica. Esto significa que puede migrar con facilidad bases de datos de MySQL a Aurora y desde Aurora mediante el uso de instantáneas o herramientas de importación y exportación estándares. Esto significa que la mayor parte del código, las aplicaciones, los controladores y las herramientas que ya utiliza con bases de datos MySQL también se pueden utilizar con Aurora con cambios mínimos o incluso sin necesidad de realizar ninguna modificación. Esto facilita la migración de aplicaciones entre los dos motores.
Puede ver la información de compatibilidad de la versión actual de Amazon Aurora MySQL en la documentación.
¿Amazon Aurora es compatible con PostgreSQL?
Amazon Aurora es directamente compatible con las bases de datos de código abierto de PostgreSQL existentes y agrega compatibilidad para los lanzamientos nuevos de manera periódica. Esto significa que puede migrar con facilidad bases de datos de PostgreSQL a Aurora y desde Aurora mediante el uso de instantáneas o herramientas de importación/exportación estándares. Esto también significa que la mayor parte del código, las aplicaciones, los controladores y las herramientas que ya utiliza con bases de datos PostgreSQL también se pueden utilizar con Aurora con cambios mínimos o incluso sin necesidad de realizar ninguna modificación.
Puede ver la información de compatibilidad de la versión actual de Amazon Aurora PostgreSQL en la documentación.
¿Cómo es la asistencia de Aurora PostgreSQL para los problemas relacionados con las extensiones de PostgreSQL?
Amazon es completamente compatible con Aurora PostgreSQL y todas las extensiones disponibles con Aurora. Si necesita asistencia para Aurora PostgreSQL, póngase en contacto con AWS Support. Si tiene una cuenta de AWS Premium Support activa, puede contactar con AWS Premium Support para conocer cuestiones específicas de Aurora.
¿Cómo puedo comenzar a utilizar Aurora?
Para probar Aurora, inicie sesión en la Consola de administración de AWS, seleccione RDS en la categoría Database (Base de datos) y elija Amazon Aurora como motor de base de datos. Para obtener una guía y recursos detallados, consulte nuestra página Introducción a Amazon Aurora.
¿En qué regiones de AWS se encuentra disponible Aurora?
Puede ver la disponibilidad de la región de Aurora aquí.
¿Cómo puedo migrar de MySQL a Aurora y viceversa?
Si quiere migrar de MySQL a Aurora y viceversa, tiene varias opciones:
- Puede utilizar el servicio mysqldump estándar para exportar datos desde MySQL y el servicio mysqlimport para importar datos a Aurora y viceversa.
- También puede utilizar la característica de migración Instantánea de base de datos de Amazon RDS para migrar una instantánea de base de datos de Amazon RDS para MySQL a Aurora mediante la consola de administración de AWS.
La migración a Aurora se completa para la mayoría de los clientes en menos de una hora, aunque la duración depende del formato y del tamaño del conjunto de datos. Para obtener más información, consulte Prácticas recomendadas para migrar bases de datos MySQL a Amazon Aurora.
¿Cómo puedo migrar de PostgreSQL a Aurora y viceversa?
Si desea migrar de PostgreSQL a Aurora y viceversa, tiene varias opciones:
- Puede emplear la utilidad pg_dump estándar para exportar datos desde PostgreSQL y la utilidad pg_restore para importar datos a Aurora y viceversa.
- También puede utilizar la característica de migración Instantánea de base de datos de Amazon RDS para migrar una instantánea de base de datos de Amazon RDS para PostgreSQL a Aurora mediante la consola de administración de AWS.
La migración a Aurora se completa para la mayoría de los clientes en menos de una hora, aunque la duración depende del formato y del tamaño del conjunto de datos.
Para migrar bases de datos de SQL Server a una edición compatible con PostgreSQL de Amazon Aurora, puede utilizar Babelfish para Aurora PostgreSQL. Las aplicaciones funcionarán sin ningún cambio. Consulte la documentación de Babelfish para obtener más información.
¿Necesito cambiar los controladores de cliente para utilizar la edición compatible con PostgreSQL de Amazon Aurora?
No, Aurora funciona con controladores de bases de datos PostgreSQL estándar.
Rendimiento
¿Qué significa “rendimiento cinco veces superior al de MySQL”?
Amazon Aurora ofrece mejoras importantes en comparación con el rendimiento de MySQL, ya que realiza una estrecha integración del motor de base de datos con la capa de almacenamiento virtualizado de uso general (SSD) para cargas de trabajo de base de datos, reduce las escrituras en el sistema de almacenamiento, minimiza la contención de bloqueos y elimina los retrasos que ocasionan los subprocesos del procesamiento de bases de datos.
Nuestras pruebas con SysBench en instancias r3.8xlarge revelan que Amazon Aurora ofrece más de 500 000 SELECT/segundo y más de 100 000 UPDATE/segundo, cinco veces más que cuando MySQL se ejecuta en el mismo hardware con la misma referencia. En la Guía de referencia de rendimiento de la edición compatible con MySQL de Amazon Aurora, se incluyen instrucciones detalladas sobre esta referencia y cómo replicarla.
¿Qué significa “rendimiento tres veces superior al de PostgreSQL”?
Amazon Aurora ofrece mejoras importantes en comparación con el desempeño de PostgreSQL, ya que realiza una estrecha integración del motor de base de datos con la capa de almacenamiento virtualizado basado en SSD para cargas de trabajo de base de datos, reduce las escrituras en el sistema de almacenamiento, minimiza la contención de bloqueos y elimina los retrasos que ocasionan los subprocesos del procesamiento de bases de datos.
Nuestras pruebas con SysBench en instancias r4.16xlarge revelan que Amazon Aurora ofrece una métrica de SELECT/segundo y UPDATE/segundo tres veces superior que cuando PostgreSQL se ejecuta en el mismo hardware con la misma referencia. En la Guía de referencia de rendimiento de la edición compatible con PostgreSQL de Amazon Aurora, se incluyen instrucciones detalladas sobre esta referencia y cómo replicarla.
¿Cómo puedo optimizar la carga de trabajo de la base de datos para la edición compatible con MySQL de Amazon Aurora?
Amazon Aurora está diseñado para ser compatible con MySQL, de forma que las herramientas y las aplicaciones de MySQL ya existentes puedan ejecutarse sin necesidad de realizar ninguna modificación. Sin embargo, un aspecto en el que Amazon Aurora supera a MySQL es en las cargas de trabajo con alto nivel de simultaneidad. Para maximizar el rendimiento de la carga de trabajo en Amazon Aurora, le aconsejamos que cree sus aplicaciones de manera que generen una gran cantidad de transacciones y consultas simultáneas.
¿Cómo puedo optimizar la carga de trabajo de la base de datos para la edición compatible con PostgreSQL de Amazon Aurora?
Amazon Aurora está diseñado para ser compatible con PostgreSQL, de forma que las herramientas y las aplicaciones de PostgreSQL ya existentes puedan ejecutarse sin necesidad de realizar ninguna modificación. Sin embargo, un aspecto en el que Amazon Aurora supera a PostgreSQL es en las cargas de trabajo con alto nivel de simultaneidad. Para maximizar el rendimiento de la carga de trabajo en Amazon Aurora, aconsejamos que cree sus aplicaciones de manera que generen una gran cantidad de transacciones y consultas simultáneas.
Facturación
¿Cuánto cuesta Aurora?
Para obtener información actualizada de los precios, consulte la página de precios de Aurora.
¿Aurora forma parte del nivel gratuito de AWS?
Por el momento, no hay ninguna oferta de nivel gratuito de AWS para Aurora. Sin embargo, Aurora almacena los datos de forma duradera en tres zonas de disponibilidad en una región y solo cobra por una copia de los datos. No se le cobrará por las copias de seguridad de hasta el 100 % del tamaño del clúster de bases de datos. Tampoco se cobrarán las instantáneas durante el periodo de retención de copias de seguridad configurado para el clúster de bases de datos.
Aurora replica datos en tres zonas de disponibilidad. ¿Esto significa que el precio aplicable por el almacenamiento será tres veces mayor que el que se muestra en la página de precios?
No, la replicación de Aurora está incluida en el precio. Los cargos se aplicarán en función del almacenamiento que la base de datos consuma en la capa de la base de datos, no por el almacenamiento consumido en la capa de almacenamiento virtual de Aurora.
¿Qué son las operaciones de E/S en Aurora y cómo se calculan?
E/S se refiere a las operaciones entrantes y salientes que realiza el motor de base de datos de Aurora en la capa de almacenamiento virtualizado basado en SSD. Cada operación de lectura de la página de la base de datos cuenta como una E/S.
El motor de la base de datos de Aurora emite lecturas contra la capa de almacenamiento para obtener páginas de la base de datos que no están presentes en la memoria en la caché:
- Si el tráfico de consultas puede entregarse totalmente desde la memoria o la caché, no se cobrará por recuperar ninguna página de datos desde la memoria.
- Si el tráfico de consultas no puede entregarse completamente desde la memoria, se cobrará por las páginas de datos que deban recuperarse del almacenamiento.
Cada página de la base de datos tiene 16 KB en la edición compatible con MySQL de Amazon Aurora y 8 KB en la edición compatible con PostgreSQL de Aurora.
Aurora se diseñó para eliminar operaciones de E/S innecesarias. Esto permite reducir costos y garantizar que los recursos estén disponibles cuando se necesiten para el tráfico de lectura y escritura. Las operaciones de E/S de escritura solo se consumen cuando se conservan registros de rehacer en la edición compatible con MySQL de Aurora o se escriben registros de avance en la edición compatible con PostgreSQL de Aurora en la capa de almacenamiento con el fin de hacer duraderas las escrituras.
Las operaciones de E/S de escritura se cuentan en unidades de 4 KB. Por ejemplo, un registro que tiene 1024 bytes se cuenta como una operación de E/S. Sin embargo, si el registro es mayor de 4 KB, se necesitará más de una operación de E/S de escritura para conservarlo.
Las operaciones de escritura simultáneas cuyo registro tenga menos de 4 KB se pueden agrupar por lotes en el motor de base de datos de Aurora para optimizar el consumo de operaciones de E/S. A diferencia de los motores de bases de datos tradicionales, Aurora nunca coloca páginas de datos incorrectos en el almacenamiento.
Para ver la cantidad de operaciones de E/S que consume una instancia de Aurora, diríjase a la consola de administración de AWS. Para buscar el consumo de operaciones de E/S, vaya a la sección Amazon RDS de la consola, observe la lista de instancias, seleccione las instancias de Aurora y, luego, busque las métricas VolumeReadIOPs y VolumeWriteIOPs en la sección de supervisión.
Para obtener más información sobre los precios de las operaciones de E/S, consulte la página de precios de Aurora. Se cobrará por las operaciones de E/S de lectura y escritura cuando configure los clústeres de bases de datos según la configuración de Aurora Standard. No se cobrará por las operaciones de E/S de lectura y escritura cuando configure los clústeres de bases de datos para que estén optimizados para Amazon Aurora I/O Optimized.
¿Qué son Aurora Standard y Aurora I/O Optimized?
Aurora ofrece la flexibilidad de optimizar su gasto en bases de datos al elegir entre dos opciones de configuración en función de sus necesidades de precio-rendimiento y previsibilidad de precios. Las dos opciones de configuración son Aurora estándar y Aurora optimizado para E/S. Ninguna de las dos opciones requiere un aprovisionamiento inicial de E/S o almacenamiento y ambas pueden escalar las operaciones de E/S para dar soporte a las aplicaciones más exigentes.
Aurora estándar es una configuración de clústeres de bases de datos que ofrece precios rentables para la gran mayoría de las aplicaciones con un uso de E/S bajo o moderado. Con Aurora Standard, usted paga por las instancias de bases de datos, el almacenamiento y las E/S de pago por solicitud.
Aurora optimizado para E/S es una configuración de clústeres de bases de datos que ofrece una mejor relación precio-rendimiento para aplicaciones con un uso intensivo de E/S, como los sistemas de procesamiento de pagos, los sistemas de comercio electrónico y las aplicaciones financieras. Además, si su gasto en E/S supera el 25 % del gasto total en bases de datos de Aurora, puede ahorrar hasta un 40 % en los costos de las cargas de trabajo intensivas de E/S con Aurora optimizado para E/S. Aurora optimizado para E/S ofrece precios predecibles para todas las aplicaciones, ya que no se cobran cargos por las operaciones de E/S de lectura y escritura, lo que hace que esta configuración sea ideal para cargas de trabajo con una alta variabilidad de E/S.
¿Cuándo debo usar Aurora I/O-Optimized?
Aurora I/O-Optimized es la opción ideal cuando necesita costos predecibles para cualquier aplicación. Ofrece una mejor relación precio-rendimiento para aplicaciones con uso intensivo de E/S, que requieren un alto rendimiento de escritura o ejecutan consultas de análisis que procesan grandes cantidades de datos. Para los clientes con un gasto de E/S superior al 25 % de su factura de Aurora, puede ahorrar hasta un 40 % en los costos de las cargas de trabajo intensivas de E/S con Aurora optimizado para E/S.
¿Cómo puedo migrar mi clúster de bases de datos existente para usar Aurora optimizado para E/S?
Puede utilizar la experiencia de un solo clic disponible en la Consola de administración de AWS para cambiar el tipo de almacenamiento de los clústeres de bases de datos existentes de modo que estén optimizados para Aurora I/O-Optimized. También puede invocar la Interfaz de la línea de comandos de AWS (AWS CLI) o el SDK de AWS para realizar este cambio.
¿Puedo alternar entre la configuración Aurora I/O-Optimized y la configuración Aurora Standard?
Puede cambiar a Aurora I/O-Optimized los clústeres de bases de datos existentes una vez cada 30 días. Puede volver a Aurora Standard en cualquier momento.
¿Aurora I/O-Optimized funciona con instancias reservadas?
Sí, Aurora I/O-Optimized funciona con las instancias reservadas de Aurora existentes. Aurora contabiliza automáticamente la diferencia de precio entre Aurora Standard y Aurora I/O-Optimized con instancias reservadas. Con los descuentos de instancias reservadas con Aurora I/O-Optimized, puede ahorrar aún más en sus gastos de E/S.
¿Cambia el precio de la retroactividad, la instantánea, la exportación o la copia de seguridad continua con Aurora I/O-Optimized?
No hay cambios en el precio de la retroactividad, la instantánea, la exportación o la copia de seguridad continua con Aurora I/O-Optimized.
¿Sigo pagando por las operaciones de E/S necesarias para replicar datos en todas las regiones con la Base de datos global de Aurora con Aurora I/O Optimized?
Sí, se siguen cobrando los cargos por las operaciones de E/S necesarias para replicar datos en todas las regiones. Aurora optimizado para E/S no cobra por las operaciones de E/S de lectura y escritura, lo cual es diferente de la replicación de datos.
¿Cuál es el costo de Amazon Aurora Optimized Reads para Aurora PostgreSQL?
No hay cargos adicionales por Amazon Aurora Optimized Reads para Aurora PostgreSQL, aparte del precio de las instancias R6id con tecnología de Intel y R6gd con tecnología de Graviton. Para más información, consulte la página de precios de Aurora.
Hardware y escalado
¿Cuáles son los límites máximos y mínimos de almacenamiento de una base de datos de Amazon Aurora?
El límite mínimo de almacenamiento es de 10 GB. El almacenamiento de Amazon Aurora aumentará de forma automática en función del uso de la base de datos, hasta 128 TB, en incrementos de 10 GB, sin que ello incida en el rendimiento de la base de datos. No es necesario aprovisionar el almacenamiento por adelantado.
¿Cómo puedo escalar los recursos de computación asociados con mi instancia de base de datos de Amazon Aurora?
Existen dos formas de escalar los recursos de computación asociados a mi instancia de base de datos de Amazon Aurora: a través de Aurora sin servidor y mediante un ajuste manual.
Puede utilizar Aurora sin servidor, una configuración bajo demanda de autoescalado para Amazon Aurora cuyo objetivo es escalar recursos de computación de bases de datos según la demanda de las aplicaciones. Esta configuración le permite ejecutar su base de datos en la nube, sin que tenga de preocuparse por la administración de la capacidad de la base de datos. Puede especificar el rango de capacidad de base de datos deseado y su base de datos escalará en función de las necesidades de la aplicación. Puede obtener más información en la Guía del usuario de Aurora sin servidor.
También puede escalar de manera manual sus recursos de computación asociados a su base de datos si selecciona el tipo de instancia de base de datos deseado en la consola de administración de AWS. El cambio solicitado se aplicará durante el periodo de mantenimiento que haya especificado; también puede utilizar la opción “Apply Immediately” (Aplicar de inmediato) para cambiar el tipo de instancia de base de datos de manera inmediata.
Ambas opciones afectarán la disponibilidad durante algunos minutos mientras se ejecuta la operación de escalado. Tenga en cuenta que también se aplicarán los demás cambios pendientes en el sistema.
Copia de seguridad y restauración
¿Cómo puedo habilitar las copias de seguridad para mi instancia de base de datos?
Las copias de seguridad automáticas siempre están habilitadas en las instancias de base de datos de Amazon Aurora. Las copias de seguridad no afectan el rendimiento de la base de datos.
¿Puedo realizar instantáneas de bases de datos y conservarlas durante el tiempo que desee?
Sí. Además, la realización de instantáneas no afecta el rendimiento. Tenga en cuenta que, para restablecer datos a partir de instantáneas de base de datos, es necesario crear una nueva instancia de base de datos.
Si se produce algún error en la base de datos, ¿qué ruta de recuperación debo seguir?
Amazon Aurora hace que sus datos duren de forma automática en tres zonas de disponibilidad (AZ) de una región e intentará recuperar automáticamente su base de datos en una AZ en buen estado sin pérdida de datos. En el extraño caso de que los datos no se encuentren disponibles en el almacenamiento de Amazon Aurora, puede restablecerlos a partir de una instantánea de base de datos o realizar una operación de restablecimiento puntual en una instancia nueva. Tenga en cuenta que el tiempo restablecible para una operación de restablecimiento en un momento dado puede llevarse a cabo dentro de los cinco minutos anteriores.
¿Qué sucede con las copias de seguridad automatizadas y las instantáneas de base de datos si elimino mi instancia de base de datos?
Puede optar por crear una instantánea de base de datos final al eliminar la instancia de base de datos. De ser así, puede usar esta instantánea de base de datos para restablecer la instancia de base de datos eliminada en un momento posterior. Amazon Aurora retiene esta instantánea de base de datos definitiva creada por el usuario junto con todas las demás instantáneas de bases de datos creadas manualmente después de haber eliminado la instancia de base de datos. Después de eliminar una instancia de base de datos, solo se retienen las instantáneas de base de datos (es decir, no se retienen las copias de seguridad automáticas creadas para un restablecimiento a un momento dado).
¿Puedo compartir mis instantáneas con otra cuenta de AWS?
Sí. Aurora le permite crear instantáneas de sus bases de datos, que puede usar más adelante para restaurar una base de datos. Puede compartir una instantánea con una cuenta distinta de AWS. El propietario de la cuenta de destino podrá usar esta instantánea para restaurar una base de datos que contenga sus datos. Incluso puede elegir que sus instantáneas sean públicas. Es decir, cualquiera podría restaurar una base de datos que contenga sus datos (públicos).
Puede usar esta característica para compartir datos entre diferentes entornos (producción, desarrollo/pruebas, ensayos, etc.) que tengan cuentas distintas, así como también conservar copias de seguridad de todos los datos seguras en una cuenta independiente en caso de que alguna vez su cuenta principal de AWS esté comprometida.
¿Se cobran las instantáneas compartidas?
Compartir instantáneas entre cuentas no conlleva ningún cargo. Sin embargo, es posible que se le cobre por las instantáneas, así como por cualquier base de datos que restaure a partir de instantáneas compartidas. Obtenga más información acerca de los precios de Aurora.
¿Puedo compartir instantáneas de forma automática?
No es posible compartir instantáneas de base de datos automáticas. Para compartir una instantánea, debe crear una copia de la instantánea de forma manual y compartirla.
¿Con cuántas cuentas puedo compartir instantáneas?
Puede compartir instantáneas manuales con hasta 20 ID de cuenta de AWS. Si desea compartir una instantánea con más de 20 cuentas, puede hacerla pública para compartirla o bien, contactar con el equipo de Soporte para incrementar esta cantidad.
¿En qué regiones puedo compartir mis instantáneas de Aurora?
Puede compartir sus instantáneas de Aurora en todas las regiones de AWS en las que se encuentra disponible Aurora.
¿Puedo compartir mis instantáneas de Aurora en distintas regiones?
No. Solo podrán acceder a las instantáneas de Aurora compartidas cuentas ubicadas en la misma región que la cuenta que los comparte.
¿Puedo compartir una instantánea de Aurora cifrada?
Sí, puede compartir instantáneas de Aurora cifradas.
Alta disponibilidad y replicación
¿Cómo mejora Amazon Aurora la tolerancia a errores de la base de datos ante errores de disco?
Amazon Aurora divide de manera automática el volumen de la base de datos en segmentos de 10 GB distribuidos en varios discos. Cada segmento de 10 GB del volumen de la base de datos se replica de seis formas en tres zonas de disponibilidad (AZ). Amazon Aurora es un servicio diseñado para administrar de manera transparente la pérdida de hasta dos copias de datos sin que ello afecte a la disponibilidad de escritura de la base de datos y hasta tres copias sin que incida en la disponibilidad de lectura.
El almacenamiento de Amazon Aurora también ofrece recuperación automática. Los bloques de datos y los discos se someten a análisis constantes para buscar errores, que se reparan automáticamente.
¿En qué medida Aurora mejora el tiempo de recuperación después de un bloqueo de la base de datos?
A diferencia de lo que ocurre con otras bases de datos, después de un bloqueo, Amazon Aurora no necesita reproducir el registro de rehacer a partir del último punto de comprobación de la base de datos (que suele ser cinco minutos) y confirmar que todos los cambios se hayan aplicado antes de habilitar la base de datos para las operaciones. Esto reduce el tiempo de reinicio de la base de datos a menos de 60 segundos en la mayoría de los casos.
Amazon Aurora extrae la caché del búfer del proceso de la base de datos y la habilita inmediatamente en el momento de realizar el reinicio. Esto evita la necesidad de limitar el acceso hasta que la caché se vuelva a llenar a fin de evitar interrupciones.
¿Qué tipos de réplicas admite Aurora?
La edición compatible con MySQL de Amazon Aurora y la edición compatible con PostgreSQL de Amazon Aurora admiten las réplicas de Amazon Aurora, que comparten el mismo volumen subyacente que la instancia principal en la misma región de AWS. Las actualizaciones realizadas por la instancia principal son visibles en todas las réplicas de Amazon Aurora.
Gracias a la edición compatible con MySQL de Amazon Aurora también puede crear réplicas de lectura de MySQL entre regiones basadas en el motor de replicación binlog de MySQL. En las réplicas de lectura de MySQL, los datos de la instancia principal se reproducen en su réplica como transacciones. En la mayoría de los casos de uso, entre otros, el escalado de lectura y la alta disponibilidad, recomendamos utilizar réplicas de Amazon Aurora.
Tiene la flexibilidad de combinar y asociar estos dos tipos de réplicas en función de las necesidades de la aplicación:
Característica | Réplicas de Amazon Aurora |
Réplicas de MySQL |
---|---|---|
Cantidad de réplicas | Hasta 15 | Hasta 5 |
Tipo de replicación | Asincrónica (milisegundos) | Asincrónica (segundos) |
Impacto en el rendimiento de la instancia principal | Bajo | Alto |
Ubicación de la réplica | En la región |
Entre regiones |
Funciona como destino de conmutación por error | Sí (sin pérdida de datos) | Sí (posible pérdida de minutos de datos) |
Conmutación por error automática | Sí | No |
Soporte para retraso de replicación definido por el usuario | No | Sí |
Soporte para datos o esquemas diferentes con respecto a la instancia principal | No | Sí |
Además de las opciones de replicación anteriores, cuenta con dos más. Puede usar la Base de datos global de Amazon para lograr una replicación física mucho más rápida entre clústeres de Aurora que se encuentren en diferentes regiones. Además, para la replicación entre bases de datos de Aurora y bases de datos que no sean de la edición compatible con MySQL de Aurora (inclusive fuera de AWS), puede configurar su propia replicación binlog autoadministrada.
¿Puedo tener réplicas entre regiones con Amazon Aurora?
Sí, puede configurar las réplicas de Aurora entre regiones por medio de la replicación física o lógica. La replicación física, llamada Amazon Aurora Global Database, utiliza una infraestructura dedicada que deja las bases de datos completamente disponibles para servir a la aplicación. Además, puede replicarse hasta en cinco regiones secundarias con una latencia típica de menos de un segundo. Está disponible para la edición compatible con MySQL de Aurora y la edición compatible con PostgreSQL de Aurora.
Para las lecturas globales de baja latencia y la recuperación de desastres, recomendamos utilizar Amazon Aurora Global Database.
Aurora es compatible con la replicación lógica nativa en cada motor de base de datos (binlog para MySQL y slot de replicación de PostgreSQL para PostgreSQL), lo que permite la replicación en bases de datos Aurora y en bases de datos que no son Aurora, incluso entre regiones.
La edición compatible con MySQL de Aurora también ofrece una característica de réplica de lectura lógica entre regiones y fácil de utilizar que admite hasta cinco regiones secundarias de AWS. Se basa en una única replicación binlog MySQL encadenada. Por lo tanto, el retraso de la replicación se verá afectado por la tasa de cambio/aplicación, así como cualquier retraso en la comunicación por red entre las regiones específicas seleccionadas.
¿Puedo crear réplicas de Aurora en el clúster de réplica entre regiones?
Sí, puede agregar hasta 15 réplicas de Aurora en cada clúster entre regiones, y estas compartirán el mismo almacenamiento subyacente que la réplica entre regiones. La réplica entre regiones funcionará como la instancia principal del clúster y las réplicas de Aurora en el clúster presentarán un retraso de décimas de milisegundos en comparación con la instancia principal.
¿Puedo conmutar por error mi aplicación desde la instancia principal actual a la réplica entre regiones?
Sí, puede convertir su réplica entre regiones en la nueva instancia principal a través de la consola de Amazon RDS. Para la replicación lógica (binlog), el proceso de conversión suele tardar unos minutos, en función de la carga de trabajo. La replicación entre regiones se detendrá una vez que inicie el proceso de conversión.
Con la Base de datos global de Amazon Aurora, puede convertir una región secundaria para que tome cargas de trabajo de lectura/escritura completas en menos de un minuto.
¿Puedo priorizar ciertas réplicas sobre otras como destinos de conmutación por error?
Sí. Puede asignar un nivel de prioridad de conversión a cada instancia del clúster. Cuando la instancia principal falle, Amazon RDS convertirá en instancia principal la réplica que tenga mayor prioridad. Si dos o más réplicas de Aurora comparten la misma prioridad, Amazon RDS convertirá en instancia principal a la réplica de mayor tamaño. Si dos o más réplicas de Aurora comparten prioridad y tamaño, Amazon RDS convertirá en instancia principal a una réplica cualquiera del mismo nivel de prioridad.
Para obtener más información sobre la lógica de conmutación por error, lea la guía del usuario de Amazon Aurora.
¿Puedo modificar los niveles de prioridad de las instancias una vez creadas?
Sí, puede modificar el nivel de prioridad de una instancia en cualquier momento. Modificar los niveles de prioridad no activará una conmutación por error.
¿Puedo impedir que determinadas réplicas se conviertan en instancia principal?
Puede asignar niveles de prioridad inferiores a las réplicas que no quiera que se conviertan en instancia principal. No obstante, si las réplicas de prioridad superior del clúster están en mal estado o no están disponibles por el motivo que sea, Amazon RDS convertirá la réplica de menor prioridad.
¿Cómo puedo mejorar la disponibilidad de una única base de datos de Amazon Aurora?
Puede agregar réplicas de Amazon Aurora. Las réplicas de Aurora en la misma región de AWS comparten el mismo almacenamiento subyacente que la instancia principal. Puede convertir cualquier réplica de Aurora en instancia principal sin que se produzcan pérdidas de datos, por lo que puede utilizarla para mejorar la tolerancia a errores en caso de que se produzca algún error en la instancia de base de datos primaria.
Para aumentar la disponibilidad de la base de datos, solo tiene que crear de 1 a 15 réplicas en cualquiera de las tres zonas de disponibilidad, y Amazon RDS las incluirá de forma automática en la selección de instancias principales para la conmutación por error en el caso de que se produzca una interrupción de la base de datos. Puede utilizar Amazon Aurora Global Database si desea que su base de datos abarque varias regiones de AWS. Esto replicará sus datos sin afectar el rendimiento de la base de datos y proporcionará una recuperación de desastres de interrupciones en toda la región.
¿Qué sucede durante la conmutación por error y cuánto tiempo lleva?
Amazon Aurora administra de manera automática la conmutación por error para que las aplicaciones puedan reanudar las operaciones de la base de datos a la mayor brevedad posible sin intervención administrativa manual.
- Si dispone de una réplica de Aurora en la misma zona de disponibilidad o en otra distinta, al realizar la conmutación por error, Aurora cambia el registro de nombre canónico (CNAME) de la instancia de base de datos para apuntar a la réplica en buen estado, que se convierte en la nueva instancia principal. La conmutación por error completa normalmente finaliza en 30 segundos o menos. Para mejorar la resiliencia y acelerar las conmutaciones por error, considere la posibilidad de utilizar Amazon RDS Proxy, que se conecta automáticamente a la instancia de base de datos de conmutación por error y, al mismo tiempo, conserva las conexiones de las aplicaciones. El proxy hace que las conmutaciones por error sean transparentes para sus aplicaciones y reduce los tiempos de conmutación por error hasta en un 66 %.
- Si está ejecutando Aurora sin servidor v1 y la instancia de base de datos o la zona de disponibilidad dejan de estar disponibles, Aurora volverá a crear la instancia de base de datos automáticamente en una zona de disponibilidad diferente. Aurora Serverless v2 funciona como aprovisionado para conmutación por error y otras características de alta disponibilidad. Para obtener más información, consulte Aurora sin servidor v2 y alta disponibilidad.
- Si no dispone de una réplica de Aurora (es decir, una instancia única) y no está ejecutando Aurora sin servidor, Aurora intentará crear una nueva instancia de base de datos en la misma zona de disponibilidad en la que se encuentra la instancia original. Este reemplazo de la instancia original se lleva a cabo con el mayor esfuerzo, pero puede fallar, por ejemplo, si existe un problema que esté afectando a la zona de disponibilidad de manera generalizada.
La aplicación debe reintentar establecer las conexiones de la base de datos en caso de que se pierda la conexión. La recuperación de desastres en todas las regiones es un proceso manual, en el cual se convierte una región secundaria para que tome cargas de trabajo de lectura/escritura.
¿Qué sucede si tengo una base de datos principal y una réplica de Amazon Aurora que reciben tráfico de lectura de manera activa y se produce una conmutación por error?
Amazon Aurora detectará de forma automática un problema en su instancia principal y activará una conmutación por error. Si está utilizando el punto de enlace del clúster, sus conexiones de lectura y escritura se redireccionarán de manera automática a una réplica de Amazon Aurora que se convertirá en principal.
Además, se interrumpirá momentáneamente el tráfico de lectura que atendían las réplicas de Aurora. Si está utilizando el punto de conexión del lector del clúster para direccionar su tráfico de lectura a la réplica de Aurora, las conexiones de solo lectura se direccionarán a la réplica de Aurora recientemente convertida en principal hasta que el nodo principal anterior se recupere como una réplica.
¿Cuál será el nivel de retraso de las réplicas en relación con la instancia principal?
Dado que las réplicas de Amazon Aurora comparten el mismo volumen de datos que la instancia principal en la misma región de AWS, no se produce prácticamente ningún retraso de replicación. Por lo general, observamos retrasos en decenas de milisegundos.
Para las replicación entre regiones, el retraso de replicación lógica con base en binlog puede aumentar indefinidamente en función de la tasa de cambio/aplicación, así como de los retrasos en la comunicación de red. No obstante, en condiciones normales, lo habitual es que el retraso de replicación sea inferior a un minuto. Las réplicas entre regiones que utilicen una replicación física de la Base de datos global de Amazon Aurora tendrán un retraso típico inferior a un segundo.
¿Puedo configurar una replicación entre mi base de datos con la edición compatible con MySQL de Aurora y una base de datos MySQL externa?
Sí, puede configurar una replicación binlog entre una instancia con la edición compatible con MySQL de Aurora y una base de datos MySQL externa. La otra base de datos se puede ejecutar en Amazon RDS o como una base de datos autoadministrada en AWS o completamente fuera de AWS.
Si ejecuta la edición compatible con MySQL 5.7 de Aurora, considere configurar una replicación binlog basada en identificadores de transacciones globales (GTID). De esta manera, se logra una coherencia completa para que su replicación no omita transacciones ni genere problemas, inclusive después de una conmutación por error o una interrupción del servicio.
¿Qué es Base de datos global de Amazon Aurora?
Base de datos global de Amazon Aurora es una característica que permite que una sola base de datos de Amazon Aurora abarque varias regiones de AWS. Replica sus datos sin afectar el rendimiento de la base de datos, permite lecturas locales rápidas en cada región con la latencia típica o de menos de un segundo y proporciona recuperación de desastres ante interrupciones en toda la región. En el caso improbable de una degradación o interrupción regional, una región secundaria se puede ascender para que tenga la capacidad completa de lectura/escritura en menos de un minuto. Esta característica está disponible para la edición compatible con MySQL de Aurora y la edición compatible con PostgreSQL de Aurora.
¿Cómo creo una Base de datos global de Amazon Aurora?
Puede crear una Base de datos global de Aurora con tan solo unos clics en la consola de Amazon RDS. Como alternativa, puede utilizar el Kit de desarrollo de software (SDK) de AWS o la AWS Command Line Interface (CLI). Debe aprovisionar al menos una instancia por región en su Base de datos global de Amazon Aurora.
¿Cuántas regiones secundarias puede tener una Base de datos global de Amazon Aurora?
Para una Base de datos global de Amazon Aurora, puede crear hasta cinco regiones secundarias.
Si utilizo Base de datos global de Amazon Aurora, ¿puedo también utilizar la replicación lógica (binlog) en la base de datos principal?
Sí. Si su objetivo es analizar la actividad de la base de datos, considere utilizar en su lugar la función de auditoría avanzada de Aurora, los registros generales y los registros de consultas lentas, para evitar afectar el rendimiento de su base de datos.
¿Aurora conmutará de manera automática a una región secundaria de una Base de datos global de Amazon Aurora?
No. Si su región principal no está disponible, puede eliminar de manera manual una región secundaria de una Base de datos global de Amazon Aurora y promoverla para que realice lecturas y escrituras completas. También deberá dirigir su aplicación a la región recientemente convertida.
Seguridad
¿Puedo utilizar Amazon Aurora en Amazon Virtual Private Cloud (Amazon VPC)?
Sí, todas las instancias de base de datos de Amazon Aurora deben crearse en una VPC. Con Amazon VPC, puede definir una topología de red virtual que refleje de forma detallada una red tradicional que tenga instaurada en su propio centro de datos. Esto le permite ejercer un control total sobre quién puede obtener acceso a las bases de datos de Amazon Aurora.
¿Amazon Aurora cifra los datos en tránsito y en reposo?
Sí. Amazon Aurora utiliza SSL (AES-256) para proteger la conexión entre la instancia de base de datos y la aplicación. Amazon Aurora le permite cifrar sus bases de datos mediante las claves que administra a través de AWS Key Management Service (AWS KMS).
En una instancia de base de datos que se ejecute con cifrado de Amazon Aurora, los datos almacenados en reposo en el almacenamiento subyacente están cifrados, al igual que las copias de seguridad automatizadas, las réplicas y las instantáneas en el mismo clúster. El cifrado y el descifrado se administran de forma ininterrumpida. Para obtener más información acerca del uso de AWS KMS con Amazon Aurora, consulte la guía del usuario de Amazon RDS.
¿Puedo cifrar una base de datos existente que no esté cifrada?
Actualmente, no se puede cifrar una instancia de Aurora que no esté cifrada. Para utilizar el cifrado de Amazon Aurora para una base de datos existente no cifrada, cree una nueva instancia de base de datos con cifrado habilitado y migre sus datos a ella.
¿Cómo obtengo acceso a mi base de datos de Amazon Aurora?
Se debe acceder a las bases de datos de Aurora a través del puerto de la base de datos ingresado en la creación de la base de datos. Esto ofrece a los datos una capa adicional de seguridad. En la Guía de conectividad de Amazon Aurora, se proporcionan instrucciones paso a paso sobre cómo conectarse a su base de datos de Amazon Aurora.
¿Puedo utilizar Amazon Aurora con aplicaciones que deban cumplir con HIPAA?
Sí, las ediciones de Aurora compatibles con MySQL y PostgreSQL son elegibles para HIPAA. Puede usarlas para crear aplicaciones compatibles con HIPAA y almacenar información relacionada con la atención médica, incluida la información de salud protegida (PHI), mediante un anexo comercial (BAA) ejecutado con AWS. Si ya cuenta con un BAA con AWS, no es necesario realizar ninguna otra acción para comenzar a utilizar estos servicios en las cuentas cubiertas por su BAA. Para obtener más información sobre el uso de AWS para crear aplicaciones compatibles, consulte Proveedores de atención médica.
¿Dónde puedo acceder a una lista de entradas de Vulnerabilidades y exposiciones comunes (CVE) a fin de consultar las vulnerabilidades de seguridad cibernética conocidas públicamente para las versiones de Amazon Aurora?
Actualmente puede encontrar una lista de CVE en Actualizaciones de seguridad de Amazon Aurora.
¿Cómo puedo detectar amenazas de seguridad a mi base de datos de Aurora?
Aurora está integrado con Amazon GuardDuty para ayudarlo a identificar posibles amenazas a los datos almacenados en las bases de datos de Aurora. La protección de RDS de GuardDuty perfila y supervisa la actividad de inicio de sesión en las bases de datos nuevas y existentes de su cuenta, y utiliza modelos de ML personalizados para detectar inicios de sesión sospechosos en las bases de datos de Aurora. Para obtener más información, consulteSupervisión de amenazas con la protección de RDS de GuardDuty y la guía del usuario de la protección de RDS de GuardDuty.
Tecnologías sin servidor
¿Qué es Amazon Aurora sin servidor?
Aurora sin servidor es una configuración de escalado automático bajo demanda para Amazon Aurora. Con Aurora sin servidor, puede ejecutar su base de datos en la nube sin administrar la capacidad de la base de datos. Administrar manualmente la capacidad de la base de datos puede llevar mucho tiempo y llevar a un uso ineficiente de los recursos de la base de datos. Con Aurora sin servidor, tan solo debe crear una base de datos, especificar el rango de capacidad de la base de datos deseado y conectar la aplicación. Aurora ajusta de manera automática la capacidad dentro del rango que especificó en función de las necesidades de la aplicación.
Se facturará por segundo por la capacidad de base de datos que utilice cuando la base de datos esté activa. Obtenga más información acerca de Aurora sin servidor y comience a utilizarlo con tan solo unos pasos desde la consola de administración de Amazon RDS.
¿Cuál es la diferencia entre Aurora sin servidor v2 y v1?
Aurora sin servidor v2 es compatible con todo tipo de cargas de trabajo de base de datos, desde desarrollo y entornos de prueba, sitios web y aplicaciones con cargas de trabajo poco frecuentes, intermitentes o impredecibles, hasta aquellas aplicaciones empresariales críticas más exigentes que requieren alta escalabilidad y disponibilidad. Aurora Serverless escala in situ al agregar más CPU y memoria sin tener que conmutar por error la base de datos a una instancia de base de datos más pequeña. Como resultado, es capaz de escalar incluso cuando hay transacciones de larga duración, bloqueos de tablas, etc.
Además, el servicio escala la capacidad de la base de datos en incrementos tan pequeños como media unidad de capacidad Aurora (ACU), de modo que la capacidad de base de datos coincida lo máximo posible con las necesidades de la aplicación.
Aurora sin servidor v1 es una opción rentable y sencilla para las cargas de trabajo poco frecuentes, intermitentes o impredecibles. Es capaz de iniciarse automáticamente, escalar la capacidad de computación para coincidir con el uso que hace la aplicación y dejar de funcionar cuando no está en uso. Para obtener más información, visite la guía del usuario de Aurora.
¿Qué características de Aurora son compatibles con Aurora sin servidor v2?
Aurora sin servidor v2 es compatible con todas las características de Aurora aprovisionado, incluidas la réplica de lectura, la configuración Multi-AZ, la Base de datos global de Aurora, RDS Proxy e Información de rendimiento.
¿Puedo empezar a usar Aurora sin servidor v2 con instancias aprovisionadas en mi clúster de bases de datos de Aurora existente?
Sí, puede comenzar a utilizar Aurora sin servidor v2 para administrar la capacidad de cálculo de la base de datos en su clúster de bases de datos de Aurora existente. Un clúster que contiene ambas instancias aprovisionadas además de Aurora Serverless v2 es un clúster de configuración combinada. Puede elegir cualquier combinación de instancias aprovisionadas y Aurora Serverless v2 en su clúster.
Para probar Aurora Serverless v2, debe agregar un lector a su clúster de base de datos de Aurora y seleccionar Serverless v2 como el tipo de instancia. Una vez que el lector ha sido creado y está disponible, puede comenzar a utilizar para cargas de trabajo de solo lectura. Tras confirmar que el lector funciona como se esperaba, puede iniciar una conmutación por error para comenzar a utilizar Aurora Serverless v2 para lectura y escritura. Esta opción brinda una experiencia de tiempo de inactividad mínimo para comenzar con Aurora sin servidor v2.
¿Puedo migrar de Aurora sin servidor v1 a Aurora sin servidor v2?
Sí, puedo migrar desde Aurora sin servidor v1 a Aurora sin servidor v2. Para obtener más información, consulte la guía del usuario de Aurora.
¿Qué versiones de Amazon Aurora son compatibles con Aurora sin servidor?
La información de compatibilidad de Aurora sin servidor v1 puede verse aquí. La información de compatibilidad de Aurora sin servidor v2 puede verse aquí.
¿Puedo migrar un clúster de bases de datos de Aurora existente a Aurora sin servidor?
Sí, puede restaurar una instantánea tomada de un clúster aprovisionado de Aurora existente en un clúster de bases de datos de Aurora sin servidor y viceversa.
¿Cómo establezco una conexión con un clúster de bases de datos de Aurora sin servidor?
Puede acceder a un clúster de bases de datos de Aurora sin servidor a partir de una aplicación cliente que se ejecute en la misma VPC. No puede asignarle una dirección IP pública a una bases de datos de Aurora sin servidor .
¿Puedo definir explícitamente la capacidad de un clúster de Aurora sin servidor?
Si bien Aurora sin servidor ajusta la escala automáticamente en función de la carga de la base de datos activa, en algunos casos, es posible que la capacidad no se ajuste con la suficiente rapidez como para respaldar una modificación repentina de la carga de trabajo, como un número elevado de transacciones nuevas. En estos casos, puede definir de manera explícita la capacidad en un valor específico con la consola de administración de AWS, AWS CLI o la API de Amazon RDS.
¿Por qué no se escala automáticamente mi clúster de bases de datos de Aurora sin servidor?
Una vez que se inicia una operación de escalado, Aurora sin servidor intenta encontrar un punto de escalado, que es el punto temporal en el cual la base de datos puede completar el escalado de manera segura. Es posible que Aurora sin servidor no pueda encontrar un punto de escalado si existen transacciones o consultas de ejecución prolongada en progreso o bien tablas temporales o bloqueos de tablas en uso.
¿Cómo se factura el uso de Aurora sin servidor?
En Aurora sin servidor, la capacidad de la base de datos se mide en ACU. Paga una tarifa fija por segundo de uso de ACU. Los costos de procesamiento para ejecutar las cargas de trabajo en Aurora sin servidor dependerán de la configuración del clúster de bases de datos que elija: Aurora estándar o Aurora optimizado para E/S. Visite la página de precios de Aurora para obtener información sobre precios y disponibilidad regional.
Consulta en paralelo
¿Qué es la consulta en paralelo de Amazon Aurora?
Amazon Aurora Parallel Query se refiere a la capacidad de reducir y distribuir la carga informática de una sola consulta en miles de CPU en la capa de almacenamiento de Aurora. Sin la consulta en paralelo, una consulta realizada en una base de datos de Amazon Aurora se ejecutaría completamente dentro de una instancia del clúster de bases de datos, de manera similar al funcionamiento de la mayoría de las bases de datos.
¿A qué casos de uso está destina?
La consulta en paralelo es una excelente opción para cargas de trabajo de análisis que necesitan datos actualizados y un buen rendimiento de consultas, inclusive en tablas de gran tamaño. A menudo, las cargas de trabajo de este tipo son de naturaleza operativa.
¿Qué beneficios ofrece la consulta en paralelo?
La consulta en paralelo ofrece un rendimiento más rápido, lo que agiliza las consultas analíticas hasta en dos órdenes de magnitud. También ofrece simplicidad operativa y actualización de datos, ya que puede enviar una consulta de forma directa a los datos transaccionales actuales en su clúster de Aurora. Además, la consulta en paralelo habilita las cargas de trabajo transaccionales y analíticas en la misma base de datos, lo que permite a Aurora mantener un alto rendimiento de transacciones junto con consultas analíticas simultáneas.
¿Qué tipos de consultas específicas mejoran con la consulta en paralelo?
Pueden beneficiarse la mayoría de las consultas que se realizan en conjuntos grandes de datos y que aún no se encuentran en un grupo de búferes. La primera versión de consulta en paralelo puede enviar y escalar horizontalmente del procesamiento en más de 200 proyecciones, combinaciones de igualdad y funciones SQL.
¿Qué nivel de mejora de rendimiento puedo esperar?
La mejora de rendimiento en una consulta específica depende de cuánto del plan de consulta se puede enviar a la capa de almacenamiento de Aurora. Los clientes informaron mejoras de una orden de magnitud en relación con la latencia de las consultas.
¿Existe alguna posibilidad de que el rendimiento sea más lento?
Sí, pero esperamos que dichos casos sean poco comunes.
¿Qué modificaciones debo introducir en mi consulta para poder aprovechar la consulta en paralelo?
No se necesita hacer ninguna modificación en la sintaxis de la consulta. El optimizador de consultas decidirá de manera automática si se utilizará la consulta en paralelo para su consulta específica. Para averiguar si una consulta está utilizando la consulta en paralelo, ejecute el comando EXPLAIN para ver el plan de ejecución de la consulta. Si desea omitir la heurística y forzar la consulta en paralelo para hacer pruebas, utilice la variable de sesión aurora_pq_force.
¿Cómo puedo activar o desactivar la función de consulta en paralelo?
La consulta en paralelo se puede activar y desactivar de manera dinámica a nivel de sesión y global con el parámetro aurora_pq.
¿Existen cargos adicionales asociados con el uso de la consulta en paralelo?
No. No se cobran cargos adicionales además de lo que ya paga por las instancias, la E/S y el almacenamiento.
Si la consulta en paralelo reduce la E/S, ¿activar la característica reducirá mis cargos de E/S de Aurora?
No, los costos de E/S de la consulta se calculan en la capa de almacenamiento y serán los mismos o mayores con la consulta en paralelo activada. El beneficio es la mejora en el nivel de rendimiento de las consultas.
Existen dos razones por las cuales se podrían generar costos de E/S más altos con la consulta en paralelo. En primer lugar, aunque algunos de los datos en una tabla estén en el grupo de búferes, la consulta en paralelo necesita que todos los datos se escaneen en la capa de almacenamiento, lo que genera E/S. En segundo lugar, un efecto secundario de evitar la contención en el grupo de búferes es que ejecutar una consulta en paralelo no prepara al grupo de búferes. Como resultado, las ejecuciones consecutivas de la misma consulta en paralelo generarán el costo pleno de E/S.
Obtenga más información sobre la consulta en paralelo en la documentación.
¿La consulta en paralelo se encuentra disponible con todos los tipos de instancias?
No. En este momento, puede utilizar la consulta en paralelo con instancias en la familia de instancias R*.
¿Qué versiones de Amazon Aurora admiten la consulta en paralelo?
La consulta en paralelo está disponible para la versión compatible con MySQL 5.7 y MySQL 8.0 de Amazon Aurora.
¿La consulta en paralelo es compatible con todas las demás características de Aurora?
La consulta en paralelo es compatible con Aurora Serverless v2 y Backtrack.
Si la consulta en paralelo agiliza las consultas con pérdidas de rendimiento aisladas, ¿no debería activarla para todas las bases de datos, todo el tiempo?
No. Si bien esperamos que la consulta en paralelo mejore la latencia de las consultas en la mayoría de los casos, podrían generarse costos de E/S elevados. Recomendamos que pruebe minuciosamente su carga de trabajo con la característica habilitada y deshabilitada. Una vez que esté convencido de que la consulta en paralelo es la opción correcta, podrá confiar en el optimizador de consultas para decidir de manera automática qué consultas utilizarán la consulta en paralelo. En el excepcional caso de que el optimizador no tome la decisión óptima, podrá omitir la configuración.
¿La consulta en paralelo de Aurora puede reemplazar mi almacenamiento de datos?
La consulta en paralelo de Aurora no es un almacenamiento de datos y, por lo tanto, no suministra la funcionalidad que normalmente ofrecen dichos productos. Está diseñada para acelerar el rendimiento de las consultas en su base de datos relacional y es adecuado para casos de uso como el análisis operativo, donde es necesario realizar consultas analíticas rápidas en datos actualizados en su base de datos.
Para un almacenamiento de datos en la nube a escala de exabytes, considere Amazon Redshift.
Optimized Reads
¿Qué es Amazon Aurora Optimized Reads para Aurora PostgreSQL?
Amazon Aurora Optimized Reads, disponible para Aurora PostgreSQL, es una nueva opción de precio y rendimiento que ofrece una latencia de consultas hasta 8 veces mejor y un ahorro de costos de hasta un 30 % en comparación con las instancias que no la tienen. Es ideal para aplicaciones con grandes conjuntos de datos que superan la capacidad de memoria de una instancia de base de datos.
¿Cómo mejora Amazon Aurora Optimized Reads para Aurora PostgreSQL el rendimiento de las consultas?
Las instancias de Amazon Aurora Optimized Reads utilizan almacenamiento local a nivel de bloques SSD con tecnología de NVMe (disponible en las instancias r6gd con tecnología de Graviton y r6id con tecnología de Intel) para mejorar la latencia de consultas de las aplicaciones con conjuntos de datos que superan la capacidad de memoria de una instancia de base de datos. Optimized Reads incluye mejoras de rendimiento, como el almacenamiento en caché por niveles y los objetos temporales.
El almacenamiento en caché por niveles ofrece una latencia de consultas hasta 8 veces mejor y un ahorro de costos de hasta un 30 % para aplicaciones con uso intensivo de E/S y lectura, como paneles operativos, detección de anomalías y búsquedas de similitudes basadas en vectores. Estas ventajas se obtienen al almacenar automáticamente en caché los datos expulsados de la memoria caché del búfer de la base de datos en memoria en el almacenamiento local para acelerar los accesos posteriores a esos datos. El almacenamiento en caché por niveles solo está disponible para la edición de Amazon Aurora compatible con PostgreSQL con la configuración de Aurora optimizado para E/S.
Los objetos temporales logran un procesamiento de consultas más rápido al colocar tablas temporales generadas mediante Aurora PostgreSQL en el almacenamiento local, lo que mejora el rendimiento de las consultas que implican ordenaciones, agregaciones de hash, uniones de alta carga y otras operaciones con uso intensivo de datos.
¿Cuándo debo usar Amazon Aurora Optimized Reads para Aurora PostgreSQL?
Amazon Aurora Optimized Reads para Aurora PostgreSQL ofrece a los clientes que tienen aplicaciones sensibles a la latencia y grandes conjuntos de trabajo una alternativa atractiva de precio y rendimiento para cumplir sus SLA empresariales y lograr aún más con sus instancias.
¿Qué tipos de instancias de base de datos admiten Amazon Aurora Optimized Reads para Aurora PostgreSQL? ¿En qué regiones están disponibles?
Amazon Aurora Optimized Reads está disponible en instancias R6gd con tecnología de Intel y R6gd con tecnología de Graviton. Puede ver la disponibilidad de la región de Aurora aquí.
¿Qué versiones de motor de Amazon Aurora admite Aurora Optimized Reads para Aurora PostgreSQL?
Amazon Aurora Optimized Reads está disponible para la edición de Aurora compatible con PostgreSQL en instancias R6id y R6gd. Las versiones de motor compatibles son la 15.4 y posterior y la 14.9 o posterior en Aurora PostgreSQL.
¿Puedo usar Amazon Aurora Optimized Reads para Aurora PostgreSQL con Aurora sin servidor v2?
Amazon Aurora Optimized Reads no está disponible en Aurora sin servidor v2 (ASv2).
¿Puedo usar Amazon Aurora Optimized Reads para Aurora PostgreSQL con las configuraciones Aurora Standard y Aurora optimizado para E/S?
Sí, Amazon Aurora Optimized Reads está disponible con ambas configuraciones. En ambas configuraciones, las instancias habilitadas para Optimized-Reads asignan automáticamente tablas temporales al almacenamiento local con tecnología de NVMe para mejorar el rendimiento de las consultas analíticas y las actualizaciones de índices.
Para cargas de trabajo intensivas de E/S con un uso intensivo de lectura, las instancias habilitadas para Optimized Reads en Aurora PostgreSQL configuradas para usar Aurora optimizado para E/S almacenan en caché automáticamente los datos expulsados de la memoria en el almacenamiento local con tecnología de NVMe para ofrecer una latencia de consultas hasta 8 veces mejor y hasta un 30 % de ahorro de costos en comparación con las instancias que no la tienen, para aplicaciones con grandes conjuntos de datos que superan la capacidad de memoria de una instancia de base de datos.
¿Cómo puedo empezar a utilizar Amazon Aurora Optimized Reads para Aurora PostgreSQL?
Los clientes pueden comenzar a utilizar Amazon Aurora Optimized Reads mediante la consola de administración de AWS, la CLI y el SDK. Optimized Reads está disponible en todas las instancias de R6id y R6gd de forma predeterminada. Para utilizar esta funcionalidad, los clientes pueden simplemente modificar sus clústeres de bases de datos de Aurora existentes para incluir instancias R6id y R6gd, o crear nuevos clústeres de bases de datos con estas instancias. Consulte la documentación de Amazon Aurora Optimized Reads para comenzar.
¿Qué parte del almacenamiento local disponible está disponible para Amazon Aurora Optimized Reads para Aurora PostgreSQL?
Aproximadamente el 90 % del almacenamiento local disponible en las instancias R6id y R6gd está disponible para Optimized Reads. Aurora reserva el 10 % del almacenamiento de NVMe para reducir el impacto de la amplificación de escritura en SSD. La asignación del almacenamiento disponible varía en función de las características de Optimized Reads que estén habilitadas.
Cuando se utiliza Optimized Reads con las características de objetos temporales y almacenamiento en caché por niveles, el espacio disponible para los objetos temporales en el almacenamiento local equivale al doble del tamaño de la memoria disponible en estas instancias de base de datos. Esto coincide con el tamaño actual del almacenamiento de objetos temporales en Aurora PostgreSQL. El espacio restante en el disco de almacenamiento local está disponible para almacenar datos en caché.
Cuando se utiliza Optimized Reads solo con la característica de objetos temporales, todo el espacio en el disco de almacenamiento local disponible está disponible para los objetos temporales. Por ejemplo, cuando se usa una instancia r6gd.8xlarge con las características de objetos temporales y almacenamiento en caché por niveles, se reservan 534 GiB (el doble de la capacidad de memoria) para los objetos temporales y 1054 GiB para la memoria caché por niveles.
¿Qué sucede en caso de error en el almacenamiento local?
Si se produce un error en el almacenamiento local, Aurora hace automáticamente un reemplazo del host. En un clúster de base de datos de varios nodos, esto desencadena una conmutación por error en la región.
¿Qué efecto tiene Amazon Aurora Optimized Reads para Aurora PostgreSQL en la latencia de las consultas en caso de una conmutación por error de la base de datos?
En caso de una conmutación por error de la base de datos, la latencia de las consultas aumentará temporalmente tras la conmutación por error. Este aumento de latencia se reducirá con el tiempo y, finalmente, recuperará la latencia de consulta anterior a la conmutación por error. Esta duración de recuperación se puede acelerar si se habilita la administración de caché de clústeres (CCM). Con CCM, los clientes pueden designar una instancia de base de datos de Aurora PostgreSQL específica como destino de conmutación por error.
Cuando se habilita CCM, la caché de almacenamiento local del destino de conmutación por error designado refleja fielmente la caché de almacenamiento local de la instancia principal, lo que reduce el tiempo de recuperación tras la conmutación por error. Sin embargo, la habilitación de CCM podría afectar a la eficacia de la memoria caché de almacenamiento local a largo plazo si el destino de conmutación por error designado también se utiliza para atender una carga de trabajo de lectura independiente de la carga de trabajo de la instancia de escritura.
Por lo tanto, los clientes que ejecutan cargas de trabajo que requieren la designación de un lector como conmutación por error en espera deben permitir que CCM aumente sus probabilidades de recuperar rápidamente la latencia de consultas tras la conmutación por error. Es posible que los clientes que ejecutan cargas de trabajo independientes en sus objetivos de conmutación por error designados quieran equilibrar sus necesidades de recuperación inmediata de la latencia tras la conmutación por error con la eficacia a largo plazo del rendimiento de la caché, antes de habilitar la CCM.
IA generativa
¿Qué es pgvector?
pgvector es una extensión de código abierto para PostgreSQL compatible con Amazon Aurora PostgreSQL Edition.
¿Qué capacidades habilita pgvector para Aurora PostgreSQL?
¿Funciona pgvector con el machine learning de Aurora?
Sí. El machine learning (ML) de Aurora expone los modelos de ML como funciones SQL, lo que le permite usar SQL estándar para llamar a los modelos de ML, pasarles datos y devolver predicciones como resultados de consultas. pgvector requiere que las incrustaciones vectoriales se almacenen en la base de datos, lo que requiere ejecutar el modelo de ML en el texto de origen o los datos de imagen para generar incrustaciones y, a continuación, mover las incrustaciones por lotes a Aurora PostgreSQL.
El ML de Aurora puede hacer que este proceso se haga en tiempo real, lo que permite que las incrustaciones se mantengan actualizadas en Aurora PostgreSQL mediante llamadas periódicas a Amazon Bedrock o Amazon SageMaker, que devuelve las incrustaciones más recientes de su modelo.
¿Cómo ayudan las lecturas optimizadas de Aurora para Aurora PostgreSQL al rendimiento de pgvector?
Amazon Aurora PostgreSQL Optimized Reads con pgvector aumentan hasta 9 veces las consultas por segundo para la búsqueda vectorial en las cargas de trabajo que superan la memoria de instancias disponible. Esto es posible gracias a la capacidad de almacenamiento en caché por niveles que se encuentra disponible en Optimized Reads, que almacena automáticamente en caché los datos expulsados de la memoria caché del búfer de la base de datos en memoria en el almacenamiento local para acelerar los accesos posteriores a esos datos.
Integraciones sin ETL
¿Cuándo debo usar la integración sin ETL de Aurora con Amazon Redshift?
Debe utilizar la integración sin ETL de Amazon Aurora con Amazon Redshift cuando necesite acceso casi en tiempo real a los datos transaccionales. Esta integración le permite aprovechar el ML de Amazon Redshift con comandos SQL sencillos.
¿Qué motores y versiones de Aurora admiten integraciones sin ETL?
La integración sin ETL de Aurora con Amazon Redshift está disponible en la edición Aurora compatible con MySQL para Aurora MySQL 3.05 (compatible con MySQL 8.0.32) y versiones posteriores en las regiones Este de EE. UU. (Ohio), Este de EE. UU. (Norte de Virginia), Oeste de EE. UU. (Oregón), Asia-Pacífico (Singapur), Asia-Pacífico (Sídney), Asia-Pacífico (Tokio), Europa (Fráncfort), Europa (Irlanda) y Europa (Estocolmo). La integración sin ETL de Aurora con Amazon Redshift está disponible en la edición compatible con Aurora PostgreSQL para Aurora PostgreSQL 15.4 en la región Este de EE. UU. (Ohio).
¿Qué beneficios ofrece la integración sin ETL?
La integración sin ETL de Aurora con Amazon Redshift elimina la necesidad de crear y mantener canalizaciones de datos complejas. Puede consolidar los datos de uno o varios clústeres de bases de datos de Aurora en un único clúster de base de datos de Amazon Redshift y ejecutar análisis y ML casi en tiempo real con Amazon Redshift en petabytes de datos transaccionales de Aurora.
¿La integración sin ETL es compatible con Aurora sin servidor v2?
La integración sin ETL de Aurora con Amazon Redshift es compatible con Aurora sin servidor v2. Al utilizar tanto Aurora sin servidor v2 como Amazon Redshift sin servidor, puede generar análisis casi en tiempo real de los datos transaccionales sin tener que administrar ninguna infraestructura para canalizaciones de datos.
¿Cómo comienzo con una integración sin ETL?
Para empezar, utilice la consola de Amazon RDS para crear la integración sin ETL especificando el origen de Aurora y el destino de Amazon Redshift. Una vez creada la integración, la base de datos de Aurora se replicará en Amazon Redshift y podrá empezar a consultar los datos una vez que se complete la fase inicial. Para obtener más información, lea la guía de introducción a las integraciones sin ETL de Aurora con Amazon Redshift.
¿Cuánto cuesta la integración sin ETL?
La integración sin ETL y el procesamiento continuo de los cambios de datos se ofrecen sin cargos adicionales. Usted paga por los recursos existentes de Amazon RDS y Amazon Redshift que se utilizan para crear y procesar los datos de cambios generados como parte de una integración sin ETL. Estos recursos podrían incluir:
- E/S y almacenamiento adicionales que se utilizan al habilitar un binlog mejorado
- Costos de exportación de instantáneas para la exportación inicial de datos para crear bases de datos de Amazon Redshift
- Almacenamiento adicional en Amazon Redshift para almacenar datos replicados
- Costos de transferencia de datos entre zonas de disponibilidad para mover datos del origen al destino
Para obtener más información, visite la página de precios de Aurora.
Amazon DevOps Guru para RDS
¿Qué es Amazon DevOps Guru para RDS?
Amazon DevOps Guru para RDS es una nueva capacidad basada en machine learning (ML) para Amazon RDS (que incluye a Amazon Aurora), que está diseñada para detectar y diagnosticar de forma automática el rendimiento de la base de datos y los problemas operativos, lo que permite resolver problemas en minutos en lugar de días.
Amazon DevOps Guru para RDS es una característica de Amazon DevOps Guru, que está diseñada para detectar problemas operativos y de rendimiento para todos los motores de Amazon RDS y docenas de otros tipos de recursos. DevOps Guru para RDS amplía las capacidades existentes de DevOps Guru para detectar, diagnosticar y remediar una amplia variedad de problemas relacionados con la base de datos en Amazon RDS (como el uso excesivo de recursos y el mal comportamiento de determinadas consultas de SQL).
Cuando surge un problema, Amazon DevOps Guru para RDS está diseñado para notificar de manera inmediata a los desarrolladores y los ingenieros de DevOps y proporciona información de diagnóstico, detalles sobre el alcance del problema y recomendaciones de corrección inteligente para ayudar a los clientes a resolver rápidamente cuellos de botella de rendimiento relacionados con la base de datos y problemas operativos.
¿Por qué debería utilizar DevOps Guru para RDS?
Amazon DevOps Guru para RDS está diseñado para eliminar el esfuerzo manual y ahorrar tiempo (de horas a días y luego a minutos) para detectar y resolver cuellos de botella de rendimiento difíciles de encontrar en la carga de trabajo de la base de datos relacional.
Puede habilitar DevOps Guru para RDS para cada base de datos de Amazon Aurora, el cual detectará de forma automática problemas de rendimiento de sus cargas de trabajo, enviará alertas sobre cada problema, explicará los hallazgos y recomendará acciones para resolver los problemas.
DevOps Guru para RDS ayuda a que la administración de bases de datos sea más accesible para quienes no son expertos y ayuda a los expertos de bases de datos para que puedan administrar aún más bases de datos.
¿Cómo funciona Amazon DevOps Guru para RDS?
Amazon DevOps Guru para RDS utiliza ML para analizar los datos de telemetría recopilados por la Información de rendimiento de Amazon RDS. DevOps Guru para RDS no utiliza ninguno de los datos almacenados en la base de datos durante su análisis. La información sobre rendimiento mide la carga de la base de datos, una métrica que caracteriza cómo una aplicación pasa tiempo en la base de datos y las métricas seleccionadas generadas por la base de datos, como las variables de estado del servidor en MySQL y las tablas pg_stat en PostgreSQL.
¿Cómo puedo comenzar a utilizar Amazon DevOps Guru para RDS?
Para comenzar a utilizar DevOps Guru para RDS, asegúrese de que la información sobre rendimiento esté habilitada a través de la consola de RDS y, luego, simplemente habilite DevOps Guru para las bases de datos de Amazon Aurora. Con DevOps Guru, puede elegir que el límite de cobertura de análisis sea toda su cuenta de AWS, prescribir las pilas de AWS CloudFormation específicas que desea que DevOps Guru analice, o utilizar etiquetas de AWS para crear la agrupación de recursos que desea que DevOps Guru analice.
¿Qué tipos de problemas puede detectar Amazon DevOps Guru para RDS?
Amazon DevOps Guru para RDS ayuda a identificar una amplia variedad de problemas de rendimiento que pueden afectar la calidad del servicio de la aplicación, como bloqueos acumulados, tormentas de conexión, regresiones SQL, contención de CPU y E/S y problemas de memoria.
¿En qué se diferencia DevOps Guru para RDS de la información de rendimiento de Amazon RDS?
La Información de rendimiento de Amazon RDS es una característica de ajuste y supervisión del rendimiento de las bases de datos que recopila y visualiza las métricas de rendimiento de la base de datos de Amazon RDS, lo que ayuda a evaluar de forma rápida la carga en las bases de datos y determinar cuándo y dónde tomar las medidas oportunas. Amazon DevOps Guru para RDS está diseñado para supervisar esas métricas, detectar cuándo la base de datos está experimentando problemas de rendimiento, analizar las métricas y, luego, decirle qué está mal y qué puede hacer al respecto.
API de datos
¿Cuándo debo usar la API de datos con Aurora en lugar de los controladores de bases de datos?
Debe usar la API de datos para nuevas aplicaciones modernas, en particular aquellas creadas con AWS Lambda que necesitan acceder a Aurora en un modelo de solicitud/respuesta. Debe usar controladores de base de datos en lugar de la API de datos y administrar las conexiones de base de datos persistentes cuando una aplicación existente esté muy acoplada a los controladores de base de datos, cuando existen consultas de ejecución prolongada o cuando el desarrollador quiera aprovechar las características de la base de datos, como las tablas temporales, o usar variables de sesión.
¿Qué motores y versiones de Aurora son compatibles con la API de datos?
En nuestra documentación encontrará la disponibilidad de la región de AWS y de la versión de la base de datos de la API de datos para las instancias aprovisionadas de Aurora sin servidor v2 y Aurora. Se recomienda a los clientes que actualmente utilizan la API de datos para Aurora sin servidor v1 que migren a Aurora sin servidor v2 para aprovechar la API de datos rediseñada y el escalado más granular de Aurora sin servidor v2.
¿Qué ventajas ofrece la API de datos?
La API de datos le permitirá simplificar y acelerar el desarrollo de aplicaciones modernas. La API de datos es una API segura y fácil de usar basada en HTTP que elimina la necesidad de desplegar controladores de bases de datos, administrar grupos de conexiones del lado del cliente o configurar redes de VPC complejas entre la aplicación y la base de datos. La API de datos también mejora la escalabilidad al agrupar y compartir automáticamente las conexiones de bases de datos, lo que reduce la sobrecarga computacional de las aplicaciones que abren y cierran conexiones con frecuencia.
¿La API de datos es compatible con la base de datos global de Aurora o Aurora sin servidor v1?
La API de datos existente para Aurora sin servidor v1 seguirá siendo una característica de Aurora sin servidor v1 tanto para la edición compatible con PostgreSQL como para la edición compatible con MySQL de Aurora. La API de datos para las instancias aprovisionadas de Aurora sin servidor v2 y Aurora no es compatible con Aurora sin servidor v1. La API de datos para Aurora sin servidor v2 y las instancias aprovisionadas de Aurora son compatibles con las instancias de escritor de la base de datos global de Aurora.
¿Cómo me autentico en la base de datos mediante la API de datos?
Los usuarios pueden invocar las operaciones de la API de datos solo si están autorizados a hacerlo. Los administradores pueden conceder a un usuario permiso para usar la API de datos adjuntando una política de AWS Identity and Access Management (IAM) que defina sus privilegios. También puede adjuntar la política a un rol si utiliza roles de IAM. Al llamar a la API de datos, puede transferir las credenciales del clúster de base de datos Aurora mediante un secreto en AWS Secrets Manager.
¿Cuánto cuesta la API de datos?
El uso de la API de datos con Aurora sin servidor v1 sigue disponible sin cargo adicional. La API de datos para las instancias aprovisionadas de Aurora sin servidor v2 y Aurora tiene un precio por volumen de solicitudes de API, tal como se describe en la página de precios de Aurora. La API de datos para las instancias aprovisionadas de Aurora sin servidor v2 y Aurora usa eventos del plano de datos de AWS CloudTrail para registrar la actividad en lugar de eventos de administración, como ocurría con la API de datos para Aurora sin servidor v1.
Puede habilitar el registro de eventos de datos a través de la consola, la CLI o el SDK de CloudTrail si desea realizar un seguimiento de esta actividad. Esto generará cargos según lo establecido en la página de precios de CloudTrail. Además, el uso de AWS Secrets Manager generará cargos según lo establecido en la página de precios de AWS Secrets Manager.
¿Por qué AWS comenzó a usar eventos de plano de datos para la API de datos en lugar de eventos de administración de CloudTrail?
AWS CloudTrail captura la actividad de la API de AWS como eventos de administración o eventos de datos. Los eventos de administración de CloudTrail (también conocidos como “operaciones de plano de control”) muestran las operaciones de administración que se realizan en los recursos de su cuenta de AWS, como crear, actualizar y eliminar un recurso. Los eventos de datos de CloudTrail (también conocidos como “operaciones de plano de datos”) muestran las operaciones de recursos realizadas en o dentro de un recurso de su cuenta de AWS.
La API de datos realiza operaciones de plano de datos, ya que realiza consultas en los datos de la base de datos Aurora. Por lo tanto, registraremos la actividad de la API de datos como eventos de datos, ya que esta es la categorización correcta de los eventos. Solo se cobrarán cargos por los eventos de datos de CloudTrail si habilita el registro de eventos de datos.
¿La API de datos tiene una capa gratuita?
Sí, la capa gratuita de la API de datos incluye un millón de solicitudes al mes, agregadas en todas las regiones de AWS, durante el primer año de uso. Transcurrido un año, los clientes comenzarán a pagar por la API de datos tal y como se describe en la página de precios de Aurora.
Despliegue azul-verde de Amazon RDS
¿Qué versiones son compatibles con las implementaciones azul-verde de Amazon RDS?
Las implementaciones azul-verde de Amazon RDS están disponibles en las versiones 5.6 y posteriores de la edición compatible con PostgreSQL de Amazon Aurora y en las versiones 11.21 y posteriores, 12.16 y posteriores, 13.12 y posteriores, 14.9 y posteriores y 15.4 y posteriores. Obtenga más información sobre las versiones disponibles en la documentación de Aurora.
¿Qué regiones son compatibles con las implementaciones azul-verde de Amazon RDS?
Las implementaciones azul-verde de Amazon RDS están disponibles en todas las regiones de AWS y las regiones de AWS GovCloud.
¿Cuándo debo usar las implementaciones azul-verde de Amazon RDS?
Las implementaciones azul-verde de Amazon RDS le permiten realizar cambios de bases de datos con mayor seguridad, sencillez y rapidez. Las implementaciones azul-verde son ideales para casos de uso como actualizaciones del motor de bases de datos de versiones principales o secundarias, actualizaciones del sistema operativo, cambios de esquema en entornos verdes que no interrumpen la replicación lógica, como agregar una nueva columna al final de una tabla o cambios en la configuración de los parámetros de la base de datos.
Puede utilizar las implementaciones azul-verde para realizar varias actualizaciones de bases de datos al mismo tiempo mediante una sola conmutación. Esto le permite mantenerse al día con las revisiones de seguridad, mejorar el rendimiento de la base de datos y acceder a las características más recientes de la base de datos con un tiempo de inactividad breve y predecible. Si solo desea realizar una actualización menor de la versión de Aurora, le recomendamos que utilice la aplicación de parches con tiempo de inactividad cero (ZDP, Zero Downtime Patching).
¿Cuál es el costo de usar las implementaciones azul-verde de Amazon RDS?
El precio por ejecutar sus cargas de trabajo en las instancias verdes será el mismo que el de las instancias azules. El costo de ejecución en instancias azules y verdes incluye nuestro precio estándar actual para db.instances, costo de almacenamiento, costo de E/S de lectura/escritura y cualquier característica habilitada, como costo de copias de seguridad e Información de rendimiento de Amazon RDS. De hecho, paga aproximadamente el doble del costo para ejecutar cargas de trabajo en db.instance durante la vida útil de la implementación azul-verde.
Por ejemplo: tiene un clúster de la edición compatible con MySQL de Aurora 5.7 que se ejecuta en dos db.instances r5.2xlarge, una instancia de escritura principal y una instancia de lectura, en la región us-east-1 de AWS. Cada una de las db.instances r5.2xlarge está configurada para almacenamiento de 40 GiB y tiene 25 millones de E/S por mes. Crea un clon de la topología de la instancia azul con las implementaciones azul-verde de Amazon RDS, lo ejecuta durante 15 días (360 horas) y cada instancia verde tiene 3 millones de lecturas de E/S durante ese tiempo. Luego, elimina las instancias azules después de una conmutación exitosa. Las instancias azules (escritor y lector) cuestan 849,2 USD por 15 días a una tarifa bajo demanda de 1,179 USD/h (instancia + almacenamiento + E/S). Las instancias verdes (escritor y lector) cuestan 840,40 USD por 15 días a una tarifa bajo demanda de 1,167 USD/h (instancia + almacenamiento + E/S). El costo total por usar despliegues azul-verde durante esos 15 días es de 1689,60 USD, que es aproximadamente el doble del costo de ejecutar instancias azules durante ese periodo.
¿Qué tipo de cambios puedo hacer con las implementaciones azul-verde de Amazon RDS?
Las implementaciones azul-verde de Amazon RDS lo ayudan a realizar cambios de bases de datos más seguros, simples y rápidos, como actualizaciones de versiones principales o secundarias, cambios de esquema, escalado de instancias, cambios de parámetros del motor y actualizaciones de mantenimiento.
¿Qué es el “entorno azul” en las implementaciones azul-verde de Amazon RDS? ¿Qué es un “entorno verde”?
En las implementaciones azul-verde de Amazon RDS, el entorno azul es el entorno de producción actual. El entorno verde es el entorno de ensayo, que será el nuevo entorno de producción después de la conmutación.
¿Cómo funcionan las conmutaciones con las implementaciones azul-verde de Amazon RDS?
Cuando las implementaciones azul-verde de Amazon RDS inician una conmutación, se bloquean las escrituras en los entornos azul y verde hasta que se completa la conmutación. Durante la conmutación, el entorno de ensayo, o entorno verde, se actualiza con el sistema de producción, lo que garantiza que los datos sean coherentes entre el entorno de ensayo y el de producción. Una vez que los entornos de producción y ensayo están completamente sincronizados, las implementaciones azul-verde promocionan el entorno de ensayo como nuevo entorno de producción al redirigir el tráfico al entorno de producción recién promocionado.
Las implementaciones azul-verde de Amazon RDS están diseñadas para permitir escrituras en el entorno verde después de que se completa la conmutación, lo que garantiza que no se pierdan datos durante el proceso de conmutación.
Después de que las implementaciones azul-verde de Amazon RDS conmutan, ¿qué sucede con mi antiguo entorno de producción?
Las implementaciones azul-verde de Amazon RDS no eliminan su antiguo entorno de producción. Si es necesario, puede acceder a él para validaciones adicionales y pruebas de rendimiento o regresión. Si ya no necesita el antiguo entorno de producción, puede eliminarlo. Los cargos de facturación estándar se aplican a las instancias de producción antiguas hasta que las elimine.
¿Qué comprueban las barreras de protección de conmutación de las implementaciones azul-verde de Amazon RDS?
Las barreras de protección de conmutación de las implementaciones azul-verde de Amazon RDS bloquean las escrituras en los entornos azul y verde hasta que el entorno verde se actualiza antes de la conmutación. Las implementaciones azul-verde también realizan comprobaciones de estado del entorno principal y las réplicas en los entornos azul y verde. Además, realizan comprobaciones del estado de la replicación, por ejemplo, para ver si la replicación se ha detenido o si hay errores. Detectan transacciones de ejecución prolongada entre los entornos azul y verde. Puede especificar un tiempo de inactividad máximo tolerable, a partir de 30 segundos, y si tiene una transacción en curso que lo excede, la conmutación se interrumpirá.
¿Puedo usar implementaciones azul-verde cuando tengo una base de datos azul como suscriptor/publicador para una réplica lógica autoadministrada?
Si su entorno azul es una réplica lógica autoadministrada o un suscriptor, bloquearemos la conmutación. Se recomienda detener primero la replicación en el entorno azul, continuar con la conmutación y, a continuación, reanudar la replicación. Por el contrario, si su entorno azul es el origen de una réplica lógica autoadministrada o un editor, puede continuar con la conmutación. Sin embargo, tendrá que actualizar la réplica autoadministrada para replicarla desde el entorno verde después de la conmutación.
¿Las implementaciones azul-verde de Amazon RDS son compatibles con bases de datos globales de Amazon Aurora, Amazon RDS Proxy o réplicas de lectura entre regiones?
No, las implementaciones azul-verde de Amazon RDS no admiten bases de datos globales de Amazon Aurora, Amazon RDS Proxy o réplicas de lectura entre regiones.
¿Puedo usar las implementaciones azul-verde de Amazon RDS para revertir los cambios?
No, en este momento no puede utilizar las implementaciones azul-verde de Amazon RDS para revertir los cambios.
Extensiones de lenguaje de confianza para PostgreSQL
¿Por qué debería usar extensiones de lenguaje de confianza para PostgreSQL?
Las extensiones de lenguaje de confianza (TLE) para PostgreSQL permiten a los desarrolladores crear extensiones de PostgreSQL de alto rendimiento y ejecutarlas de forma segura en Amazon Aurora. Al hacerlo, las TLE mejoran su tiempo de comercialización y eliminan la carga impuesta a los administradores de bases de datos para certificar el código personalizado y de terceros para su uso en cargas de trabajo de bases de datos de producción. Puede avanzar tan pronto como decida que una extensión satisface sus necesidades. Con las LTE, los proveedores de software independientes (ISV) pueden proporcionar a los clientes nuevas extensiones de PostgreSQL que se ejecutan en Aurora.
¿Cuáles son los riesgos tradicionales de ejecutar extensiones en PostgreSQL y cómo las TLE para PostgreSQL mitigan esos riesgos?
¿Cómo es la interacción de las TLE para PostgreSQL con los demás servicios de AWS?
Las TLE para PostgreSQL están disponibles para la edición compatible con PostgreSQL de Amazon Aurora en las versiones 14.5 y superiores. Las TLE se implementan como una extensión de PostgreSQL y puede activarlas desde el rol rds_superuser de forma similar a otras extensiones admitidas en Aurora.
¿En qué versiones de PostgreSQL puedo ejecutar TLE para PostgreSQL?
Puede ejecutar TLE para PostgreSQL en PostgreSQL 14.5 o superiores en Amazon Aurora.
¿En qué regiones están disponibles las extensiones de lenguaje de confianza para PostgreSQL?
Las TLE para PostgreSQL están disponibles actualmente en todas las regiones de AWS (excepto las regiones de China de AWS) y las regiones de AWS GovCloud.
¿Cuánto cuesta ejecutar TLE?
Las TLE para PostgreSQL están disponibles para los clientes de Aurora sin costo adicional.
¿En qué se diferencian las TLE para PostgreSQL de las extensiones disponibles en Amazon Aurora y Amazon RDS en la actualidad?
Aurora y Amazon RDS admiten un conjunto seleccionado de más de 85 extensiones de PostgreSQL. AWS administra los riesgos de seguridad para cada una de estas extensiones bajo el modelo de responsabilidad compartida de AWS. La extensión que implementa TLE para PostgreSQL se incluye en este conjunto. Las extensiones que escribe o que obtiene de fuentes de terceros e instala en TLE se consideran parte del código de su aplicación. Usted es responsable de la seguridad de sus aplicaciones que usan extensiones de TLE.
¿Cuáles son algunos ejemplos de extensiones que podría ejecutar con TLE para PostgreSQL?
Puede crear funciones de desarrollador, como compresión de mapa de bits y privacidad diferencial (como consultas estadísticas de acceso público que protegen la privacidad de las personas).
¿Qué lenguajes de programación puedo usar para desarrollar TLE para PostgreSQL?
Las TLE para PostgreSQL actualmente son compatibles con JavaScript, PL/pgSQL, Perl y SQL.
¿Cómo implemento una extensión de TLE para PostgreSQL?
Una vez que el rol rds_superuser activa TLE para PostgreSQL, puede implementar extensiones de TLE mediante el comando SQL CREATE EXTENSION desde cualquier cliente de PostgreSQL, como psql. Esto es similar a cómo crearía una función definida por el usuario escrita en un lenguaje de procedimiento, como PL/pgSQL o PL/Perl. Puede controlar qué usuarios tienen permiso para implementar extensiones de TLE y usar extensiones específicas.
¿Cómo se comunican las extensiones de TLE para PostgreSQL con la base de datos de PostgreSQL?
Las TLE para PostgreSQL acceden a su base de datos de PostgreSQL exclusivamente a través de la API de TLE. Los lenguajes de confianza admitidos por TLE incluyen todas las funciones de la interfaz de programación del servidor (SPI) de PostgreSQL y compatibilidad con enlaces de PostgreSQL, incluido el enlace de verificación de contraseña.
¿Dónde puedo obtener más información sobre el proyecto de código abierto TLE para PostgreSQL?
Puede obtener más información sobre el proyecto TLE para PostgreSQL en la página oficial de TLE en GitHub.
Soporte ampliado de Amazon RDS
¿Puedo utilizar Soporte ampliado de RDS con cualquier versión secundaria?
No, Soporte ampliado de Amazon RDS solo está disponible en determinadas versiones secundarias. Consulte la Guía del usuario de Aurora para obtener más información.
¿Cómo puedo calcular mis cargos de Soporte ampliado de RDS?
Los cargos de Soporte ampliado de Amazon RDS dependen de tres factores: 1. La cantidad de vCPU o ACU que se ejecutan en la instancia, 2. La región de AWS y 3. El número de años transcurridos desde la finalización del soporte estándar.
Para calcular los cargos, determine la cantidad de vCPU de la instancia y el precio anual correspondiente a la versión del motor. Si su versión está dentro del precio de los años 1 y 2 y utiliza instancias aprovisionadas, se le cobrará el precio del número de vCPU x año 1 y año 2 por hora de uso para la región que elija. Si su versión tiene el precio del tercer año y utiliza instancias aprovisionadas, se le cobrará el precio del número de vCPU x año 3 por hora de uso en la región que elija.
Por ejemplo, si ejecuta una instancia db.r5.large de la versión 2 compatible con MySQL de Aurora en la región Norte de Virginia el 30 de diciembre de 2024, es decir, dentro del primer año de Soporte ampliado de RDS, se le cobrarán 0,200 USD por hora o 2 vCPU x 0,100 USD por vCPU/hora.
¿Cuándo empieza Amazon Aurora a cobrar por Soporte ampliado de RDS?
Empezará a recibir los cargos por Soporte ampliado de Amazon RDS al día siguiente de la fecha de finalización del soporte estándar de la versión principal compatible con MySQL de Aurora. Esto se sumará a los cargos por instancia, almacenamiento, copia de seguridad y transferencia de datos incurridos durante la vida útil de la instancia.
Por ejemplo, el soporte para la versión 2 compatible con MySQL de Aurora finaliza el 30 de noviembre de 2024. Si ejecuta una instancia de la versión 2 compatible con MySQL de Aurora después del 30 de noviembre de 2024, se le cobrará Soporte ampliado de RDS en esa instancia.
¿Tengo que pagar por Soporte ampliado de RDS en mis instantáneas de base de datos?
No, los precios de Soporte ampliado de Amazon RDS no se aplican a las instantáneas de bases de datos. Sin embargo, cuando restaure una instantánea en una nueva instancia de base de datos que utilice una versión de Soporte ampliado de RDS, se cobrarán los precios de Soporte ampliado de RDS por esa instancia hasta que la actualice a una versión de soporte estándar o elimine la instancia.
¿Cuándo dejaré de recibir cargos por Soporte ampliado de RDS?
Si actualiza su instancia a una versión de motor más reciente que esté disponible en el soporte estándar, evitará que se le cobren los precios de Soporte ampliado de RDS por esa instancia. Los cargos de Soporte ampliado de RDS se detienen automáticamente al cerrar o eliminar una instancia que ejecuta una versión principal del motor después de la fecha de finalización del soporte estándar.
Hay dos precios diferentes para cada versión de motor. ¿Cómo puedo saber qué cargos se me están cobrando?
Los precios de Soporte ampliado de RDS que se le cobran dependen de la versión del motor, la región de AWS y el número de años naturales transcurridos desde que venció el soporte estándar para esa versión. Se le cobrarán los precios de los años 1 y 2 en la región elegida por vCPU/hora durante los dos primeros años tras la finalización del soporte estándar. Si se ofrece Soporte ampliado de RDS durante un tercer año, se le cobrará el precio del tercer año en la región elegida por vCPU/hora a partir del primer día del tercer año.
Por ejemplo, el soporte estándar de la edición 11 compatible con PostgreSQL de Aurora finaliza el 29 de febrero de 2024. Si la implementación se hace en la región Este de EE. UU. (Ohio), se le cobrarán 0,100 USD por vPCU/hora entre el 1 de abril de 2024 y el 31 de marzo de 2026. A partir del 1 de abril de 2026, se le cobrarán 0,200 USD por vCPU/hora.
¿Cómo puedo evitar que me cobre por Soporte ampliado de RDS?
Recomendamos actualizar la instancia lo antes posible a una versión principal del motor que se encuentre dentro de su plazo de soporte estándar. Esto ayudará a evitar incurrir en cargos de Soporte ampliado de RDS.
¿Puedo usar las implementaciones azul-verde de Amazon RDS para migrar de una versión de Soporte ampliado de RDS a una versión de soporte estándar?
Puede usar las implementaciones azul-verde de Amazon RDS para migrar sus instancias mediante el soporte ampliado de RDS, siempre que las implementaciones azul/verde sean compatible con el motor, la región y el tipo de versión principal de su instancia. Las implementaciones azul-verde están disponibles para la edición compatible con MySQL de Aurora. Para obtener información sobre las versiones disponibles, consulte la documentación de las implementaciones azul-verde.
¿Se aplican descuentos por instancias reservadas a Soporte ampliado de RDS?
No, los cargos de Soporte ampliado de RDS son independientes de los cargos en los que incurren las instancias. Por lo tanto, los descuentos por instancias reservadas no se aplican a los cargos de Soporte ampliado de RDS.
¿Se me cobrará por Soporte ampliado de RDS aunque pase de RDS para MySQL 5.7 a la versión 2 de Aurora para MySQL (basada en MySQL 5.7)?
Si migra de RDS para MySQL 5.7 a la versión 2 de Aurora para MySQL antes del 29 de febrero de 2024, no se le cobrará por Soporte ampliado de RDS. Si realiza la migración después del 29 de febrero de 2024 y antes del 30 de noviembre de 2024, se le cobrará Soporte ampliado de RDS por el número de horas que haya estado ejecutando MySQL 5.7 en Amazon RDS.
Si migra después del 30 de noviembre de 2024 o utiliza la versión 2 compatible con MySQL de Aurora después del 30 de noviembre de 2024, también se le cobrará Soporte ampliado de RDS en su base de datos de Aurora. Para obtener más información, consulte la documentación de Amazon Aurora y Amazon RDS.
¿Qué ocurre con las instantáneas de bases de datos que creé en una versión que ya no es compatible con el soporte estándar? ¿Tendré que pagar el precio de Soporte ampliado de RDS por ellas?
No, no se le cobrará el precio de Soporte ampliado de RDS en las instantáneas de bases de datos. Sin embargo, cuando restaure una instantánea de base de datos en una nueva instancia de base de datos tras la finalización del soporte estándar, se le cobrará el precio de Soporte ampliado de RDS por esa instancia.
Por ejemplo, si restaura una instantánea de base de datos en una nueva instancia de base de datos en la versión 2 compatible con MySQL de Aurora después del 30 de noviembre de 2024, la instancia se cobrará con el precio de Soporte ampliado de RDS de la versión 2 compatible con MySQL de Aurora hasta que la actualice a la versión 3 compatible con MySQL de Aurora o elimine la instancia.
Si creo una nueva instancia en un motor de una versión principal después de que finalice el soporte estándar, ¿se me cobrará por Soporte ampliado de RDS?
Sí, si crea una instancia o restaura una instantánea de base de datos en una instancia que se ejecuta en una versión cuyo soporte estándar ya haya vencido, se le cobrará el precio de Soporte ampliado de RDS, además de los cargos por instancia, almacenamiento, copia de seguridad y transferencia de datos.
Más información acerca de los precios de Amazon Aurora