Migración a Aurora Serverless v2

Para convertir un clúster de base de datos existente para utilizar Aurora Serverless v2, puede hacer lo siguiente:

Cuando el clúster actualizado ejecuta la versión del motor adecuada, tal como se indica en Requisitos y limitaciones para Aurora Serverless v2, puede empezar a añadirle instancias de base de datos de Aurora Serverless v2. La primera instancia de base de datos que se agrega al clúster actualizado debe ser una instancia de base de datos aprovisionada. A continuación, puede cambiar el procesamiento de la carga de trabajo de escritura, la carga de trabajo de lectura o ambos a las instancias de base de datos de Aurora Serverless v2.

Actualización o cambio de clústeres existentes para utilizar Aurora Serverless v2

Si el clúster aprovisionado tiene una versión de motor que admite Aurora Serverless v2, cambiar a Aurora Serverless v2 no requiere actualización. En ese caso, puede añadir instancias de base de datos de Aurora Serverless v2 al clúster original. Puede cambiar el clúster para utilizar todas las instancias de base de datos de Aurora Serverless v2. También puede utilizar una combinación de instancias de base de datos de Aurora Serverless v2 aprovisionadas en el mismo clúster de base de datos. Para las versiones del motor Aurora compatibles con Aurora Serverless v2, consulte Regiones y motores de base de datos Aurora admitidos para Aurora Serverless v2.

Si está ejecutando una versión del motor anterior que no admite Aurora Serverless v2, siga estos pasos generales:

La actualización de Aurora Serverless v1 en Aurora Serverless v2 implica crear un clúster aprovisionado como paso intermedio. A continuación, debe realizar los mismos pasos de actualización que cuando comienza con un clúster aprovisionado.

Rutas de actualización para clústeres compatibles con MySQL para usar Aurora Serverless v2

Si el clúster original ejecuta Aurora MySQL, elija el procedimiento adecuado según la versión del motor y el modo de motor de su clúster.

Rutas de actualización para clústeres compatibles con PostgreSQL para usar Aurora Serverless v2

Si el clúster original ejecuta Aurora PostgreSQL, elija el procedimiento adecuado según la versión del motor y el modo de motor del clúster.

Cambiar de un clúster aprovisionado a Aurora Serverless v2

Para cambiar un clúster aprovisionado para que utilice Aurora Serverless v2, siga estos pasos:

Los siguientes ejemplos de la AWS CLI muestran el proceso de conmutación utilizando un clúster aprovisionado que ejecuta Aurora MySQL versión 3.02.0. El clúster se denomina mysql-80. El clúster comienza con dos instancias de base de datos aprovisionadas llamadas provisioned-instance-1 y provisioned-instance-2, escritor y lector. Ambos usan la clase instancia de base de datos de db.r6g.large.

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' --output text
mysql-80
provisioned-instance-2     False
provisioned-instance-1     True

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-1 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-1     db.r6g.large

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-2 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-2     db.r6g.large

Creamos una tabla con algunos datos. De esta forma podemos confirmar que los datos y el funcionamiento del clúster son los mismos antes y después de la conmutación.

mysql> create database serverless_v2_demo;
mysql> create table serverless_v2_demo.demo (s varchar(128));
mysql> insert into serverless_v2_demo.demo values ('This cluster started with a provisioned writer.');
Query OK, 1 row affected (0.02 sec)

En primer lugar, añadimos un rango de capacidad al clúster. De no hacerlo, se producirá un error al añadir cualquier instancia de base de datos de Aurora Serverless v2 al clúster. Si usamos la AWS Management Console para este procedimiento, ese paso es automático cuando añadimos la primera instancia de base de datos de Aurora Serverless v2.

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql

An error occurred (InvalidDBClusterStateFault) when calling the CreateDBInstance operation:
Set the Serverless v2 scaling configuration on the parent DB cluster before creating a Serverless v2 DB instance.

$ # The blank ServerlessV2ScalingConfiguration attribute confirms that the cluster doesn't have a capacity range set yet.
$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 --query 'DBClusters[*].ServerlessV2ScalingConfiguration'
[]

$ aws rds modify-db-cluster --db-cluster-identifier mysql-80 \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16
{
  "DBClusterIdentifier": "mysql-80",
  "ServerlessV2ScalingConfiguration": {
    "MinCapacity": 0.5,
    "MaxCapacity": 16
  }
}

