Se usó la API de Cloud Translation para traducir esta página.

Migra las claves primarias

En este documento, se ofrecen instrucciones para migrar las claves primarias desde las tablas de la base de datos de origen en Spanner. Debes conocer la información disponible en Descripción general de la migración de claves primarias.

Antes de comenzar

Para obtener los permisos que necesitas para migrar claves primarias a Spanner, pídele a tu administrador que te otorgue el rol de IAM de administrador de bases de datos de Cloud Spanner (roles/spanner.databaseAdmin) en la instancia.

Nota: Los roles básicos de IAM también pueden contener permisos para migrar claves primarias a Spanner. No deberías otorgar roles básicos en un entorno de producción, pero puedes otorgarlos en un entorno de desarrollo o de prueba.

Cómo migrar claves secuenciales generadas automáticamente

Si migras desde una base de datos que usa claves monótonas secuenciales, como AUTO_INCREMENT en MySQL, SERIAL en PostgreSQL o el tipo IDENTITY estándar en SQL Server o Oracle, ten en cuenta la siguiente estrategia de migración de alto nivel:

En Spanner, replica la estructura de la tabla de tu base de datos de origen con una clave primaria de número entero.
Para cada columna de Spanner que contenga valores secuenciales, crea una secuencia y asigna la función GET_NEXT_SEQUENCE_VALUE (GoogleSQL, PostgreSQL) como el valor predeterminado de la columna.
Migra los datos existentes con claves originales desde la fuente la base de datos en Spanner. Considera usar Herramienta de migración de Spanner o una plantilla de Dataflow
De manera opcional, puedes establecer restricciones de claves externas para cualquier tabla dependiente.
Antes de insertar datos nuevos, ajusta la configuración para omitir el rango de valores clave existentes.
Inserta datos nuevos, lo que permite que la secuencia genere claves únicas automáticamente.

Ejemplo de flujo de trabajo de migración

El siguiente código define la estructura de la tabla y la secuencia relacionada en Spanner con un SEQUENCE y establece el objeto como el valor principal predeterminado de la tabla de destino:

GoogleSQL

CREATE SEQUENCE singer_id_sequence OPTIONS (
     SequenceKind = 'bit_reversed_positive'
  );

CREATE TABLE Singers (
     SingerId INT64 DEFAULT
     (GET_NEXT_SEQUENCE_VALUE(SEQUENCE SingerIdSequence)),
     Name STRING(1024),
     Biography STRING(MAX),
  ) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
     AlbumId INT64,
     SingerId INT64,
     AlbumName STRING(1024),
     SongList STRING(MAX),
     CONSTRAINT FK_singer_album
     FOREIGN KEY (SingerId)
       REFERENCES Singers (SingerId)
  ) PRIMARY KEY (AlbumId);

PostgreSQL

CREATE SEQUENCE SingerIdSequence BIT_REVERSED_POSITIVE;

CREATE TABLE Singers (
  SingerId BIGINT DEFAULT nextval('SingerIdSequence') PRIMARY KEY,
  Name VARCHAR(1024) NOT NULL,
  Biography TEXT
);

CREATE TABLE Albums (
  AlbumId BIGINT PRIMARY KEY,
  SingerId BIGINT,
  AlbumName VARCHAR(1024),
  SongList TEXT,
  CONSTRAINT FK_singer_album FOREIGN KEY (SingerId) REFERENCES Singers (SingerId)
);

La opción bit_reversed_positive indica que los valores generados por el del tipo INT64, son mayores que cero y no son secuenciales.

A medida que migras las filas existentes de la base de datos de origen a Spanner, las claves primarias no se modifican.

En el caso de las inserciones nuevas que no especifican una clave primaria, Spanner recupera automáticamente un valor nuevo llamando a la función GET_NEXT_SEQUENCE_VALUE() (GoogleSQL o PostgreSQL).

