Información de referencia › Guía de referencia del catálogo de dispositivos › Catálogo del sistema › Dispositivos de base de datos › MYSQLR, MYSQLR64: dispositivo de base de datos MySQL apropiado para replicar › Propiedades

Propiedades

Importante:

• Desde MYSQLR64 1.6.8, la propiedad use_old_passwords se ha eliminado. Si necesita activar old_passwords, cree una configuración personalizada, tal y como se describe más abajo.
• El dispositivo MYSQLR dará error al iniciarse si error_log_filename se ha especificado y el terminal log no está conectado o el sistema de archivos no se puede montar.

Propiedades avanzadas (utilizadas en escenarios de replicación)

Configuración personalizada

Esta función está disponible en MYSQLR64 1.6.1 o versiones posteriores.

MYSQLR64 permite usar un archivo de configuración de MYSQL personalizado que puede proporcionar opciones de configuración adicionales o sobrescribir configuraciones existentes especificadas en /etc/my.cnf.

Para utilizar una configuración personalizada, cree un archivo denominado my.cnf y colóquelo en el directorio superior del volumen de datos. El formato del archivo deberá seguir la sintaxis de archivo de opciones MYSQL, tal y como se describe en la documentación de MYSQL.

Por ejemplo, se puede usar lo siguiente para ajustar MYSQLR64 de modo que proporcione un mejor rendimiento al utilizar InnoDB (la configuración de MYSQLR64 predeterminada se optimiza para MyISAM). El ejemplo se basa en el uso de 512 MB de memoria (valor predeterminado para MYSQLR64).

[mysqld]
# Shrink down MyISAM buffers
key_buffer = 512K
myisam_sort_buffer_size = 512K

# Make InnoDB the default storage engine (optional)
default-storage-engine = INNODB

# Set InnoDB buffer size
innodb_buffer_pool_size=350M
innodb_log_file_size=128M
innodb_log_buffer_size=4M
innodb_thread_concurrency=8

# If you do not have too many tables use this option, so you will not have uncontrolled innodb main tablespace growth which you can’t reclaim.
innodb_file_per_table=1

Importante: Cuando se use en modo de replicación, MYSQLR64 sincronizará también el archivo my.cnf en el volumen de datos cuando arregle o inicie la replicación, de modo que el secundario tendrá la misma configuración que el principal.

Interfaz Web

MYSQLR64 proporciona una interfaz Web a la cual se puede acceder tanto desde el terminal ui como desde la interfaz predeterminada mediante la opción Inicio de sesión (Web) del editor de CA AppLogic. El uso de la interfaz Web requiere autenticación HTTP. Deje en blanco el espacio de nombre del usuario y utilice el valor de web_pwd como contraseña. La interfaz tiene las funciones siguientes:

• view server status
  • start/stop/restart mysql service
  • mysql server status and uptime
  • mysql replication status (sólo para este dispositivo)
  • latest mysql log entries
  • appliance uptime
  • appliance memory usage
  • appliance disk usage
• view/manage replication
  • mysql replication status (sólo para este dispositivo)
  • initiate/fix replication. En este caso la base de datos en el dispositivo se limpia y la replicación se inicia desde cero en el principal. Esto no afecta a la base de datos en el principal (no se suprime ningún dato en el principal) y no genera tiempo de inactividad en el dispositivo MYSQLR64 principal. Durante la reparación, el dispositivo permanecerá desconectado y no se deberá utilizar.
  • delete snapshot: suprime una instantánea de base de datos creada en este dispositivo para iniciar/reparar la replicación en su secundario. En el funcionamiento normal todas las instantáneas se borran del dispositivo. Si ve el botón "delete snapshot", significa que hay un secundario que está inicializando la replicación en ese momento desde este dispositivo, o que ha fallado un intento anterior de iniciar la replicación. Ayuda garantizar que no haya ningún secundario que esté usando la instantánea antes de suprimirla. Esta opción no aparecerá visible si no hay ninguna instantánea en el dispositivo.
  • reset master log position: cuando agrega un servidor nuevo en una replicación principal-principal de varios nodos, después de iniciar o reparar una replicación en el dispositivo actual deberá iniciar sesión en la interfaz Web del dispositivo que se conecta a través de su terminal rout a este dispositivo y hacer clic en "reset master log position".