Creamos dos lectores de Aurora Serverless v2 que sustituyen a las instancias de base de datos originales. Para ello, especificamos la clase de instancia de base de datos db.serverless para las nuevas instancias de base de datos.

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-2 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-2",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ # Wait for both DB instances to finish being created before proceeding.
$ aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1 && \
  aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-2

Realizamos una conmutación por error para que una de las instancias de base de datos de Aurora Serverless v2 sea el nuevo escritor del clúster.

$ aws rds failover-db-cluster --db-cluster-identifier mysql-80 \
  --target-db-instance-identifier serverless-v2-instance-1
{
  "DBClusterIdentifier": "mysql-80",
  "DBClusterMembers": [
    {
      "DBInstanceIdentifier": "serverless-v2-instance-1",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "serverless-v2-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-1",
      "IsClusterWriter": true,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    }
  ],
  "Status": "available"
}

Se necesitan unos segundos para que ese cambio surta efecto. En ese momento, tenemos un escritor de Aurora Serverless v2 y lector de Aurora Serverless v2. Por lo tanto, no necesitamos ninguna de las instancias de base de datos aprovisionadas originales.

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
  --output text
mysql-80
serverless-v2-instance-1        True
serverless-v2-instance-2        False
provisioned-instance-2          False
provisioned-instance-1          False

El último paso del procedimiento de conmutación es eliminar ambas instancias de base de datos aprovisionadas.

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-2 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-2",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-1 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-1",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}

Como comprobación final, confirmamos que la tabla original es accesible y se puede escribir desde la instancia de base de datos de escritor de Aurora Serverless v2.

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
+---------------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into serverless_v2_demo.demo values ('And it finished with a Serverless v2 writer.');
Query OK, 1 row affected (0.01 sec)

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)

También nos conectamos a la instancia de base de datos de lector de Aurora Serverless v2 y confirmamos que los datos recién escritos también están disponibles ahí.

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)

Comparación de Aurora Serverless v2 y Aurora Serverless v1

Si ya está utilizando Aurora Serverless v1, puede conocer las principales diferencias entre Aurora Serverless v1 y Aurora Serverless v2. Las diferencias de arquitectura, como la compatibilidad con instancias de base de datos de lector, abren nuevos tipos de casos de uso.

Puede utilizar las siguientes tablas para comprender las diferencias más importantes que existen entre Aurora Serverless v2 y Aurora Serverless v1.

Comparación de los requisitos de Aurora Serverless v2 y Aurora Serverless v1

En la siguiente tabla se resumen los diferentes requisitos para ejecutar la base de datos utilizando Aurora Serverless v2 o Aurora Serverless v1. Aurora Serverless v2 ofrece versiones posteriores de los motores de base de datos Aurora MySQL y Aurora PostgreSQL que Aurora Serverless v1.

Comparación del escalado y la disponibilidad de Aurora Serverless v2 y Aurora Serverless v1

En la siguiente tabla se indican las diferencias de escalabilidad y disponibilidad de Aurora Serverless v2 y Aurora Serverless v1.

El escalado de Aurora Serverless v2 es más receptivo, más granular y menos disruptivo que el escalado de Aurora Serverless v1. Aurora Serverless v2 se puede escalar cambiando el tamaño de la instancia de base de datos y añadiendo más instancias de base de datos al clúster de base de datos. También se puede escalar añadiendo clústeres de otras Regiones de AWS a una base de datos global de Aurora. En cambio, Aurora Serverless v1 solo se escala aumentando o disminuyendo la capacidad del escritor. Todo la computación de un clúster de Aurora Serverless v1 se ejecuta en una única zona de disponibilidad y en una única Región de AWS.

Comparación de la compatibilidad de características de Aurora Serverless v2 y Aurora Serverless v1

Se resumen en la tabla siguiente:

Aurora Serverless v2 incluye muchas características de clústeres aprovisionados que no están disponibles en Aurora Serverless v1.

Adaptación casos de uso de Aurora Serverless v1 para Aurora Serverless v2

En función de su caso de uso para Aurora Serverless v1, podrá adaptar ese enfoque para aprovechar las características de Aurora Serverless v2 de la siguiente manera.

