Catálogo del sistema › Dispositivos de base de datos › MYSQLR, MYSQLR64: dispositivo de base de datos MySQL apropiado para replicar

MYSQLR, MYSQLR64: dispositivo de base de datos MySQL apropiado para replicar

Descripción general del funcionamiento

MYSQLR64 es un dispositivo de base de datos basado en el motor de base de datos MySQL (http://www.mysql.org). Proporciona una forma fácil de agregar una base de datos a cualquier aplicación. Los dispositivos se pueden usar también en escenarios de replicación de MYSQL complejos. Los dispositivos están basados en MYSQL5 (CentOS 5.5/MySQL 5) pero también tratan la replicación de base de datos.

La replicación de base de datos permite que los datos de un servidor de base de datos de MySQL (conocido como principal) se repliquen a uno o varios servidores de base de datos MySQL (conocidos como secundarios). Los dispositivos MYSQLR64 se pueden configurar para la replicación principal-secundario así como para la replicación principal-principal y la replicación con más de dos principales.

La configuración, gestión y control de replicación se realizan mediante una interfaz Web. La interfaz Web proporciona una forma fácil de iniciar la replicación prácticamente sin tiempo de inactividad en el principal. Se puede utilizar también para reparar una replicación en caso de problemas. La interfaz Web se puede utilizar para copiar bases de datos de dispositivos de base de datos más antiguos como MYSQL y MYSQL5. MYSQLR64 también proporcionar una forma fácil para gestionar y explorar la base de datos (basada en phpMyAdmin).

La replicación resulta útil en varios casos:

• Soluciones de escalabilidad horizontal: extiende la carga entre varios nodos para mejorar el rendimiento (configuración "principal-principal").
• Soluciones de conmutación por error: se usan varios nodos en la replicación principal-principal para que cada dispositivo se pueda usar sólo para servir la aplicación en caso de que se produzca un error en los otros. (MYSQLR64 no se encarga automáticamente de los errores, si se produce un error en un servidor MYSQL, la aplicación lo debería detectar y dejar de utilizarlo ).
• Soluciones de copia de seguridad: dos o más nodos; uno de ellos se ejecuta como principal y el resto como secundarios. La aplicación utiliza únicamente el principal. Los secundarios se utilizan para hacer copias de seguridad (en este caso la base de datos se puede detener para ser coherente con la copia de seguridad) o simplemente para hacer densos análisis de los datos (informes, resúmenes o todo lo que no cambie los datos) sin cargar el principal, con lo que no se influye en el rendimiento de la aplicación. (MYSQLR64 no hace automáticamente una copia de seguridad la base de datos; tiene que gestionar la copia de seguridad usted mismo ).

En su configuración predeterminada MYSQLR64 actúa exactamente como un dispositivo MYSQL5 con una interfaz Web para la gestión. Para utilizarlo en escenarios de replicación, necesita al menos dos dispositivos MYSQLR64 con una configuración apropiada (consulte Uso Típico).

MYSQLR64 almacena la base de datos en un volumen definido por la aplicación que se puede configurar en cada instancia de MYSQLR64. MYSQLR64 crea automáticamente una base de datos vacía cuando se inicia en un volumen vacío.

Importante: No debería mezclar dispositivos MYSQLR de 32 bits y 64 bits cuando utiliza la replicación para copiar los archivos de base de datos del principal al secundario. Tampoco deberían utilizar volúmenes de datos de la versión de 32 bits del dispositivo con una versión de 64 bits del mismo dispositivo (y viceversa). Para migrar una base de datos entre las versiones de 32 bits y 64 bits de MYSQLR, vuelque las bases de datos en un host e impórtelas al otro, tal y como se describe aquí.

Límite

Recursos

Terminales

La interfaz predeterminada está activada. Se utiliza para diagnósticos y solución de problemas (mediante SSH). Las versiones futuras de este dispositivo pueden desactivar el acceso de SSH.
Importante: Los terminales rin y rout se usan para datos tanto SSH (tcp 22) como MYSQL (tcp 3306). Cuando se usan puertas de enlace o VPN para conectar esos terminales, los cortafuegos se deberán configurar para permitir usar los dos puertos.

Volúmenes de usuario

Opcionalmente, el volumen de datos puede contener un archivo my.cnf en su directorio superior que incluye opciones de configuración de MYSQL. Para obtener más detalles, consulte la sección Configuración personalizada. Esta función está disponible en MYSQLR64 1.6.1 o versiones posteriores.

Importante:

• El volumen de datos debe estar exclusivamente dedicado a la instancia de MYSQL (no puede compartirse con otros dispositivos).
• El volumen de datos no deberá recibir formato de ningún sistema de archivos, ya que se utilizará para crear un volumen LVM. Si utiliza un volumen con formato de sistema de archivos (posiblemente con archivos de un dispositivo MYSQL antiguo), el dispositivo dará error al iniciarse y le impedirá suprimir las bases de datos y los archivos.

Para migrar una base de datos desde un dispositivo antiguo (MYSQL, MYSQL5, MYSQL64), desde un servidor físico o desde MYSQLR (si se migra una versión de 32 bits del dispositivo a una de 64), consulte el procedimiento descrito en Migración de bases de datos desde otros dispositivos.

Propiedades

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

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 3Tera 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
• Migrate Content (visible sólo cuando hay volumen old_data)
  • Migrate Content copia el contenido del volumen old_data al volumen data. Esto se utiliza para facilitar la actualización del dispositivo MYSQL y MYSQL5. Se limpiarán todos los datos en el volumen de datos.
• 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.

Configuración y mantenimiento de la replicación

Cómo agregar replicaciones principal-secundario a dispositivos MYSQLR64

CA 3Tera 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).

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 3Tera 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.

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 3Tera 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).

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 3Tera 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).

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.

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:

Uso típico

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):

principal

secundario

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.

Aplicación de N niveles con replicación principal-principal (apropiada para equilibrio de carga)

El diagrama siguiente muestra un uso típico del dispositivo MYSQLR64 en una aplicación Web en la cual la base de datos se replica a dos servidores en un escenario de replicación de principal-principal. En este caso, la aplicación usa servidores tanto WEB como MYSQLR64 durante la operación de equilibrio de carga. También, en el caso de que una de las instancias WEB/MYSQLR64 falle, la otra instancia WEB/MYSQLR64 se puede utilizar para evitar tiempo de inactividad en 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 los archivos de registro.
• 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).
• db1 y db2: los dispositivos MYSQLR64 se configuran para ser principales y secundarios al mismo tiempo.
• 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. web1 usa el dispositivo de base de datos db1 y web2 usa el dispositivo de base de datos db2. db1 y db2 se conectan para replicar las actualizaciones que los servidores Web hagan a la base de datos. Cada dispositivo MYSQLR64 utiliza un desplazamiento (igual a su server_id) para las columnas auto_increment, de manera que no se produzca duplicación de entradas.

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

Los dispositivos db1, db2, web1 y web2 se configuran para almacenar sus archivos de registro dentro del directorio raíz del recurso 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):

db1

db2

Notas:

• El volumen de datos se debe configurar en los dispositivos logs, content y mon.
• Los volúmenes de datos y registros binarios se deberán configurar tanto en db1 como en db2. Cada dispositivo debe utilizar su propio volumen (no se puede compartir entre los dispositivos).
• Al hacer una replicación principal-principal, es necesario empezar con volúmenes de datos vacíos.

Los dispositivos admin, mon y log no son necesarios para el funcionamiento de la replicación.

Aplicación de N niveles con replicación principal-principal de varios nodos (apropiada para equilibrio de carga)

El diagrama siguiente muestra un uso típico del dispositivo MYSQLR64 en una aplicación Web en la cual la base de datos se replica a cuatro servidores en un escenario de replicación principal-principal. En este caso, la aplicación usa todos los servidores WEB y MYSQLR64 durante la operación de equilibrio de carga. También, en el caso de que una de las instancias WEB/MYSQLR64 falle, las otras instancias WEB/MYSQLR64 se pueden utilizar para evitar tiempo de inactividad en la aplicación (MYSQLR64 no gestiona errores).

Dispositivos en uso:

• user: puerta de enlace de entrada para solicitudes de usuario.
• admin: puerta de enlace de entrada para acceso a los archivos de registro.
• sw: dividir el tráfico HTTP entre los dispositivos MYSQLR64.
• web_lb: equilibrador de carga Web para solicitudes de usuario.
• web1, web2, web3 y web4: servidores Web con contenido activo (por ejemplo, scripts de CGI).
• db1, db2, db3 y db4: los dispositivos MYSQLR64 se configuran para ser principales y secundarios al mismo tiempo.
• content: almacenamiento para archivos de registro de errores de base de datos, contenido Web y registros 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 envía las solicitudes al equilibrador de carga web_lb, el cual dirige la solicitud a uno de los servidores Web web1, web2, web3 y web4 . Cada servidor Web usa su propio dispositivo de base de datos. Todos los dispositivos de base de datos se conectan en círculo para replicar las actualizaciones que los servidores Web hacen en la base de datos. Así pues, una actualización en db1, por ejemplo, se replicará a db2, db3 y db4. Cada dispositivo MYSQLR64 utiliza un desplazamiento (igual a su server_id) para las columnas auto_increment, de manera que no se produzca duplicación de entradas.