• Manage Database
  • Explore y edite sus bases de datos con PhPMyAdmin.

Cómo agregar replicaciones principal-secundario a dispositivos MYSQLR64

CA AppLogic le permite agregar replicaciones principal-secundario a dispositivos MYSQLR64 existentes sin perder datos.

Para agregar replicaciones principal-secundario a dispositivos MYSQLR64

1. Establezca rpl_mode en principal en el dispositivo existente.
2. Agregue un dispositivo MYSQLR64 nuevo a su aplicación con un volumen de datos vacío. Conecte el terminal rout al terminal rin del dispositivo actual.
3. (Opcional) Si lo va a utilizar en replicación principal-principal, conecte el terminal retirado del dispositivo actual al terminal rin del dispositivo nuevo.
4. Reinicie la aplicación.
5. Conéctese a la interfaz Web del dispositivo nuevo y seleccione iniciar o reparar la replicación en la ficha de gestión de la replicación. La duración del registro depende del tamaño de los datos en el principal. Si utiliza INSSLR para acceder a MYSQLR64, asegúrese de que la propiedad de tiempo de espera se establezca en un valor alto (36.000) para evitar tiempos de espera. Compruebe que no haya tiempos de espera en ninguno de los proxies del lado del cliente (es mejor no utilizar ningún proxy).
6. Cuando empiece la replicación, inicie sesión en la interfaz Web en los dos dispositivos MYSQLR64 y verifique el estado de la replicación. En 5 minutos o menos, la replicación debería estar ejecutándose en los dos dispositivos.

Cómo agregar dispositivos MYSQLR64 a replicaciones principal-secundario

CA AppLogic le permite agregar dispositivos MYSQLR64 nuevos a replicaciones principal-principal existentes sin perder datos.

Para agregar dispositivos MYSQLR64 a replicaciones principal-secundario

1. Agregue un dispositivo MYSQLR64 nuevo a su aplicación con un volumen de datos vacío. Por ejemplo, dbN, entendiendo que ya tiene N-1 dispositivos MYSQLR64 (3 <= N <= 10) y cada dispositivo tiene su terminal rout conectado al terminal rin del dispositivo siguiente en una configuración circular (rout de db1 se conecta a rin de db2, etc.).
2. Establezca rpl_mode en master_and_slave de dbN.
3. Conecte el terminal rout del dispositivo dbN-1 al terminal rin del dispositivo dbN.
4. Conecte el terminal rout del dispositivo dbN al terminal rin del dispositivo db1.
5. Reinicie la aplicación para que se apliquen los cambios. Después del reinicio, la replicación no quedará sincronizada hasta el final del procedimiento. Puede que los datos escritos en un dispositivo no se repliquen en el resto de dispositivos durante el procedimiento.
6. Conéctese a la interfaz Web del dispositivo dbN y seleccione iniciar o reparar la replicación en la ficha de gestión de la replicación. La duración del registro depende del tamaño de los datos en el principal. Si utiliza INSSLR para acceder a MYSQLR64, compruebe que la propiedad de tiempo de espera se establezca en un valor alto (36.000) para evitar tiempos de espera. Compruebe también que no haya tiempos de espera en ninguno de los proxies del lado del cliente (es mejor no utilizar ningún proxy).
7. Después de que se inicie replicación, conéctese a la interfaz Web de dbN-1 y seleccione restablecer la posición del registro del principal. Al incluir registros, la aplicación lee los registros binarios de dbN-1 y dbN desde el principio.
8. Conéctese a la interfaz Web de todos los dispositivos MYSQLR64 y verifique el estado de la replicación; en 5 minutos o menos la replicación debería estar ejecutándose en todos los dispositivos.