Estos valores se distribuyen de manera uniforme en el rango [1, 2⁶³] y podría haber posibles colisiones con las claves existentes. Para evitar esto, puedes configura la secuencia con ALTER_SEQUENCE (GoogleSQL o PostgreSQL) para omitir el rango de de los valores cubiertos por las claves existentes.

Supongamos que la tabla singers se migró de PostgreSQL, donde se encuentra su clave primaria singer_id es del tipo SERIAL. En el siguiente PostgreSQL, se muestra el DDL de la base de datos de origen:

PostgreSQL

CREATE TABLE Singers (
SingerId SERIAL PRIMARY KEY,
Name varchar(1024),
Biography varchar
);

Los valores de la clave primaria aumentan de forma monótona. Después de la migración, puedes recuperar el valor máximo de la clave primaria singer_id en Spanner. Usa el siguiente código en Spanner:

GoogleSQL

SELECT MAX(SingerId) FROM Singers;

PostgreSQL

SELECT MAX(SingerId) FROM Singers;

Supongamos que el valor que se muestra es 20,000. Puedes configurar el bucket de Spanner para omitir el rango [1, 21000]. Los 1,000 adicionales sirven como para alojar escrituras en la base de datos de origen después de la migración inicial. Las nuevas claves generadas en Spanner no entran en conflicto con el rango de las claves primarias generadas en la base de datos PostgreSQL de origen. Usa el siguiente código en Spanner:

GoogleSQL

ALTER SEQUENCE SingerIdSequence SET OPTIONS (
skip_range_min = 1,
skip_range_max = 21000
);

PostgreSQL

ALTER SEQUENCE SingerIdSequence SKIP RANGE 1 21000;

Usa Spanner y la base de datos de origen

Puedes usar el concepto de rango de omisión para respaldar situaciones en las que Spanner o que la base de datos de origen genere claves primarias, por ejemplo, para habilitar la replicación en para la recuperación ante desastres durante una migración de sistemas.

Para admitir esto, ambas bases de datos generan claves primarias y los datos se sincronizan entre ellas. Puedes configurar cada base de datos para crear una claves en rangos de claves que no se superponen. Cuando defines un rango para la fuente base de datos, puedes configurar la secuencia de Spanner para omitirla del rango de destino de la ruta.

Por ejemplo, después de la migración de la aplicación de pistas de música, replica el datos de PostgreSQL a Spanner para reducir el tiempo cortar.

Cuando hayas actualizado y probado la aplicación en Spanner, podrás dejar de usar la base de datos PostgreSQL de origen y usar Spanner, lo que lo convierte en el sistema de registro de actualizaciones y claves primarias nuevas. Una vez que Spanner se haga cargo, podrás revertir el flujo de datos entre las bases de datos en la instancia de PostgreSQL.

Supongamos que tu base de datos de PostgreSQL de origen usa claves primarias SERIAL, que son números enteros firmados de 32 bits. Las claves primarias de Spanner son más grandes de 64 bits y números de serie. En PostgreSQL, cambia la columna de clave primaria para que sea una columna de 64 bits o bigint. Usa el siguiente código en tu base de datos de PostgreSQL de origen:

PostgreSQL

ALTER TABLE Singers ALTER COLUMN SingerId TYPE bigint;

Puedes establecer una restricción CHECK en la tabla de la base de datos PostgreSQL de origen para asegurarte de que los valores de la clave primaria SingerId siempre sean menores que 2³¹-1 o iguales a ella. Usa el siguiente código en tu base de datos de PostgreSQL de origen:

PostgreSQL

ALTER TABLE Singers ADD CHECK (SingerId <= 2147483647);

En Spanner, podemos alterar la secuencia para omitir el rango [1, 2³¹-1]. Usa el siguiente código en Spanner:

GoogleSQL

ALTER SEQUENCE SingerIdSequence SET OPTIONS (
skip_range_min = 1,
skip_range_max = 2147483647 -- 2³¹-1
);

PostgreSQL

ALTER SEQUENCE SingerIdSequence SKIP RANGE 1 2147483648;