El acceso Web a db1, db2, db3 y db4 está disponible a través de la puerta de enlace admin en los puertos 8080, 8081, 8082 y 8083.

Los dispositivos db1, db2, web1 y web2 se configuran para almacenar sus archivos de registro dentro del directorio raíz del recurso 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):

db1

db2

db3

db4

Notas:

• El volumen de datos se debe configurar en los dispositivos logs, content y mon.
• El volumen de datos y de registros binarios se deberá configurar también en todos los dispositivos db. Cada dispositivo debe utilizar su propio volumen (no se puede compartir entre los dispositivos).
• Al hacer una replicación entre varios principales, es necesario empezar con volúmenes de datos vacíos.

Los dispositivos admin, mon y log no son necesarios para el funcionamiento de la replicación.

Aplicación de N niveles que se ejecuta en diferentes instalaciones (apropiada para equilibrio de carga y conmutación por error)

El diagrama siguiente muestra un uso típico del dispositivo MYSQLR64 en una aplicación Web que se ejecuta en más de una instalación. Con esta configuración podrá ejecutar dos o más aplicaciones idénticas en instalaciones diferentes replicando la base de datos a todas las aplicaciones en la configuración principal-principal. Esto es útil en dos casos:

• Equilibrio de carga geográfico: configuración de dos (o más) aplicaciones para que los usuarios puedan utilizar la aplicación que esté más próxima a su región geográfica para generar mejores tiempos de respuesta (el equilibrio de carga se hace con DNS).
• Conmutación por error: configuración de dos (o más) aplicaciones por si falla toda la instalación donde se está ejecutando una aplicación (o falla la aplicación en sí), las otras aplicaciones se puedan utilizar para evitar tiempos de inactividad.

Aplicación principal

Aplicación secundaria

Dispositivos en uso:

• user: puerta de enlace de entrada para solicitudes de usuario.
• admin: puerta de enlace de entrada para acceso a los archivos de registro.
• sw: redirigir el puerto 8080 desde admin a ui en principal o secundario.
• vpn: entrada para que la aplicación remota se conecte al dispositivo principal o secundario para replicar la base de datos.
• 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 archivos de registro de errores de base de datos, contenido Web y registros Web.
• logs: almacenamiento para archivos de registro de errores de base de datos.

La solicitud del cliente llega a la puerta de enlace de usuario. 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 principal se conecta a la aplicación remota (secundaria) para replicar la base de datos (siendo la única diferencia la propiedad server_id de secundario y la configuración de la red). La aplicación remota se conecta al dispositivo principal a través de la puerta de enlace vpn configurada para permitir establecer conexión solamente desde la puerta de enlace vpn de la aplicación remota. Los dispositivos principal y secundario en las dos aplicaciones se ejecutan en la configuración principal-principal, de modo que siempre tienen datos idénticos.

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

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

Principal

VPN principal

slave

VPN secundario

La aplicación remota es una copia exacta, la única diferencia es la configuración de red de los dispositivos user, admin y vpn, las conexiones entre el dispositivo vpn y el principal=/=secundario, y el server_id del dispositivo principal=/=secundario (debería ser único).

Migración de bases de datos desde otros dispositivos

Si necesita migrar de MYSQLR a MYSQLR64 (y viceversa), no debería utilizar los volúmenes del dispositivo de 32 bits en uno 64 bits (o viceversa), ya que se podrían dañar los datos. Para hacer esto se recomienda volcar la base de datos en el dispositivo antiguo, transferir el archivo volcado al dispositivo nuevo y, a continuación, importar la base de datos en el dispositivo nuevo. A continuación se indica el procedimiento para hacer esto:

• (Opcional) Evite el acceso a la base de datos antigua. Esto es opcional y solamente es para garantizar que la base de datos no se modifique mientras se está volcando. Para ello, puede iniciar el dispositivo sin que haya nada conectado en los terminales de entrada.
• Vuelque todas las bases de datos en el dispositivo antiguo. Compruebe que tiene bastante espacio en el volumen de datos antes de hacer esto (siempre puede cambiar el tamaño del volumen de datos si no hay bastante espacio). Para hacer esto, inicie el dispositivo, inicie sesión en él y ejecute el comando siguiente:
  • mysqldump --all-databases --lock-all-tables | gzip > /mnt/data/my_dump.sql.gz
