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

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 › Aplicación de N niveles que se ejecuta en diferentes instalaciones (apropiada para equilibrio de carga y conmutación por error)

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 de N niveles que se ejecuta en diferentes instalaciones (apropiada para equilibrio de carga y conmutación por error)

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

Nombre de la propiedad	Valor	Notas
auto_create	1	Crea la base de datos si los volúmenes están vacíos.
error_log_filename	master-db.error	Nombre del archivo de registro de errores que se almacenará en el volumen de datos de registros.
error_log_level	error	Nivel de registro de errores.
server_id	1	Servidor principal (no es obligatorio que sea 1; debe ser diferente del server_id del secundario).
rpl_mode	master	Escribir registros binarios para la tarea de replicación.

VPN principal

Nombre de la propiedad	Valor	Notas
mode	server	Funciona como servidor.
tunnel	certificates	Uso de certificados SSL.
tcp_ports	3306,22	Permite usar los puertos que necesita MYSQLR64.
ip_addr	master_vpn_ip	Dirección IP de la VPN en la aplicación principal.
remote_host	slave_vpn_ip	Dirección IP de la VPN en la aplicación secundaria.

slave

Nombre de la propiedad	Valor	Notas
auto_create	1	Crea la base de datos si los volúmenes están vacíos.
error_log_filename	slave-db.error	Nombre del archivo de registro de errores que se almacenará en el volumen de datos de registros.
error_log_level	error	Nivel de registro de errores.
server_id	2	Servidor secundario (no es obligatorio que sea 2; debe ser diferente del server_id del principal).
rpl_mode	slave	Conectarse al principal.

VPN secundario

Nombre de la propiedad	Valor	Notas
mode	client	Funciona como cliente.
tunnel	certificates	Uso de certificados SSL.
auth_path	"client1"	Ruta al archivo de certificado SSL.
ip_addr	slave_vpn_ip	Dirección IP de la VPN en la aplicación secundaria.
remote_host	master_vpn_ip	Dirección IP de la VPN en la aplicación principal.

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 MYSQLR a MYSQLR64 (y viceversa)

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.

El mismo procedimiento se puede utilizar para migrar una base de datos desde un dispositivo de base de datos más viejo (MYSQL, MYSQL5, MYSQL64) o una base de datos MySQL que no se ejecuta en un dispositivo de CA AppLogic.

Para migrar la base de datos:

(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.

Notes

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.

Software	Versión	Modificado	Licencia	Notes
aspell	0.60.3-7.1	No	LGPLv2.1	N/A
aspell-en	6.0-2.1	No	LGPLv2.1	N/A
curl	7.15.5-2	No	MIT	N/A
device-mapper-event	1.02.32-1	No	GPLv2	N/A
freetype	1.02.32-1	No	FTL	N/A
gmp	4.1.4-10.el5	No	LGPLV2.1	N/A
libidn	0.6.5-1.1	No	LGPLv2.1	N/A
libjpeg	6b-37	No	Distribuible	N/A
libpng	1.2.10-7.0.2	No	zlib/libpng	N/A
lvm2	2.6.26-2.1.2.8	No	GPLv2.0	N/A
mysql	5.0.77-3.el5	No	GPL	N/A
mysql-server	5.0.77-3.el5	No	GPLv2	N/A
perl-DBD-MySQL	3.0007-2.el5	No	Artística	N/A
perl-DBI	1.52-2.el5	No	Artística	N/A
php-cli	5.1.6-23.el5	No	PHPv3.01	N/A
php-common	5.1.6-23.el5	No	PHPv3.01	N/A
php-gd	5.1.6-23.el5	No	PHPv3.01	N/A
php-mbstring	5.1.6-23.el5	No	PHPv3.01	N/A
php-mysql	5.1.6-23.el5	No	PHPv3.01	N/A
php-pdo	5.1.6-23.el5	No	PHPv3.01	N/A
rsync	2.6.8-3.1	No	GPLv2	N/A
samba-client	3.0.28-1.el5_2.1	No	GPLv2	N/A
samba-common	3.0.28-1.el5_2.1	No	GPLv2	N/A
sudo	1.6.8p12-10	No	ISC	N/A
lighttpd	1.4.18-1.el5.rf	No	BSD	N/A
perl-IPC-Run	0.84-1.el5.rf	No	Artística	N/A
perl-Time-Duration	1.06-1.el5.rf	No	Artística	N/A
phpMyAdmin	2.11.10-1	No	GPLv2	N/A

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:

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.

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.