La función PolarDB for MySQL Multi-master Cluster (Limitless) actualiza un clúster de una arquitectura de escritura única y lectura múltiple a una arquitectura de escritura múltiple y lectura múltiple. Esta función permite escrituras simultáneas de datos en diferentes bases de datos u objetos de datos en distintos nodos de cómputo. También admite la programación dinámica de bases de datos y objetos de datos entre nodos con cambios que se completan en segundos, lo cual mejora significativamente la capacidad general de lectura y escritura simultánea del clúster. Los objetos de datos incluyen tablas, vistas, triggers, eventos, procedimientos almacenados y funciones. Este tema describe cómo utilizar un Multi-master Cluster (Limitless).
Requisitos previos
Ha adquirido un clúster Multi-master Cluster (Limitless). Para obtener más información, consulte Custom Purchase y Purchase a subscription cluster.
Ha creado una cuenta con privilegios. Para obtener más información, consulte Create a privileged account.
Se ha conectado al clúster de base de datos. Para obtener más información, consulte Connect to a database cluster.
La versión 8.0 o posterior del kernel de PolarDB for MySQL es compatible con Multi-master Cluster (Limitless).
Limitaciones
Los datos de cada base de datos u objeto de datos solo pueden escribirse a través de un único nodo principal. Los nodos que no tienen asignada una base de datos o un objeto de datos no pueden realizar operaciones de lectura ni escritura. De forma predeterminada, las operaciones se realizan a nivel de base de datos. Para realizar operaciones a nivel de objeto de datos, debe usar una sintaxis específica para cambiar el modo.
No se admiten consultas entre nodos principales. Si una consulta involucra bases de datos u objetos de datos que residen en diferentes nodos principales, el sistema reporta un error. Se recomienda mover los endpoints de todas las bases de datos u objetos de datos involucrados a un solo nodo principal antes de ejecutar la consulta.
Solo se proporcionan endpoints de clúster, pero no se admiten endpoints principales.
-
El cambio de un endpoint está sujeto a las siguientes condiciones:
Si utiliza el nivel de aislamiento de base de datos, debe cambiar el endpoint de la base de datos.
Si utiliza el nivel de aislamiento de objeto de datos, debe cambiar el endpoint del objeto de datos.
-
No se admiten operaciones DDL entre nodos principales. Si ejecuta una sentencia DDL en una base de datos u objeto de datos mientras la conexión actual se encuentra en un nodo principal que no es el propietario de dicha base de datos u objeto, el sistema reporta el error
Failed to get global lock for table 'xxx' on master N. Para resolver este problema, realice los siguientes pasos:-
Ejecute el siguiente comando para consultar el nodo principal que posee la tabla destino:
SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Busque el
master_idcorrespondiente a la tabla destino en el resultado de la consulta. -
Ejecute el siguiente comando para cambiar la sesión actual al nodo principal que posee la tabla destino:
ALTER SESSION POLARDB_WRITE_NODE <master_id>;Reemplace
<master_id>con el número real del nodo principal obtenido en el paso anterior. Una vez completado el cambio, vuelva a ejecutar la sentencia DDL.
-
Especificar un nodo principal para una base de datos
Cree una base de datos en un nodo principal específico. La sintaxis es la siguiente:
CREATE DATABASE name [POLARDB_WRITE_NODE master_id];Al usar el nivel de aislamiento de base de datos, los datos de cada base de datos solo pueden escribirse a través de un único nodo principal.
Si omite
[POLARDB_WRITE_NODE master_id]en la sintaxis, el sistema usa el valor del parámetro loose_innodb_mm_default_master_id para especificar el nodo principal donde se creará la base de datos. Cuando el valor del parámetro loose_innodb_mm_default_master_id es 0, el sistema selecciona aleatoriamente un nodo principal para crear la base de datos. Puede ir a la consola de PolarDB y navegar a la página para view and modify cluster or node parameters.Para ver la distribución de las bases de datos entre los nodos, consulte Query the database distribution.
Ejemplo: Cree una base de datos llamada db1 en el nodo principal 1.
CREATE DATABASE db1 POLARDB_WRITE_NODE 1;Para crear la base de datos db1 en el nodo principal 2, cambie 1 por 2 en la sentencia anterior.
Eliminar una base de datos
Para eliminar una base de datos creada en un nodo principal específico, use la siguiente sintaxis:
DROP DATABASE name;Ejemplo: Elimine la base de datos db1 que se creó en el nodo principal 1.
DROP DATABASE db1;No es necesario especificar el nodo principal al eliminar una base de datos.
Cambiar el endpoint de una base de datos
Para cambiar el endpoint de la base de datos a otro nodo principal, use la siguiente sintaxis:
ALTER DATABASE name POLARDB_WRITE_NODE master_id;Ejemplo: Cambie el endpoint de la base de datos db1 al nodo principal 2.
ALTER DATABASE db1 POLARDB_WRITE_NODE 2;Cambiar un endpoint puede ser una operación que consuma tiempo. El tiempo de ejecución depende de los siguientes factores:
Cuantas más tablas contenga la base de datos, más lento será el cambio.
Cuanto mayor sea la carga de trabajo DML en la base de datos durante el cambio, más lenta será la operación.
Cambiar al aislamiento de objeto de datos
De forma predeterminada, el nivel de aislamiento para un clúster multi-principal es el nivel de base de datos. Esto significa que todos los objetos de datos dentro de la misma base de datos solo pueden accederse en un único nodo principal. Si desea que todos los objetos de datos de la misma base de datos sean accesibles a través de múltiples nodos principales, debe cambiar el nivel de aislamiento de base de datos al nivel de aislamiento de objeto de datos. La sintaxis es la siguiente:
ALTER DATABASE name TO TABLE_LOCK POLARDB_WRITE_NODE master_id;En esta sentencia, name especifica el nombre de la base de datos y master_id especifica el endpoint del objeto de datos.
Ejemplo: Cambie el nivel de aislamiento de la base de datos db1 al nivel de aislamiento de objeto de datos y establezca su endpoint en el nodo principal 2.
ALTER DATABASE db1 TO TABLE_LOCK POLARDB_WRITE_NODE 2;Cambiar el nivel de aislamiento puede ser una operación que consuma tiempo. El tiempo de ejecución depende de los siguientes factores:
Cuantos más objetos contenga la base de datos, más lento será el cambio.
Cuanto mayor sea la carga de trabajo DML en la base de datos durante el cambio, más lenta será la operación.
Cambiar al aislamiento de base de datos
Si una base de datos está configurada con el nivel de aislamiento de objeto de datos, puede revertirla al nivel de aislamiento de base de datos para facilitar su gestión. Use la siguiente sentencia:
ALTER DATABASE name TO DB_LOCK POLARDB_WRITE_NODE master_id;En esta sentencia, name especifica el nombre de la base de datos y master_id especifica el endpoint de la base de datos.
Ejemplo: Cambie el nivel de aislamiento de la base de datos db1 de nuevo al nivel de aislamiento de base de datos y establezca su endpoint en el nodo principal 1.
ALTER DATABASE db1 TO DB_LOCK POLARDB_WRITE_NODE 1;Cambiar el nivel de aislamiento puede ser una operación que consuma tiempo. El tiempo de ejecución depende de los siguientes factores:
Cuantos más objetos contenga la base de datos, más lento será el cambio.
Cuanto mayor sea la carga de trabajo DML en la base de datos durante el cambio, más lenta será la operación.
Cambiar el endpoint de un objeto de datos
Cuando un clúster se encuentra en el nivel de aislamiento de objeto de datos, una base de datos puede contener diversos tipos de objetos, como tablas, vistas, triggers, funciones, procedimientos almacenados y eventos. Para cambiar el endpoint de estos objetos, use la siguiente sintaxis:
ALTER obj_type name POLARDB_WRITE_NODE master_id;En esta sentencia, obj_type puede ser TABLE, VIEW, TRIGGER, FUNCTION, PROCEDURE o EVENT. name es el nombre del objeto de datos.
Ejemplo 1: Cambie el endpoint de la tabla t1 en la base de datos db1 al nodo principal 3.
ALTER TABLE db1.t1 POLARDB_WRITE_NODE 3;Ejemplo 2: Cambie el endpoint de la vista t2 en la base de datos actual al nodo principal 2.
ALTER VIEW t2 POLARDB_WRITE_NODE 2;Ejemplo 3: Cambie el endpoint de las funciones f1 y f2 en la base de datos db2 al nodo principal 1.
ALTER FUNCTION db2.f1, db2.f2 POLARDB_WRITE_NODE 1;Cambiar un endpoint puede ser una operación que consuma tiempo. El tiempo de ejecución depende de los siguientes factores:
Cuanto mayor sea la carga de trabajo DML en el objeto de datos durante el cambio, más lenta será la operación.
-
Los objetos con dependencias pueden volverse inválidos si no se encuentran en el mismo nodo principal.
Por ejemplo, una vista llamada
VIEW1depende de una tabla llamadat1. Si el endpoint deVIEW1está en el nodo principal 1 y el endpoint det1está en el nodo principal 2, se produce un error al consultarVIEW1en el nodo principal 1. Del mismo modo, las llamadas a una función, procedimiento almacenado o evento fallan si los objetos a los que hacen referencia están en diferentes nodos principales. Un trigger también falla al modificar una tabla si sus endpoints están en nodos diferentes. Si existe una restricción de clave externa entre dos tablas, como
t1yt2, al modificar el endpoint de una tabla se modifica automáticamente el endpoint de la otra.
Especificar un nodo principal para SQL
Esta función solo aplica a consultas de metadatos, como consultas en information_schema o variables de estado. Si necesita consultar datos, por ejemplo, ejecutando SELECT * FROM table1, no necesita especificar un nodo principal, ya que el proxy de base de datos enruta automáticamente la consulta al nodo principal correcto.
Para enviar una sentencia SQL a un nodo principal específico, ejecute la siguiente sentencia SQL para bloquear la sesión en ese nodo:
ALTER SESSION POLARDB_WRITE_NODE master_id;Ejemplo: Consulte el valor de la variable innodb_buffer_pool_size en el nodo principal 1.
ALTER SESSION POLARDB_WRITE_NODE 1; # Send the SQL statement to primary node 1.
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; # Query the value of innodb_buffer_pool_size on primary node 1.Si no especifica un nodo principal al ejecutar una sentencia SQL, el proxy de base de datos selecciona aleatoriamente un nodo principal para ejecutar la sentencia.
Ejecute el siguiente comando para desbloquear la sesión del nodo principal especificado:
RESET SESSION POLARDB_WRITE_NODE;Consultar la distribución de bases de datos
En la consola de PolarDB, vaya a la página para ver la distribución de todas las bases de datos en el clúster. La columna MasterID muestra el número de nodo RW al que pertenece cada base de datos (por ejemplo, MasterID 1 indica que la base de datos está en el nodo RW1, y MasterID 2 indica que está en el nodo RW2).
-
Ejecute los siguientes comandos para consultar la distribución de bases de datos en un nodo principal específico:
ALTER SESSION POLARDB_WRITE_NODE master_id; SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Ejemplo: Consulte la distribución de bases de datos en el nodo principal 1.
ALTER SESSION POLARDB_WRITE_NODE 1; SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Se devuelve el siguiente resultado:
SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X'; +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ | table_name | table_id | space_id | s_lock_count | lock_mode | object | current_lsn | hold_thread | hold_start_time | hold_total_time | +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ | test3/f1 | 9149389368458135753 | 0 | 0 | SLS_X | function | 28076635 | 17 | 2024-07-10 21:35:20 | 214 | | test3/e1 | 9149389368458332874 | 0 | 0 | SLS_X | event | 28077248 | 17 | 2024-07-10 21:35:30 | 204 | | test3/v1 | 9149389368457234649 | 0 | 0 | SLS_X | view | 28075972 | 17 | 2024-07-10 21:35:08 | 226 | | sbtest | 2107518311328629409 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-07 23:04:41 | 254053 | | test | 7190879906290573778 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-10 11:20:57 | 37077 | | test2 | 3381728963524265351 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-10 11:13:09 | 37545 | +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ 6 rows in set (0.00 sec)Aunque la columna se llama
table_name, cada fila del resultado contiene información sobre una base de datos o un objeto de datos. En este ejemplo,sbtest,testytest2usan el nivel de aislamiento de base de datos. Los objetostest3/f1,test3/e1ytest3/v1usan el nivel de aislamiento de objeto de datos. El resultado también puede contener un objeto llamado mysql/global_ddl_lock con un tipo de objeto de tabla. Esto es para uso interno y puede ignorarse. -
Ejecute el siguiente comando para consultar la distribución de todas las bases de datos en el clúster:
NotaEsta consulta solo puede ejecutarse mediante una cuenta con privilegios.
SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Se devuelve el siguiente resultado:
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X'; +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ | master_id | table_name | table_id | lock_mode | object | current_lsn | hold_start_time | hold_total_time | +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ | 1 | test3/v1 | 9149389368457234649 | SLS_X | view | 28075972 | 2024-07-10 21:35:08 | 754 | | 2 | test5/t1 | 9149389447232697561 | SLS_X | table | 7256175 | 2024-07-10 21:46:36 | 66 | | 1 | test2 | 3381728963524265351 | SLS_X | db | 28034927 | 2024-07-10 11:13:09 | 38073 | | 2 | test4 | 3381728963524272009 | SLS_X | db | 7255352 | 2024-07-10 21:46:27 | 75 | | 1 | test3/f1 | 9149389368458135753 | SLS_X | function | 28076635 | 2024-07-10 21:35:20 | 742 | | 1 | test3/e1 | 9149389368458332874 | SLS_X | event | 28077248 | 2024-07-10 21:35:30 | 732 | | 1 | test | 7190879906290573778 | SLS_X | db | 28034927 | 2024-07-10 11:20:57 | 37605 | | 2 | test5/p1 | 9149389447233473757 | SLS_X | procedure | 7257051 | 2024-07-10 21:46:45 | 57 | | 1 | sbtest | 2107518311328629409 | SLS_X | db | 28034927 | 2024-07-07 23:04:41 | 254581 | +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ 9 rows in set (0.00 sec)Aunque la columna se llama
table_name, cada fila del resultado contiene información sobre una base de datos u objeto de datos y su nodo principal correspondiente. El resultado también puede contener un objeto llamado mysql/global_ddl_lock con un tipo de objeto de tabla. Esto es para uso interno y puede ignorarse.
Configurar el registro binario
Multi-master Cluster (Limitless) es totalmente compatible con el registro binario de MySQL. Consolida los registros de operaciones de todos los nodos principales del clúster para generar un registro binario lógico y globalmente unificado.
Puede usar loose_polar_log_bin para habilitar la función de registro binario para un Multi-master Cluster (Limitless) y binlog_expire_logs_seconds para establecer el período de retención de los registros binarios del Multi-master Cluster (Limitless). Para obtener más información, consulte Enable binary logs.
Multi-master Cluster (Limitless) puede usarse como origen y destino para Data Transmission Service (DTS) con el fin de realizar sincronización de datos unidireccional o bidireccional.