• Detenga la aplicación.
• Cree el nuevo volumen de aplicación que va a almacenar la base de datos para el dispositivo nuevo (ext3-snapshot). Verifique que el volumen es lo bastante grande como para contener el archivo de volcado de base de datos (/mnt/data/my_dump.sql.gz) y la base de datos.
• Transfiera el archivo de volcado de base de datos al nuevo volumen creado (a continuación se indica una forma de copiar la base de datos con 2 configuraciones de archivadores con acceso a internet externo; si esto no es apropiado para su configuración, la base de datos también se puede copiar mediante scp desde el grid a un servidor externo y, a continuación, de vuelta al volumen de destino):
  • Gestione cada volumen de forma separada usando dos archivadores (uno para cada volumen) mediante el comando vol manage. Asegúrese de transmitir la información de IP externa a la línea de comandos de vol manage, para que cada archivador pueda acceder al otro para copiar la base de datos entre los dos volúmenes. Para obtener más información sobre cómo especificar los valores de configuración de la red externa, consulte la ayuda de vol manage.
  • En el archivador del volumen fuente, ejecute lo siguiente: cat /etc/ssh/ssh_host_rsa_key.pub >> /root/.ssh/authorized_keys
  • En el archivador del volumen de destino, ejecute lo siguiente: scp -pr -i /etc/ssh/ssh_host_rsa_key IP_address_to_source_filer:/mnt/vol/my_dump.sql.gz /mnt/vol/.
  • Cuando la base de datos se copie, puede salir de los dos archivadores.
• Edite la aplicación y agregue una nueva instancia de MYSQLR/MYSQLR64, parametrícela, conéctela y asigne el nuevo volumen creado a la nueva instancia. En este punto la instancia de MYSQLR/MYSQLR64 antigua se puede suprimir de la aplicación (sin embargo, puede guardarla como copia de seguridad hasta que pueda verificar que la base de datos se ha transferido correctamente a la nueva instancia).
• Importe la base de datos. Inicie el dispositivo nuevo, inicie sesión en él y ejecute el comando siguiente:
  • zcat /mnt/data/my_dump.sql.gz | mysql

La base de datos ya se ha transferido y el dispositivo está preparado para uso.

Notas

Tenga en cuenta lo siguiente:

• El rendimiento de MYSQLR64 se optimiza para el motor de almacenamiento MyISAM que se usa de forma predeterminada. Si se desea mejorar el rendimiento para Innodb o simplemente ajustar el servicio de MYSQL para su aplicación, consulte la sección Configuración personalizada para obtener más información sobre cómo agregar parámetros de configuración a la configuración existente. Esta función está disponible en MYSQLR64 1.6.1 o versiones posteriores.
• MYSQLR64 utiliza solamente replicación asincrónica (MySQL no es compatible con la replicación sincrónica).
• MYSQLR64 detecta los errores de replicación a los 2 minutos siguientes y los notifica al usuario mediante la publicación de un mensaje en el cuadro de mandos del grid. El usuario puede utilizar a continuación la GUI de MYSQLR64 para corregir la incidencia (MYSQLR64 no proporciona recuperación automatizada).
• Cuando se inicia MYSQLR64, se escribe un mensaje en el archivo de registro del dispositivo que afirma que chmod no pudo modificar el propietario del archivo de registro de mysql. Esto es esperable y no afecta al funcionamiento del dispositivo MYSQLR64.
• El número máximo teórico de dispositivos de MYSQLR64 en una sola replicación es 10. Como los datos se replican de forma circular, si se incrementa el número de dispositivos MYSQLR64 aumentará el tiempo que tardan los secundarios en actualizar sus bases de datos. El máximo real de dispositivos de una replicación puede ser más bajo en función de la aplicación, la carga y las necesidades (la actualización instantánea de secundarios puede no ser esencial en algunos escenarios, como de copia de seguridad de datos).

Importante: Al crear usuarios para la base de datos, compruebe que todos los usuarios se crean sin restricciones en el host desde el que se conectan. Por ejemplo:

mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%'
    ->     IDENTIFIED BY 'some_pass' WITH GRANT OPTION;