Reparación de replicación en configuraciones principal-secundario

CA AppLogic le permite reparar la replicación en una configuración principal-secundario sin perder datos.

Para reparar la replicación en configuraciones principal-secundario

1. Inicie sesión en la interfaz Web del secundario y seleccione iniciar o reparar la replicación. La duración del registro depende del tamaño de los datos en el principal. Durante la operación, el servicio mysql en el secundario se detiene. No se introduce el tiempo de inactividad en el principal. Esta operación es equivalente a agregar un dispositivo nuevo a un dispositivo MYSQLR64 existente. Si utiliza INSSLR para acceder a MYSQLR64, compruebe que la propiedad de tiempo de espera se establezca en un valor alto (36.000) para evitar tiempos de espera. También debe comprobar que no haya tiempos de espera en ninguno de los proxies del lado del cliente (es mejor no utilizar ningún proxy).
2. Después de que se inicie replicación, conéctese a la interfaz Web en los dispositivos MYSQLR64 secundarios y verifique el estado de replicación; en 5 minutos o menos, la replicación debería estar ejecutándose.

Reparación de replicación en configuraciones principal-principal

CA AppLogic le permite reparar la replicación en una configuración principal-principal sin perder datos.

Conéctese a la interfaz Web del dispositivo que informa de error en la replicación y seleccione iniciar o repara la replicación. La duración del registro depende del tamaño de la base de datos en el principal. Durante la operación, el servicio mysql en el dispositivo se detiene. No se introduce el tiempo de inactividad en el principal. La base de datos no quedará sincronizada entre todos los principales hasta el final de la reparación. Es posible que las actualizaciones de base de datos se repliquen en todos los dispositivos MYSQLR64 restantes mientras dure la reparación.

Todos los datos en este dispositivo se inicializan desde el principal. Si se hacen actualizaciones en la base de datos en el dispositivo actual desde el momento en que falló la replicación, se perderán. En este caso, resuelva los conflictos manualmente.

Para reparar la replicación en configuraciones principal-principal

1. Inicie sesión en la interfaz Web del dispositivo que tiene su terminal rout conectado al dispositivo que ejecuta la reparación de la replicación. Seleccione restablecer la posición del registro del principal. Establecer el registro del principal hace que la aplicación lea los registros binarios del dispositivo reparado desde el principio. Si utiliza INSSLR para acceder a MYSQLR64, compruebe que la propiedad de tiempo de espera se establezca en un valor alto (36.000) para evitar tiempos de espera. También debe comprobar que no haya tiempos de espera en ninguno de los proxies del lado del cliente (es mejor no utilizar ningún proxy).
2. Conéctese en a la interfaz Web de todos los dispositivos MYSQLR64 y revise el estado de la replicación. En 5 minutos o menos, la replicación debería estar ejecutándose en todos los dispositivos.

Control de la replicación

Hay una tarea de cron que controla la replicación entre dispositivos de MYSQLR64. Si está activada la replicación, la tarea de cron se ejecuta cada dos minutos y envía alertas al cuadro de mandos del grid en los casos siguientes:

• La replicación no se está ejecutando: aparece un mensaje en el cuadro de mandos del grid que indica que el servidor principal no se está ejecutando y que debe comprobarse la situación.
• La replicación se está ejecutando pero va muy detrás del principal: aparece un mensaje en el cuadro de mandos del grid que indica que la replicación va muy por detrás del principal y que debe comprobarse la situación.
• El espacio en el disco en el volumen data es bajo (menos de un 20 % libre). Esto se comprueba independientemente de si la replicación está activada o no (aparece un mensaje en el cuadro de mandos del grid que indica que el espacio libre en el volumen de datos es muy bajo y que debe comprobarse la situación).
• El espacio en el disco en el volumen binlogs es bajo (menos de un 20 % libre). Esto se comprueba independientemente de si la replicación está activada o no (aparece un mensaje en el cuadro de mandos del grid que indica que el espacio libre en el volumen binlogs es muy bajo y que debe comprobarse la situación).

