Clústeres admitidos

Cualquier aplicación que utilice cualquier tipo de clúster MySQL tiene que enfrentarse con las mismas tareas:

• Identificar los nodos que pueden ejecutar una sentencia dada con el nivel de servicio requerido
• Equilibrar la carga de peticiones dentro de la lista de candidatos
• Usar la tolerancia a fallos automática dentro de los candidatos, si fuera necesario

El complemento está optimizado para realizar estas tareas en el contexto de un clúster de replicación MySQL asíncrono clásico que consiste en un único maestro y varios esclavos (copiar primaria). Al utilizar la replicación MySQL asíncrona clásica todas las tareas enumeradas arriba deben ser controladas en el lado del cliente.

Otros tipos de clústeres MySQL pueden cluster may have lower requirements on the application side. Po ejemplo, si todos los nodos del clúster pueden responder a peticiones de lectura y de escritura, no es necesario que se realice la división de lectura-escritura (multi-maestro, todos actualizan). Si todos los nodos del clúster son sincrónicos, proporcionarán autmáticamente la mayor calidad de servcio posible, lo que se hace eligiendo un nodo más sencillo. En este caso, el complemento puede servir a la aplicación después de una reconfiguración para deshabilitar ciertas características, como la división de lectura-escritura interna.

Nota: El enfoque de la documentación

El enfoque de la documentación describe el uso del complemento con los clústeres de replicación MySQL asíncronos clásicos (copia primaria). El soporte para este tipo de clústeres ha sido el objetivo de desarrollo original. El uso de otros clústeres se describe brevemente abajo. Por favor, observe que aún está en desarrollo.

Copia primaria (Replicación de MySQL)

Este es el caso de uso primario del complemento. Siga las indicaciones dadas en la descripción de cada característica.

• Configurar un maestro y uno o más esclavos. Los detalles de configuraicón del servidor se dan en la sección de configuración.
• Utilizar la política de equilibrado de carga aleatorio junto con la bandera sticky.
• Si no se planea usar las llamadas a la API de niveles de servicio, añada la bandera master on write.
• Por favor, concienciese de las propiedades de la tolerancia de fallos automática antes de añadir una directiva failover.
• Considere el uso de trx_stickiness para ejecutar transacciones solamente en el primario. Lea cuidadosamente cómo funciona antes de confiar en él.

mysqlnd_ms.enable=1
mysqlnd_ms.config_file=/path/to/mysqlnd_ms_plugin.ini

{
  "myapp": {
    "master": {
      "master_1": {
        "host": "localhost",
        "socket": "\/tmp\/mysql57.sock"
      }
    },
    "slave": {
      "slave_0": {
        "host": "127.0.0.1",
        "port": 3308
      },
      "slave_1": {
        "host": "192.168.2.28",
        "port": 3306
      }
    },
    "filters": {
      "random": {
        "sticky": "1"
      }
    }
  }
}

Copia primaria con multiprimarios (MMM - MySQL Multi Master)

La Replicación de MySQL permite crear topologías de clústeres con múltiples maestros (primarios). Los conflictos escritura-escritura no los maneja el sistema de replicación. No es una configuración de actualización en cualquier sitio. Por tanto, los datos deben ser particionados manualmente y los clientes deben ser redirigidos de acuerdo a las reglas de particionamiento. La configuración recomendada es igual a la de fragmentación de más abajo.

Fragmentación manual, posiblemente combinada con copia primaria y múltiples primarios

Use sugerencias SQL y el filtro de grupos de nodos para clústeres que usen particionamiento de datos pero que dejen la redirección de consultas al cliente. La configuración del ejemplo muestra una configuración multimaestro con dos fragmentos.

mysqlnd_ms.enable=1
mysqlnd_ms.config_file=/path/to/mysqlnd_ms_plugin.ini
mysqlnd_ms.multi_master=1

