Cómo administrar varias instancias de una base de datos en AWS

Supongo que el pk de interés se genera a partir de una secuencia.

El paquete que está generando se crea actualmente en la base de datos de origen. El registro se replica, incluida la clave primaria. El problema es que la base de datos replicada NO puede generar sus propias claves primarias, porque las copias se superpondrán en los valores de las claves primarias (a menos que se asegure de que cada base de datos genere pks dentro de un cierto rango). El problema con este diseño es cuando una base de datos excede su rango; Se requerirá una gran cantidad de reorganización de datos para continuar el procesamiento. No suele recomendarse.

Si desea tener paquetes únicos en varias bases de datos, entonces otra alternativa es tener un único generador de paquetes que todos los db usen. Tenga en cuenta que este es un punto único de falla, también conocido como: no recomendado.

También puede tener bases de datos independientes y luego proporcionar un almacén de datos que consolide los datos de sus diferentes fuentes con fines informativos (un patrón popular).

Podría implementar una solución de múltiples nodos que particione los datos entre nodos. Los ejemplos incluirán Oracle RAC, Cassandra (nosql), vertical (Hewlett-Packard). Cada opción tiene diferentes características / costos / beneficios que tendrá que investigar para sus requisitos.

La replicación puede ser ‘fácil’, las bases de datos distribuidas NO.

Buena caza

Es posible que deba repensar las claves principales.

En lugar del estilo de incremento automático RDBMS estándar de la clave primaria que toma los valores 1, 2, 3, …, hay un par de opciones:

  • use un guid / uuid en su lugar, será único
  • fragmente las claves principales: si tiene N nodos de base de datos, entonces el primer nodo de base de datos usará las teclas 1, N + 1, 2N + 1, etc., el segundo nodo de base de datos usará las teclas 2, N + 2, 2N + 2, etc. Por supuesto, es posible que tenga que planificar la adición de nodos a medida que escala, por lo que si sabe que tendrá 3 nodos, quizás establezca N en 6 para que pueda duplicar su huella de base de datos sin necesidad de arreglar el fragmento PK.

Tenga en cuenta que RDS no está activo / activo (o activo / activo / activo con 3 nodos). Es activo / en espera donde el modo de espera es una réplica en una zona diferente. Si necesita absolutamente más de 2 nodos de base de datos activos, entonces RDS no es la solución y es posible que deba crear su propio clúster MySQL. Sin embargo, RDS activo / en espera puede ser suficiente dado que el modo en espera está en una zona diferente y AWS maneja la conmutación por error, las copias de seguridad, los parches, etc.