En estos casos, el usuario deberá resolver el problema manualmente.

En caso de fallo en la replicación, se puede utilizar la interfaz Web para corregir la situación, tal y como se describe en la sección arriba.

Contadores personalizados

El dispositivo MYSQLR64 informa sobre los siguientes contadores personalizados a través del terminal "mon".

Los contadores siguientes pertenecen al grupo de contadores de MySql:

Mensajes de error

Los mensajes siguientes pueden aparecer en el archivo de registro del dispositivo o en el registro del sistema del controlador de grid cuando el dispositivo falla al iniciarse:

Además, pueden aparecer los errores siguientes en el cuadro de mandos del grid mientras el dispositivo se está ejecutando:

Aplicación de dos niveles simple (sin replicación)

El diagrama siguiente muestra un uso típico del dispositivo MYSQLR64 en una aplicación Web de dos niveles:

Dispositivos en uso:

• user: puerta de enlace de entrada.
• web: servidor Web.
• db: dispositivo de base de datos MYSQLR64.
• logs: dispositivo NAS para almacenamiento de archivos de registro.
• content: dispositivo NAS para almacenamiento de contenido de servidor Web.
• admin: puerta de enlace de entrada para ver archivos de registro.
• mon: dispositivo MON.

La solicitud del cliente llega a la puerta de enlace user. La puerta de enlace reenvía las solicitudes al servidor Web, el cual sirve la solicitud. Cuando los scripts (por ejemplo, Perl o PHP) en web tienen que acceder a datos persistentes, usan el dispositivo db a través del terminal de salida del servidor Web. El dispositivo db se configura para almacenar sus archivos de registro dentro del directorio raíz del recurso compartido mostrado por los registros.

Mediante un explorador, los administradores se conectan a la puerta de enlace admin para consultar los archivos de registro de mysql o del servidor Web. La puerta de enlace admin envía las solicitudes al dispositivo NAS de registros.

Configuración de una propiedad de ejemplo (las propiedades que no se especifican deberían dejarse con sus valores predeterminados):

Nota: El volumen de datos se deberá configurar también en el dispositivo db, así como los dispositivos logs, content y mon. Para crear volúmenes de aplicaciones que se puedan utilizar aquí, consulte la guía del usuario del grid.

Aplicación de dos niveles escalable (sin replicación)

El diagrama siguiente muestra un uso típico del dispositivo MYSQLR64 en una aplicación Web de dos niveles en la cual la base de datos se utiliza para compartir el estado y los datos entre varios servidores Web con equilibrio de carga. Además, este ejemplo tiene una entrada independiente para mantenimiento a través de la cual un administrador puede iniciar sesión y acceder a la base de datos para mantenimiento, así como una entrada a través de la cual un administrador puede iniciar sesión y ver el registro de errores de mysql.

Dispositivos en uso:

• user: puerta de enlace de entrada para solicitudes de usuario.
• web_lb: equilibrador de carga Web para solicitudes de usuario.
• web1, web2: servidores Web con contenido activo (por ejemplo, scripts de CGI).
• db: base de datos.
• logs: almacenamiento para archivos de registro de bases de datos y servidores Web y acceso a ellos.
• content: almacenamiento para el contenido de los servidores Web.
• maint: puerta de enlace de entrada para acceso de mantenimiento.
• admin: servidor Linux5 genérico utilizado por el administrador.
• gway: puerta de enlace de red para acceso del administrador a Internet.
• mon: dispositivo MON.

