MySQL 8.0 ha estado disponible por un tiempo y Percona XtraDB Cluster 8.0 también ha estado disponible por algún tiempo también. Además, MySQL 5.6 está llegando al final de su vida útil y las personas que usan PXC 5.6 también querrán migrar a una versión más reciente pronto. Echemos un vistazo al proceso y compartamos algunos consejos al respecto.
Recuerde, debajo está MySQL...
Para empezar, debe tener en cuenta que Galera es solo un complemento que funciona con MySQL, por lo que debe asegurarse de cumplir con las reglas y procesos de migración para su versión particular de MySQL que se usa en su PXC. Si estamos ejecutando PXC 5.7 y desea actualizar a PXC 8.0, primero debe marcar todas las casillas en la lista de verificación de actualización de MySQL. Cubrimos algo de eso en nuestro blog que describe el proceso de actualización entre MySQL 5.7 y MySQL 8.0. También significa que solo son viables las rutas de actualización admitidas por MySQL; por ejemplo, no puede actualizar PXC 5.6 directamente a PXC 8.0, ya que no se admite la actualización directa de MySQL de 5.6 a 8.0.
Lea la documentación de actualización
Como de costumbre, cada vez que planifique una actualización, debe familiarizarse con la documentación preparada por el proveedor. Percona tiene una página web dedicada a explicar el proceso de actualización y las advertencias al respecto. Repasaremos algunos de esos puntos en esta publicación de blog.
Cambios de configuración
Hay un par de cambios en los ajustes de configuración predeterminados que pueden desencadenar problemas en el proceso de actualización:pxc_strict_mode está configurado en CUMPLIMIENTO de forma predeterminada. Este modo bloquea cualquier tipo de configuración que sea experimental y pueda afectar la estabilidad del clúster. Los controles cubren, entre otras cosas, los motores de almacenamiento usados, el formato de registro binario, la existencia de claves primarias y algunas otras cosas. Al actualizar, es posible que desee configurarlo en PERMISO para rastrear las incompatibilidades en el registro de errores, pero de lo contrario, deje que PXC se ejecute incluso si algunas cosas no están en la mejor forma.
Otra configuración, pxc_encrypt_cluster_traffic, también está habilitada de manera predeterminada, lo que impone el cifrado de la comunicación de Galera entre nodos. No es posible mezclar nodos con nodos cifrados y no cifrados en el mismo clúster, por lo tanto, debe configurarlo en todos los nodos o asegurarse de deshabilitar pxc_encrypt_cluster_traffic en los nuevos nodos PXC 8.0.
Cambio en el complemento de autenticación predeterminado
Mencionamos esto en nuestra publicación de blog sobre la migración a MySQL 8.0, pero el cambio es tan importante que queremos reiterarlo aquí también:con MySQL 8.0, el complemento de autenticación predeterminado cambia a caching_sha2_password; esto puede hacer que algunas de las aplicaciones más antiguas sean incompatibles con MySQL 8.0. Por supuesto, puede cambiar esta configuración, pero si no la tiene en cuenta, puede ser contraproducente después de que se complete la actualización.
Procesos de actualización
Para empezar, tenga en cuenta que, aunque no se recomienda, con algunos es posible tener nodos PXC 5.7 y PXC 8.0 ejecutándose en el mismo clúster. Esto abre una oportunidad para hacer una actualización en vivo en el lugar. El proceso sería bastante simple:detenga el nodo PXC 5.7, actualícelo a PXC 8.0 instalando una nueva versión e iniciándolo. En el directorio de datos de proceso, se actualizará a la nueva versión y el nuevo nodo PXC 8.0 debería poder iniciarse correctamente y unirse al clúster. Luego continúa con los nodos uno por uno, migrando de PXC 5.7 a PXC 8.0. Tenga en cuenta que debe evitar SST ya que un directorio de datos del nodo PXC 8.0 no se puede usar en 5.7. Al revés debería funcionar bien. Para evitar que suceda SST, asegúrese de que el tamaño de gcache sea lo suficientemente grande para acomodar escrituras y permitir que suceda IST. IST en sí funcionará bien.
Si tiene más nodos libres, siempre puede realizar la actualización con dos clústeres en diferentes versiones principales ejecutándose en paralelo y conectados a través de la replicación asincrónica. Lo que es importante, este enfoque le permitirá probar el PXC 8.0 más a fondo, ya que lo tendrá en funcionamiento durante un tiempo (básicamente durante el tiempo que lo necesite) y podrá probar su aplicación en este clúster, en cualquier momento. tiempo, puede mover parte de la carga de trabajo de solo lectura al PXC 8.0 para ver cómo se manejan las consultas, si hay errores o problemas de rendimiento.
Si usa ClusterControl, esto se puede lograr mediante el trabajo "Crear clúster esclavo".
Se le pedirá que decida de dónde deben provenir los datos iniciales, maestro nodo PXC o desde la copia de seguridad.
También deberá pasar los detalles de conectividad como el usuario SSH y la ruta clave .
Luego se le pedirá que elija el proveedor y la versión; probablemente desee para usar PXC 5.7 por ahora, actualizará los nodos más tarde, probando el proceso de actualización en sí.
Finalmente, debe pasar los nombres de host del nodo o las direcciones IP para ClusterControl a conéctese y comience a configurar los nodos.
Como resultado, tendrá un segundo Percona XtraDB Cluster ejecutándose en la versión 5.7 , replicando desde el clúster original. Ese clúster se puede actualizar a la nueva versión y, eventualmente, puede cambiar su tráfico hacia él. Hemos explicado este proceso en detalle en nuestra publicación de blog anterior.
Esperamos que esta breve publicación de blog lo ayude a prepararse mejor para actualizar su Percona XtraDB Cluster a la versión 8.0.