Tu base de datos de PostgreSQL de origen siempre genera claves en el espacio de números enteros de 32 bits, mientras que las claves de Spanner se restringen al espacio de números enteros de 64 bits, que es más grande que todos los valores de números enteros de 32 bits. Esto garantiza que ambas bases de datos puedan generar claves primarias de forma independiente que no entren en conflicto.

Cómo migrar columnas de claves de UUID

Las claves UUIDv4 son únicas, independientemente de dónde se generen. Las claves UUID generadas en otro lugar se integran con las nuevas claves UUID generadas en Spanner

Considera la siguiente estrategia de alto nivel para migrar las claves de UUID a Spanner:

Define tus claves de UUID en Spanner con columnas de cadena con una expresión predeterminada. Usa la función GENERATE_UUID() (GoogleSQL, PostgreSQL).
Exporta los datos del sistema de origen y serializa las claves de UUID como cadenas.
Importa las claves primarias a Spanner.
Opcional: Habilita claves externas.

Este es un ejemplo de flujo de trabajo de migración:

En Spanner, define una columna de clave primaria de UUID como STRING o TEXT escribe y asigna GENERATE_UUID() (GoogleSQL o PostgreSQL) como su valor predeterminado. Migrar todos los de la base de datos de origen a Spanner. Después de la migración, como se insertan filas nuevas, Spanner llama a GENERATE_UUID() para generar nuevos valores de UUID para las claves primarias. Por ejemplo, la clave primaria FanClubId obtiene un valor UUIDv4 cuando se inserta una fila nueva en la tabla FanClubs. Usa el siguiente código en Spanner:

GoogleSQL

CREATE TABLE Fanclubs (
FanClubId STRING(36) DEFAULT (GENERATE_UUID()),
ClubName STRING(1024),
) PRIMARY KEY (FanClubId);

INSERT INTO FanClubs (ClubName) VALUES ("SwiftFanClub");

PostgreSQL

CREATE TABLE FanClubs (
  FanClubId TEXT DEFAULT spanner.generate_uuid() PRIMARY KEY,
  ClubName VARCHAR(1024)
);

INSERT INTO FanClubs (ClubName) VALUES ('SwiftFanClub');

Cómo migrar tus propias claves primarias

Tu aplicación puede depender del orden de la clave primaria para determinar qué tan recientes son los datos o para secuenciar los datos creados recientemente. Para usar claves secuenciales generadas de forma externa en Spanner, puedes crear una clave compuesta que combine un valor distribuido de forma uniforme, como un hash, como primer componente y tu clave secuencial como segundo componente. De esta manera, puedes conservar los pares clave-valor secuenciales sin crear hotspots a gran escala. Considera el siguiente flujo de trabajo de migración:

Supongamos que necesitas migrar una tabla students de MySQL con una clave primaria AUTO_INCREMENT a Spanner. Usa el siguiente código en tu base de datos de MySQL de origen:

MySQL

CREATE TABLE Students (
StudentId INT NOT NULL AUTO_INCREMENT,
Info VARCHAR(2048),
PRIMARY KEY (StudentId)
);

En Spanner, puedes agregar una columna generada StudentIdHash si creas un hash de la columna StudentId. Por ejemplo:

  StudentIdHash = FARM_FINGERPRINT(CAST(StudentId AS STRING))

Puedes usar el siguiente código en Spanner:

GoogleSQL

CREATE TABLE student (
  StudentIdHash INT64 AS (FARM_FINGERPRINT(cast(StudentId as string))) STORED,
  StudentId INT64 NOT NULL,
  Info STRING(2048),
) PRIMARY KEY(StudentIdHash, StudentId);

PostgreSQL

CREATE TABLE Student (
  StudentIdHash bigint GENERATED ALWAYS AS
  (FARM_FINGERPRINT(cast(StudentId AS varchar))) STORED,
  StudentId bigint NOT NULL,
  Info varchar(2048),
  PRIMARY KEY (StudentIdHash, StudentId)
);

¿Qué sigue?

Descripción general de la migración de la clave primaria