{
  "myapp": {
    "master": {
      "master_1": {
        "host": "localhost",
        "socket": "\/tmp\/mysql57.sock"
      }
      "master_2": {
        "host": "192.168.2.27",
        "socket": "3306"
      }
    },
    "slave": {
      "slave_1": {
        "host": "127.0.0.1",
        "port": 3308
      },
      "slave_2": {
        "host": "192.168.2.28",
        "port": 3306
      }
    },
    "filters": {
      "node_groups": {
        "Partition_A" : {
          "master": ["master_1"],
          "slave": ["slave_1"]
        },
        "Partition_B" : {
          "master": ["master_2"],
          "slave": ["slave_2"]
        }
      },
      "roundrobin": []
    }
  }
}

El complemento también se puede usar con una colección suelta de fragmentos no relacionados. Para tal clúster, configure solamente maestros y deshabilite la división de lectura-escritura. Los nodos de tal clúster son llamados maestros en la configuración del complemento ya que aceptan tanto lecturas como escrituras para su particionamiento.

Usar clústeres de actualización en cualquier sitio sincrónicos tales como el Clúster de MySQL

El Clúster de MySQL es una solución de clúster sincrónico. Todos los nodos del clúster aceptan peticiones de lectura y escritura. En el contexto del complemento, todos los nodos son considerados maestros.

Use únicamente el equilibrado de carga y la tolerancia a fallos.

• Deshabilite la división interna de lectura-esritura.
• Configure maestros solamente.
• Considere la estrategia del equilibrado de carga aleatorio una vez, que es la predeterminada del complemento. Si se usa esta estrategia, solamente se configuran los maestros y no se usan sugerencias SQL para forzar el uso de un nodo en particular, no ocurriran intercambios de conexiones durante una petición web. Por tanto, no se requiere un trato especial para las transacciones. El complemento eligirá un maestro al inicio del script de PHP y lo usará hasta que finalice dicho script.
• No establezca la calidad de servicio. Todos los nodos tienen todos los datos. Esto proporciona automáticamente la mejor calidad de servicio posible (consistencia fuerte).
• No habilite la inyección de transacciones global en el lado del cliente. Ni es necesario para ayudar con la tolerancia a fallos del lado del servidor ni para asistir al filtro de calidad de servicio a elegir un nodo apropiado.

Deshabilitar la división interna de lectura-escritura

• Establezca mysqlnd_ms.disable_rw_split=1
• No use sugerencias SQL para forzar el uso de esclavos

Configure únicamente maestros.

• Establezca mysqlnd_ms.multi_master=1.
• No configure ningún esclavo.
• Establezca failover=loop_before_master en el fichero de configuración del complemento para evitar advertencias sobre listas de esclavos vacías y para hacer que la lógica de tolerancia a fallos itere sobre todos los maestros configurados antes de emitir un error. Observe las advetencias sobre la tolerancia a fallos automática dadas en las secciones anteriores.

mysqlnd_ms.enable=1
mysqlnd_ms.config_file=/path/to/mysqlnd_ms_plugin.ini
mysqlnd_ms.multi_master=1
mysqlnd_ms.disable_rw_split=1

"myapp": {
    "master": {
      "master_1": {
        "host": "localhost",
        "socket": "\/tmp\/mysql57.sock"
      },
      "master_2": {
        "host": "192.168.2.28",
        "port": 3306
      }
    },
    "slave": {
    },
    "filters": {
      "roundrobin": {
      }
    },
    "failover": {
      "strategy": "loop_before_master",
      "remember_failed": true
    }
  }
}

Si se ejecuta un clúster de actualización en cualquier sitio que no tenga particionamiento interno para evitar hot spots y altas tasas de colisiones, considere usar el filtro de grupos de nodos para seguir las actualizaciones en una tabla de acceso frecuente en uno de los nodos. Esto podría ayudar a reducir las tasas de colisión y proporcionar así una mejora del rendimiento.