Supongamos que tiene un clúster de Aurora Serverless v1 que está ligeramente cargado y su prioridad es mantener la disponibilidad continua y minimizar los costes. Con Aurora Serverless v2, puede configurar una valor de ACU mínimo menor de 0,5, en comparación con un mínimo de 1 ACU para Aurora Serverless v1. Puede aumentar la disponibilidad creando una configuración Multi-AZ, ya que la instancia de base de datos del lector también tiene un mínimo de 0,5 ACU.

Supongamos que tiene un clúster de Aurora Serverless v1 que utiliza en un escenario de desarrollo y prueba. En este caso, el costo también es de alta prioridad, pero el clúster no necesita estar disponible en todo momento. En la actualidad, Aurora Serverless v2 no se detiene automáticamente cuando el clúster está completamente inactivo. En su lugar, puede detener manualmente el clúster cuando no sea necesario e iniciarlo cuando llegue el momento del próximo ciclo de prueba o desarrollo.

Supongamos que tiene un clúster de Aurora Serverless v1 con una carga de trabajo pesada. Se puede escalar un clúster equivalente mediante Aurora Serverless v2 con más granularidad. Por ejemplo, Aurora Serverless v1 escala duplicando la capacidad, por ejemplo, de 64 a 128 AUC. Por el contrario, la instancia de base de datos de Aurora Serverless v2 puede reducirse horizontalmente en incrementos de 0,5 ACU.

Supongamos que su carga de trabajo requiere una capacidad total superior a la disponible en Aurora Serverless v1. Puedes usar varias instancias de base de datos de lector de Aurora Serverless v2 para descargar las partes de lectura intensiva de la carga de trabajo de la instancia de base de datos de escritor. También puede dividir la carga de trabajo de lectura intensiva entre varias instancias de base de datos de lector.

Para una carga de trabajo de escritura intensiva, puede configurar el clúster con una instancia de base de datos aprovisionada de gran tamaño como escritor. Puede hacerlo junto con una o más instancias de base de datos de lector de Aurora Serverless v2.

Actualización de un clúster de Aurora Serverless v1 a Aurora Serverless v2

El proceso de actualización de un clúster de base de datos de Aurora Serverless v1 a Aurora Serverless v2 tiene varios pasos. Esto se debe a que no se puede convertir directamente de Aurora Serverless v1 a Aurora Serverless v2. Siempre hay un paso intermedio que implica convertir el clúster de base de datos de Aurora Serverless v1 en un clúster aprovisionado.

Clústeres de base de datos compatibles con Aurora MySQL

Puede convertir su clúster de base de datos de Aurora Serverless v1 en un clúster de base de datos aprovisionado y, a continuación, utilizar una implementación azul/verde para actualizarlo y convertirlo en un clúster de base de datos de Aurora Serverless v2. Recomendamos este procedimiento para los entornos de producción. Para obtener más información, consulte Uso de las implementaciones azul/verde de Amazon RDS para actualizar las bases de datos.

Clústeres de base de datos compatibles con Aurora PostgreSQL

Puede convertir su clúster de base de datos de Aurora Serverless v1 en un clúster de base de datos aprovisionado y, a continuación, utilizar una implementación azul/verde para actualizarlo y convertirlo en un clúster de base de datos de Aurora Serverless v2. Recomendamos este procedimiento para los entornos de producción. Para obtener más información, consulte Uso de las implementaciones azul/verde de Amazon RDS para actualizar las bases de datos.

También puede actualizar el clúster de base de datos de Aurora Serverless v1 directamente desde la versión 11 de Aurora PostgreSQL a la versión 13, convertirlo en un clúster de base de datos aprovisionado y, a continuación, convertir el clúster aprovisionado en un clúster de base de datos de Aurora Serverless v2.

Para los clústeres de base de datos de Aurora Serverless v1 que ejecuten Aurora PostgreSQL versión 13, debe convertir el clúster de Aurora Serverless v1 en un clúster de base de datos aprovisionado y, a continuación, convertir el clúster aprovisionado en un clúster de base de datos de Aurora Serverless v2.

Migración de una base de datos en las instalaciones a Aurora Serverless v2

Puede migrar sus bases de datos en las instalaciones a Aurora Serverless v2, de igual modo que con Aurora MySQL y Aurora PostgreSQL.