• Requisitos de volumen
  • El tamaño del volumen de datos debería ser 100 MB o más. Actualmente, el motor InnoDB se activa y ocupa unos 22 MB en el volumen de datos. En esta versión, no hay ninguna forma de deshabilitar esto, incluso aunque no utilice InnoDB para el almacenamiento de datos.
  • No se debería aplicar formato al volumen de datos con ningún sistema de archivos, ya que se utilizará para construir un volumen LVM (el volumen debería estar sin formato). Si utiliza un volumen que al que se le ha aplicado formato con cualquier sistema de archivos (seguramente con archivos de un dispositivo MYSQL anterior), se producirá un error al iniciar el dispositivo que le impedirá eliminar sus archivos.
  • Se adjudica el 20 % del espacio del volumen de datos para iniciar/corregir la replicación, lo que deja el 80 % del espacio de volumen para el almacenamiento de la base de datos.
  • Al utilizar MYSQLR64 en escenarios de replicación, ya sea como principal, secundario o master_and_slave, debe proporcionar un volumen de registros binarios. Los registros binarios se rotan 100 MB y se conservan durante 2 días después de la rotación. Después de este tiempo, se eliminan. Si el dispositivo se está ejecutando también como secundario, se almacenan también registros de relé en el volumen de registros binarios. Necesitará por lo menos 500 MB de espacio de registros binarios para ejecutar una replicación principal-principal. El tamaño real depende de la intensidad de las consultas de actualización/inserción de MySQL que se ejecutan. Necesitará volúmenes de registros binarios de unos cuantos GB para que una aplicación funcione con normalidad.
• El dispositivo conectado a MYSQLR64 es responsable de crear su propia base de datos y tablas, en caso de que no existan. Si lo desea, puede copiar manualmente la base de datos inicial en el volumen de datos.
• El dispositivo o servidor conectado a la entrada in de MYSQLR64 debería tener la biblioteca de cliente de MySQL para acceder al servidor MySQL y enviar solicitudes. Todos los servidores virtuales incluidos en el catálogo del dispositivo tienen la biblioteca de cliente de MySQL instalada, incluido el servidor LINUX genérico.
• Referencias:
  • http://www.mysql.com: sitio Web de MySQL

http://dev.mysql.com/doc/refman/5.0/en/index.html: documentación de MySQL 5.0

Software de fuente abierta de terceros utilizado en el dispositivo

MYSQLR64 utiliza los siguientes paquetes de fuente abierta/de terceros además de los paquetes de fuente abierta/de terceros que utiliza su clase base LUX64.

Solución de problemas de MYSQLR

El dispositivo MYSQLR se bloquea al iniciarse

Desde MYSQLR 1.6.2, se puede establecer o cambiar la contraseña para la cuenta de la base de datos raíz. Sin embargo, el dispositivo MSYQLR tiene algunas cuentas raíz con nombres de host diferentes. Cuando se establezca o cambie una contraseña, se deberá utilizar siempre la cuenta root@%. La cuenta root@% es la cuenta ante la que se autentican los dispositivos conectados al terminal de entrada de MYSQLR . Las otras cuentas raíz se utilizan solamente desde usuarios locales, y no se deberá establecer nunca una contraseña para ellos, ya que al hacerlo el dispositivo MYSQLR dará error al iniciarse.

Nota: Si deja la cuenta root@localhost sin contraseña, no incurrirá en un problema de seguridad, ya que sólo los usuarios locales pueden utilizar esta cuenta en el dispositivo y cualquiera con acceso al dispositivo podrá cambiar la contraseña.

Recuperación de un dispositivo MYSQLR que falla al iniciarse después de haber cambiado la contraseña de la base de datos raíz

Para recuperar un dispositivo que da error al iniciarse porque se ha cambiado la contraseña raíz de la base de datos, realice los pasos siguientes:

1. Inicie el dispositivo o aplicación en el modo de depuración.

   Comando de inicio del dispositivo

   comp start main.MYSQLR --debug 
   

   Comando de inicio de la aplicación

   app start --debug 
   

   Debería poder iniciar sesión en el dispositivo unos cuantos segundos después de iniciar el dispositivo. No es necesario esperar a que el dispositivo alcance el tiempo de espera.

2. Inicie sesión mediante SSH en el dispositivo y ejecute los comandos siguientes:

   mysql -p -e "update mysql.user set Password='' where User='root'" 
   mysqladmin -p flush-privileges 
   mysql -e 'update mysql.user set password=PASSWORD("NEWPASSWORD") where User="root" and Host="%"' 
   mysqladmin flush-privileges
   

Reinicie el dispositivo para comprobar que se inicialice y que las conexiones mysql en el terminal de entrada para la raíz de usuario requieran contraseña.