Archive for Abril, 2009

Instalaciones desatendidas CentOS 5.2

Necesitamos archivo, anakonda-ks.cfg. Este archivo se genera en /root

con la instalación de cada sistema, este archivo tiene una sintaxi
especial, en el documento de instalación de centos se describen las
opciones.CentOS 5.2

http://www.centos.org/docs/5/html/5.2/pdf/Installation_Guide.pdf

En el CD#1 de la instalación de Centos tenemos una carpeta isolinux
para crear un cd de instalación que contenga Anaconda (Anaconda es el
instalador de Centos/Fedora/RHEL)

Metemos el archivo de kickstart.cfg dentro de la carpeta pero lo
renombramos a ks.cfg

# mkdir /mnt/isolinux
# mount /dev/cdrom /mnt/isolinux

# mkdir  /tmp/isolinux
# cp /mnt/isolinux /tmp/isolinux
# cp <nuestro anakonda.cfg> /tmp/isolinux

Hacemos la ISO con las configuraciones de ks.cfg mediante un sistema
linux (toma ya!!!)

# mkisofs -o file.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -R -J -v -T isolinux/

isolinuxes una carpeta en nuestro sistema de archivos que contiene el
CD de arranque

Para realizar las instalación desatendida, Insertamos el CD de
Arranque y en Anaconta introducimos

linux ks=cdrom:/ks.cfg

Correspondencia Teclado

= –> ¿
: –> n
/ –> -

La idea es tener mas de una imagen para montar cada uno de los
equipos, luego los paquetes de CentOS los tenemos en CD o via PXE en
red.

Tipo:

ks/
-- ks.172.16.157.1.cfg
-- ks.172.16.157.2.cfg

MySQL Replication

La Replicación permite que la información de una base de datos MySQL (llamada Master) sea replicada en una o varios motores MySQL (llamados Slaves).

Mysql Master-Slave replication

La replicación es asíncrona, por lo que los slaves no tienen porqué estar permanentemente conectados para recibir las actializaciones del servidor. Esto permite que la replicación se pueda realizar a larda distancia, incluso con conexiones de tipo dial-up.

Algunos posibles usos de la replicación en MySQL pueden ser:

  • Soluciones de rendimiento: Repartir la carga sobre múltiples slaves hace incrementear el rendimiento de la base de datos. En este ‘paradigma’ todos los inserts y updates se deben realizar en el master. Las lecturas se realizarán sobre los slaves.

  • Integridad de los datos: Toda la informaci-on se replicará en el slave y como éste es capaz de parar el proceso de replica, incluso podríamos paragar el servidor MySQL si no está operativo en el momento será posible realizar un backupt sin corromper la base de datos.

  • Analisis

  • Distribución a larga distancia: Es posible que en una oficina quieras traajar con una copia de la base de datos central. Es posible usar la replicación para crear una copia local sin necesidad de tener una acceso permanente al master.

MySQL soporta la replicación unidirecional asíncrona, en el que un sercidor actua de master y uno o varios actúan como slaves.

La replicación entre servidores MySQL funciona a través del mecanismo de registros binarios (binnary logging). El master MySQL escribe las actualizaciones y cambios como ‘eventos’ en el log. Los slaves se configuran para ralizar la lectura del registro del mastery ejecutar aquellos ‘eventos’ que encuentren en la base de datos local.

En este escenario el master no hace nada, tan solo almacena los cambios en el registro binario. Cada slave guarda una copia de los contenidos del registro del master. Es responsabilidad del slave devidir que instrucciones debe ejecutar

Los slaves guardan una copia del registro del master de la mima forma que la posición hasta la que han leído la información del master. Esto significa que diversos slaves pueden conectarse a un mismo master y es posible que puedan estar en un mimsmo momento ejecutando diferentes partes del mismo registro primario.