La solicitud del cliente llega a la puerta de enlace user. La puerta de enlace reenvía las solicitudes al equilibrador de carga web_lb, el cual las dirige a uno de los servidores Web: web1 o web2. Los servidores Web acceden a la base de datos db.

La base de datos db y los servidores web1 y web2 escriben sus archivos de registro en el dispositivo de registros a través de los terminales de registro. Además, un administrador se puede conectar a través de la puerta de enlace maint al dispositivo de registros y consultar los archivos de registro.

Adicionalmente, un administrador se puede conectar por SSH a través de la puerta de enlace maint al servidor de administración (deben configurarse las claves públicas y privadas). Desde el servidor admin, el administrador puede acceder a la base de datos db para obtener estadísticas o cambiar el esquema de la base de datos. El servidor admin puede acceder a Internet a través de la puerta de enlace gway para, por ejemplo, descargar una versión más reciente de bibliotecas o el esquema de la base de datos.

Configuración de una propiedad de ejemplo (las propiedades que no se especifican deberían dejarse con sus valores predeterminados):

Notas:

• El volumen de datos también se debe configurar en los dispositivos db, logs, content y mon.
• Los dispositivos maint, admin, gway, mon y log no son necesarios para el funcionamiento de la aplicación de dos niveles. Si existen, el servidor admin puede tener tareas de cron para limpiar la base de datos, enviar correo electrónico, etc.

Aplicación de N niveles con replicación principal-secundario (apropiada para copias de seguridad)

El diagrama siguiente muestra un uso típico del dispositivo MYSQL en una aplicación Web en la cual la base de datos se replica a un servidor secundario. El servidor secundario se puede usar para hacer copias de seguridad consistentes de los datos sin detener el servidor principal, introduciendo así un tiempo de inactividad cero para la aplicación.

Dispositivos en uso:

• user: puerta de enlace de entrada para solicitudes de usuario.
• admin: puerta de enlace de entrada para acceso a archivos de registro y acceso Web al dispositivo MYSQLR64.
• sw: dividir el tráfico HTTP entre los dispositivos MYSQLR64.
• web_lb: equilibrador de carga Web para solicitudes de usuario.
• web1, web2: servidores Web con contenido activo (por ejemplo, scripts de CGI).
• master: MYSQLR64 configurado como principal.
• slave: MYSQLR64 configurado como secundario.
• content: almacenamiento para el contenido de los servidores Web.
• logs: almacenamiento de archivos de registro de bases de datos y servidores Web.
• mon: dispositivo MON.

La solicitud del cliente llega a la puerta de enlace user. La puerta de enlace reenvía las solicitudes al equilibrador de carga web_lb, el cual las dirige a uno de los servidores Web: web1 o web2. Los servidores Web acceden a la base de datos principal.

El dispositivo secundario se conecta al dispositivo principal y replica sus datos. Los dispositivos secundarios se pueden detener en cualquier momento para hacer copias de seguridad consistentes de los datos de SQL o los análisis de gran volumen sin interferir en el rendimiento del dispositivo principal y el resto de la aplicación.

El acceso Web a los dispositivos principales y secundarios está disponible a través de la puerta de enlace admin en los puertos 8080 y 8081.

Los dispositivos principal, secundario, web1 y web2 se configuran para almacenar sus archivos de registro dentro del directorio raíz del recurso compartido que muestran los registros. Además, un administrador puede ver los archivos de registro a través de la puerta de enlace admin.

Configuración de una propiedad de ejemplo (las propiedades que no se especifican deberían dejarse con sus valores predeterminados):

master

slave

Notas:

• El volumen de datos se debe configurar en los dispositivos logs, content y mon.
• Los volúmenes de datos y de registros binarios se deberán configurar tanto en el principal como en el secundario. Deberán tener bastante espacio como para gestionar los datos y los registros.
• Cada dispositivo debe utilizar su propio volumen (no se puede compartir entre los dispositivos).
• Los dispositivos admin, mon y log no son necesarios para el funcionamiento de la replicación.