Etiqueta: linux

Configurar replicacion en MySQL

GUÍA DE INSTALACIÓN

El servidor de MySQL puede replicar una base de datos sobre TCP hacia otra instancia de MySQL para lograr un respaldo casi en tiempo real para redundancia de datos. Este proceso es algo diferente a u MySql funcionando sobre clúster.

MySQL usa un escenario de Maestro-Esclavo, donde el maestro es donde se reciben los cambios y solo son replicados en una sola dirección hacia el esclavo y el esclavo no va a replicar hacia el maestro.

Para configurar la replicación y un solo camino, se tiene que tener MySQL instalado en ambos servidores, uno como maestro y el otro como esclavo, esto se puede realizar con el manejador de paquetes apt-get.

sudo apt-get install mysql-server

La instrucción anterior debe de ser ejecutada en ambos servidores, tanto en el maestro como en el esclavo.

modo de replicación de mysql

Antes de empezar la configuración de nuestra replicación, se debe de considerar que tipo de replicación se va a utilizar.

  • Replicación por transacción, este modo hace que cada vez que se lanza un dato para escribir, se manda en paralelo al servidor de esclavo, tiene como ventaja que ambas bases se encuentran permanentemente en el mismo estado, con la desventaja que, si hay alguna latencia, el motor no libera el registro hasta que no está copiado en el servidor esclavo
  • Replicación por log, este modo lo que hace es que cada log generado por transacciones en el servidor maestro, se replican hacia el servidor esclavo copiando los archivos logs de un servidor a otro, con la ventaja de que si hay alguna interrupción de comunicación o lentitud en él envió de archivos, no interrumpe en nada la transferencia, con la desventaja que puede estar segundos o minutos atrás, dependiendo de la velocidad de transferencia.

CONFIGURACIÓN DE REPLIACIÓN EN MYSQL

La replicación instalada en el servidor es a nivel de logs, replicando en una sola dirección de maestro a esclavo. Esto significa que cualquier cambio hecho al servidor esclavo, no se verá reflejado en el servidor maestro.

  • Maestro

Los siguientes cambios se harán en el servidor maestro, ligeramente diferentes a los cambios que se harán en el servidor esclavo.

Editando el archivo my.cnf de MySQL Se realizaron los siguientes cambios:

vi /etc/my.cnf

Buscamos el parámetro bind-address y lo cambiamos a la ip del servidor maestro.  Se puede obtener la ip del servidor maestro con el comando ifconfig.

bind-address = 10.1.1.100


ahora También buscamos el parámetro server-id y nos aseguramos de que no se encuentre comentado. Hay que asignarle un ID al servidor maestro, en este caso usamos el ID 1 para nuestro servidor maestro.

server-id = 1

Buscamos o agregamos el parámetro log_bin y nos aseguramos de que no esté comentado. Esta es la ubicación donde se guardarán todos los camios realizados a la base de datos y esta será la carpeta que se replicará.

log_bin = /var/log/mysql/mysql-bin.log

Además, se agrega la siguiente entrada donde le diremos como se llama la base de datos que vamos a replicar.

binlog_do_db = SIERRADB

En caso de que querremos más replicas, se podría agregar más parámetros de binlog_do_db, por ejemplo:

binlog_do_db = BASEAREPLICAR2

binlog_do_db = BASEAREPLICAR3

El siguiente paso es crear un usuario con los permisos adecuados para usar la replicación de MySQL. Accede al MySql con el siguiente comando, para poder acceder como super administrador (root).

mysql -u root -p

Se crea un nuevo usuario que se usara para conectar de la instancia maestra a la instancia esclava, este se utilizara para transferir los datos a replicar, en este caso, el usuario se llama mysql_rep

GRANT REPLICATION SLAVE ON *.* TO 'mysql_rep'@'%' IDENTIFIED BY '[PASSWORD]';

Aquí solo hay que remplazar el password con una contraseña segura.

Ahora, vamos a crear la base de datos que será replicada a nuestro servidor esclavo, es importante que después de crear la base de datos, ningún cambio se aplique hasta que la replicación haya sido completada.

create database replication_database;

Una vez terminado, escribe quit Para salir de MySql y luego procede a reiniciar el servicio

service mysql restart

En este punto, Podemos revisar la base de datos que el servidor esta active y configurado para escribir los cambios del logfile, para esto, logueate como root y ejecuta el siguiente comando

mysql -u root -p

SHOW MASTER STATUS;

Lo que te muestra debe de ser similar a esto.

Después de esto, ya debe de estar configurado correctamente el servidor maestro.

  • Esclavo

La configuración del servidor esclavo es muy similar a la configuración del servidor maestro, pero con diferencias muy sutiles.

Edita el archivo my.cnf de la configuración de MySQL y realiza los siguientes cambios:

vi /etc/my.cnf

Encuentra el parámetro bind-address y pones la IP del servidor MAESTRO.  Puedes consultar la ip con el comando ifconfig.

bind-address = 10.1.1.200

Busca el atributo llamado server-id y asegúrate que no esté comentado (que no tenga # al inicio de la línea). Ocupas asignarle al servidor esclavo un ID, En este caso usaremos el ID 2 como esclavo. Toma en cuenta que este número debe de ser único a través de tus configuraciones de la replicación.

server-id = 2

Encuentra o agrega el parámetro log_bin y asegúrate que no esté comentado. Esta es la ubicación donde serán guardados los cambios realizados en la base de datos que estará trayendo del servidor Maestro. Adicional al parámetro log_bin también ocupas configurar el parámetro relay-log solo en tu servidor esclavo.

log_bin = /var/log/mysql/mysql-bin.log

relay-log = /var/log/mysql/mysql-relay-bin.log

Igual que en el servidor maestro, configura el nombre de la base de datos que se va a replicar.

binlog_do_db = SIERRADB

Guarda el archive y reinicia el servicio de MySQL.

service mysql restart

Ahora necesitamos indicarle a MySql donde se encuentra el servidor maestro, primero accede como root.

mysql -u root -p

Tienes que ejecutar el siguiente comando, sustituyendo los siguientes parámetros por el valor adecuado.

  • MASTER_HOST La IP de tu servidor maestro.
  • MASTER_USER el usuario que tu servidor maestro esta usando para conectarse, en este caso es mysql_rep.
  • MASTER_PASSWORD Es el password del usuario mencionado anteriormente
  • MASTER_LOG_FILE es el nombre del archive de logs que el servidor maestro va a usar para la replicación. Este nombre lo Podemos obtener ejecutando el siguiente comando en el servidor maestro SHOW MASTER STATUS.
  • MASTER_LOG_POS es la ubicación de donde el servidor esclavo va a leer para restaurar. La posición del log, la puedes obtener con el comando SHOW MASTER STATUS.

CHANGE MASTER TO MASTER_HOST='10.1.1.100',

MASTER_USER='mysql_rep',

MASTER_PASSWORD='paswdtemporal',

MASTER_LOG_FILE='mysql-bin.000001',

MASTER_LOG_POS=  107;

El paso final para iniciar nuestro servidor esclavo es ver en qué punto se está realizando la replicación y revisar el estatus.

Ejecutando el siguiente comando, iniciamos la replicación (desde el maestro):

START SLAVE;

Y finalmente ejecutamos el siguiente comando para ver que este funcionado.

SHOW SLAVE STATUS;

Si haces un cambio sobre tu servidor maestro, debe de ser inmediatamente replicado en el servidor esclavo. Después de hacer algunos cambios, ejecuta SHOW SLAVE STATUS y debes de ver que el valor de la posición se incrementó.

Esta replica sirve para absolutamente todos los objetos, como índices, estadísticas, y usuarios.

Crear instancia de DataGuard

Nota: la instalacion de Oracle RDBMS se instala en la BD primaria y Standby, en este caso en la standby solo tiene la instalacion.

Primaria:

IP Address: 192.168.2.61
DB_NAME=test
DB_UNIQUE_NAME=test

Standby:

IP Address: 192.168.2.62
DB_NAME=test
DB_UNIQUE_NAME=test_stby

Parametros requeridos:

DB_NAME                                             – Tiene que ser la misma en primaria y standby
DB_UNIQUE_NAME                             – Tiene que ser diferente en la primaria y todas las standby
LOG_ARCHIVE_CONFIG             –  Este parametro incluye el db_unique name que forma parte de la configuracion del DataGuard
LOG_ARCHIVE_DEST_n                     – Define donde se guardaran los archive logs locales y remotos
LOG_ARCHIVE_DEST_STATE_n        – Define el estado del guardado de archive logs, )enable o disable)
REMOTE_LOGIN_PASSWORDFILE    – Siempre tiene que estar en modo EXCLUSIVE
FAL_SERVER                                        – Se usa para resolver como se aplican los archivelogs (solo se requiere en el standby)
DB_FILE_NAME_CONVERT                 – Se requiere cuando la estructura de directorios estan tiene otro datafile (osea los dbf se almacenan en diferentes unidades entre el primario y standby)
LOG_FILE_NAME_CONVERT               – Requiere cuando la estrictura del directorio va a tener otro redolog
STANDBY_FILE_MANAGEMENT          – Para que cree archivos nuevos en el standby

 

Los siguientes pasos en la base de datos primaria:

Nota: Asegurarse que la base de datos este prendida en modo ARCHIVELOG

Revisa tu instancia con los siguientes comandos

SQL> select log_mode from v$database;
              O
SQL> archive log list

Si no esta corriendo, activas los archivelogs con el siguiente secuencia de comandos.

SQL> SHU IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;

Ahora tu instancia esta en modo archivelog

Nota: asegurate que tu BD esta en modo forcelogging.

SQL> SELECT FORCE_LOGGING FROM V$DATABASE;

Si no lo esta, ejecuta el siguiente comando

SQL> ALTER DATABASE FORCE LOGGING;

Ahora verifica el parametro DB_NAME y DB_UNIQUE_NAME de la instancia primaria

SQL> show parameter db_name
SQL> show parameter db_unique_name

Ahora cambia elDB_UNIQUE_NAME Para que forme parte del dataguard. (El servicio de standby aun no se ha creado)

SQL> alter system set log_archive_config=’DG_CONFIG=(test,test_stby)’; 

(test es el service name de la primaria y test_stby es el nombre de la BD standby)

Luego sigue crear el servicio usando netmgr

SQL> host
$netmgr –> service add for std (+) –> net service name std –> hostname standby machine ip –> service name std –> save

Ahora inicia el listener

$lsnrctl start

Define donde se guardaran los archivelogs

SQL> alter system set log_archive_dest_2=’service=std Valid_for=(online_logfiles, primary_role) db_unique_name=std’;

SQL>alter system set log_archive_dest_state_2=enable;

Tienes que configurar el remote password como «exclusive»

SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;
SQL> show parameter remote_login

Se define el «fail server» y si se quiere reconvertir la ruta, por si las rutas entre servidores son diferentes

SQL> ALTER SYSTEM SET FAL_SERVER=test;

SQL> ALTER SYSTEM SET DB_FILE_NAME_CONVERT=’test_stby’,’test’ scope=spfile;

SQL> ALTER SYSTEM SET LOG_FILES_NAME_CONVERT=’test_stby’,’test’ scope=spfile;

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

Ahora sigue replicar la instancia entre servidores (hacer la clonacion), para hacerlo en caliente, se hace con RMAN como sigue

$rman target=/

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

Ahora se crean los controlfile de standby y el nuevo pfile

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/u01/stdcontrol.ctl’;

SQL> CREATE PFILE=’/u01/inittest_stby.ora’ from spfile;

Ahora editas el nuevo spfile

$vi /u01/inittest_stby.ora

 Nota:- El pfile debe de verse algo asi.

std.__db_cache_size=318767104
std.__java_pool_size=4194304
std.__large_pool_size=4194304
std.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
std.__pga_aggregate_target=335544320
std.__sga_target=503316480
std.__shared_io_pool_size=0
std.__shared_pool_size=159383552
std.__streams_pool_size=4194304
*.audit_file_dest='/u01/app/oracle/admin/std/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='/u01/app/oracle/oradata/test_stby/control01.ctl','/u01/app/oracle/fast_recovery_area/test_stby/control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_file_name_convert='test','test_stby'
*.db_name='test'
*.db_unique_name='test_stby'
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=4322230272
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=testXDB)'
*.fal_server='TEST'
*.log_archive_config='DG_CONFIG=(test,test_stby)'
*.log_archive_dest_2='SERVICE=test VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=test'
*.log_archive_dest_state_2='ENABLE'
*.log_file_name_convert='test','test_stby'
*.memory_target=836763648
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.standby_file_management='AUTO'
*.undo_tablespace='UNDOTBS1'

Se graba este archivo y luego creamos los directorios en la maquina de Standby

$mkdir -p /u01/app/oracle/admin/test_stby/adump

$mkdir -p /u01/app/oracle/oradata/test_stby

$mkdir -p /u01/app/oracle/fast_recovery_area/test_stby

Despues de crear los directorios en el servidor de standby y copiar los backupsets, atchivelogs, pfile, controlfile generado con el standby y el archivoe de password hacia el servidor standby.

#scp /u01/stdcontrol.ctl oracle@192.168.1.20:/u01/app/oracle/oradata/test_stby/control01.ctl
#scp /u01/stdcontrol.ctl oracle@192.168.1.20:/u01/app/oracle/fast_recovery_area/test_stby/control02.ctl

Transfiere archivelogs y backups
#scp –r /u01/app/oracle/fast_recovery_area/test oracle@192.168.2.62:/u01/app/oracle/fast_recovery_area/

Copy Parameter file

#scp /u01/inittest_stby.ora oracle@192.168.2.62:/u01/inittest_stby.ora

Transfiere el archivo de password de oracle

#scp /u01/app/oracle/product/11.2.0.4/db_1/dbs/orapwdtest oracle@192.168.1.62:/u01/app/oracle/product/11.2.0.4/db_1/dbs/orapwtest_stby

En el servidor de Standby

$export ORACLE_HOME=/u01/app/oracle/product/11.2.0.1/db_1

Crear el servicio de tnsnames

$netmgr
 =>service naming
           + add new
              Net service name (test)
                      Host name (oradb1)
                             Service name (test)
Prueba la conexion y luego termina
Otro servicio para la standby
        + add new
           Net service name (test_stby)
                 Host name (oradb2)
                         Service name (test_stby)
                                     finish

clic en file => save network configuration

inicia listener

$lsnrctl start

Actualiza /etc/oratab en el standby

$vi /etc/oratab  (add below line in end of file) 

Std:/u01/app/oracle/product/11.2.0.4/db_1:N

restauras backup en el standby

$export ORACLE_SID=test_stby
$sqlplus / as sysdba
Sql> create spfile from pfile=’/u01/inittest_stby.ora’;

Ahora sales del sqlplus y restauras usando rman

Sql> exit

$rman target=/
RMAN>startup mount
RMAN> restore database;
RMAN> exit

Nota: Despues de terminar la restauracion, ocupamos crear los redolog del standby en el servidor de standby

$sqlplus / as sysdba
SQL> alter database add standby logfile (‘/u01/app/oracle/oradata/test_stby/standby_redo01.log’) size 50m;
SQL> alter database add standby logfile (‘/u01/app/oracle/oradata/test_stby/standby_redo02.log’) size 50m;
SQL> alter database add standby logfile (‘/u01/app/oracle/oradata/test_stby/standby_redo03.log’) size 50m;
SQL> alter database add standby logfile (‘/u01/app/oracle/oradata/test_Stby/standby_redo04.log’) size 50m;

Note: ocupamos agregar cuadro archivos de redo log, por que solo tenemos 3 redo logs

Ahora revisa los miembros del grupo de los redologs y puedes confirmarlo con los siguientes querys

SQL> select member from v$logfile  where type=’STANDBY’;

SQL> select member from v$logfile;

 

Nota:- Ahora creamos los mismos redologs en el servidor primario, esto es importante para configurar el cambio de roles, cuando quieras switchear la primaria a Standby, por eso ocupa estos redologs.

Entonces en el servidor primario se agregan los redologs

SQL> alter database add standby logfile (‘/u01/app/oracle/oradata/test/standby_redo01.log’) size 50m;
SQL> alter database add standby logfile (‘/u01/app/oracle/oradata/test/standby_redo02.log’) size 50m;
SQL> alter database add standby logfile (‘/u01/app/oracle/oradata/test/standby_redo03.log’) size 50m;
SQL> alter database add standby logfile (‘/u01/app/oracle/oradata/test/standby_redo04.log’) size 50m;

revisamos

SQL> select member from v$logfile  where type=’STANDBY’;

Ahora inicias la aplicacion de redo logs en la instancia Standby

Recomendado, que antes de aplicar los redologs, abrir el alert en otra ventana

En el servidor standby

SQL> alter database recover managed standby database disconnect from session;

Ejecuta el comando de abajo para revisar la secuencia de redo logs

En el servidor primario

SQL> select sequence#,first_time,next_time from v$archived_log order by sequence#;

Para cuestiones de pruebas, switchea de redo log, para ver si lo esta generando en el secundario

SQL> alter system switch logfile;

Then check what your current sequence number on PRIMARY machine is

SQL> select sequence#,first_time,next_time from v$archived_log order by sequence#;

Luego nos vamos al standby para revisar que este enviando los redologs

en el STANDBY:-

SQL> select sequence#,first_time,next_time,applied from v$archived_log order by sequence#;

Ahora nos vamos al primario para hacer otro switch para ver si los manda al standby.

SQL> alter system switch logfile;

Ahora revisa el nivel de proteccion de ambos servidores

SQL> desc v$database
SQL> select name,open_mode,database_role,db_unique_name,protection_mode from v$database;

YA QUEDO….

 

 

Pasos para configurar el modo de solo lectura en el STANDBY

En la Standby

Ahora convertiremos el standby en modo de solo lectura

En este caso, la BD se podra leer solamente

SQL>Shu immediate
SQL>startup mount;
SQL>alter database open read only;

Despues de correr esos comandos, la instancia sera accesible como solo lectura

Revisamos:

SQL> select name,open_mode,database_role,db_unique_name,protection_mode from v$database;
SQL> select * from scott.emp;   (now you able to read your database)

Ahora nos logueamos en la PRIMARIA y corremos el switch

SQL>alter system switch logfile;

Ahora revisamos si en la standby se aplico o no

SQL> select sequence#,first_time,next_time,applied from v$archived_log order by sequence#;

Nota:-Puedes ver los redo logs nuevos, pero no se han aplicado

Por lo tanto, cuando la instancia esta en modo de solo lectura y es accesible, pero no se aplican los nuevos redologs

Si quieres que vuelva a ser standby normal, es con los siguientes comandos

SQL> shu immediate

SQL> startup mount

SQL> alter database recover managed standby database disconnect from session;

Desarrollo de aplicación de reconocimiento de rostros y emociones

Este es uno de los desarrollos hechos por nuestro equipo, tiene como funcionalidad ser un demo de la capacidad de nuestra aplicación para reconocer edad, genero, emoción, etc. de un grupo de personas, con el propósito de implementarlo en kioskos interactivos.

Esta desarrollado en .NET, utilizando procesamiento de imágenes en la nube de Azure, almacenando las bases de datos utilizando la tecnología de Big Data.

El Oracle Enterprise Manager no inicia al terminar la instalación en Oracle Linux 6.5

El Oracle Enterprise Manager no inicia al terminar la instalación
El Oracle Enterprise Manager no inicia al terminar la instalación

Hace poco al instalar Oracle 11g en Oracle Linux 6.5 me tope con que al finalizar la instalación, no inicia el Enterprise Manager por errores del catalogo del enterprise manager dentro de la BD, a base de muchas pruebas y errores, ya di con el orden correcto para borrar el catalogo y volverlo a crear.

 

El Oracle Enterprise Manager no inicia al terminar la instalación

explicación: el Enterprise Manager es una consola web que te permite administrar completamente la instancia de base de datos e incluso administrar el ambiente RAC, el Enterprise Manager se inicia mediante su propio servidor web, el servicio se llama «emagent» y para prender y apagar el servicio se utiliza «emctl».

 

Para que el «emagent» pueda inicializar, necesita conectarse a la base de datos que se va a vigilar, para hacer esto ocupa su propio usuario (SYSMAN por default) y una serie de esquemas y tablas, a estas se les llama «repositorios», al instalar el Oracle 11g en Oracle Linux 6.5 el Enterprise Manager no inicia, esto viene en la nota de metalink 470246.1 y el bug 6111734.

 

Para solucionarlo, primero se elimina manualmente el usuario del repositorio y otras tablas, en este orden (con un usuario con permisos de sysdba):

Read more

RSYNC + SSH – Clonar una maquina Xen a un VMWare o fisico

 

Clonar una maquina Xen a un VMWare o fisico
Clonar una maquina Xen a un VMWare o fisico

El dia de hoy por fin logre resolver un problema que tuve para clonar una máquina virtual que llevo arrastrando desde hace ya varios meses.

 

El principal problema es que trataba de migrar de un Xen Server con Xen Source hacia un VMWare, al hacer los intentos de conversion con QEMU me enfrente a muchos problemas como un filesystem en EXT2 y que todo estaba encriptado con LVM (Linux Volume Manager). Despues de mucho pensar se me ocurrio un metodo lateral para resolverlo.

 

Clonar la maquina virtual haciendo una copia a bajo nivel con RSYNC (comando para sincronizar dos directorios) y enviarlo a travez del SSH

 

NOTA: nunca se debe de hacer esto en un ambiente productivo, siempre es mil veces mas recomendable hacer una instalación limpia y mover los archivos de interes, en este caso es por que es una aplicación obsoleta sin documentación

 

Clonar una maquina Xen a un VMWare o fisico

 

para eso, utilice este comando:

rsync -aHxv root@1.2.3.4:/boot/* /mount/boot –exclude=/dev –exclude=/proc –exclude=/sys –exclude=/tmp

 

donde los parámetros -aHxv son para sincronizar todo el contenido con lo que tenga la fecha de modificación mas nueva, sin eliminar archivos que sean diferentes entre ambos servidores, además que respete los softlinks creados.

 

El parámetro –exclude es para que ignore esos directorios, debido a que muchos tienen vistas dinámicas que no deben de ser cambiados o por ejemplo en /mount/boot se encuentra el kernel de Linux, si es remplazado algo malo puede ocurrir.

 

capacitación Oracle en Monterrey

capacitacion oracle monterrey
capacitacion oracle monterrey

 

capacitación Oracle en Monterrey.

 

Oracle es el sistema de bases de datos más complejo y sofisticado, dominar este complejo set de aplicaciones y requiere un alto nivel de conocimiento.

 

¿Quieres desarrollarte profesionalmente como DBA?

 

  • Desarrollo tu talento y expertise
  • Aumenta exponencialmente tus oportunidades de trabajo
  • Necesario en prácticamente todas las empresas importantes

 

Capacítate con nosotros e inicia tu carrera como DBA en bases de datos Oracle 11g
Ofrecemos muchas cosas que en ninguna otra institución ofrecen:

 

  • Instructores certificados
  • Guías para la certificación y simulador de examen
  • Cubrimos todos los temas de la certificación y un poco mas
  • Resolución de problemas en bases de datos y prácticas del día a día
  • Soporte y consulta personal sobre temas vistos en la certificación
  • Invitaciones y descuento en cursos especializados de bases de datos
  • Cursos altamente personalizados, máximos con 6 alumnos por curso
  • Excelente ubicación muy céntrica y salón climatizado
  • Descuento a alumnos de universidades
  • Descuento a grupos por empresa

 

Cursos a impartir:
Curso Oracle Linux Administrator con enfoque a Bases de Datos
Curso Oracle Administrator
Curso introducción a PL/SQL
Curso Oracle Tunning
Curso E-Business Suite (Instalación e implementación)

 

mail: admin@dba.mx
telefono: (044) 81 1602 8764

Montar un filesystem de Linux LVM2

Montar un filesystem de Linux LVM2
Montar un filesystem de Linux LVM2

Experimentando con migraciones de máquinas virtuales de Xen Server hacia VMWare, se me presento un problema que fue algo complicado de resolver.

 

Problema: tengo una máquina virtual de la cual desconozco la contraseña de root y no puede levantar
Forma de atacar el problema: Crear otra maquina virtual en limpio con el mismo sistema operativo y copiar todo el contenido de las aplicaciones importantes, para asi sacarle la vuelta a tener que crackear la contraseña de root.
Principal problema: la maquina originalmente esta en XenServer y queria arrancar todo desde VMWare, despues de hacer la migracion (de Xen a VMWare) me aparecia un mensaje de error al tratar de montar el disco duro anterior a la maquina nueva.
Este es el error que me aparecia:

 

terminal:~ # mount /dev/hda2 /mnt/old/

 

mount: unknown filesystem type ‘LVM2_member’
Esto significa que estoy tratando de montar un tipo de filesystem, llamado LVM2 (Logical Volume Manager) que mas que un tipo de particion es un conjunto de particiones dentro de un solo filesystem.

Para montar un filesystem de Linux LVM2

Primero instale el paquete de linux que me permite trabajar con este tipo de particiones y me instala una serie de herramientas:

 

[BASH] # yum install -y lvm2

En las distribuciones de la familia de Red Hat, se hace con el siguiente comando:

 

[BASH] # aptitude install -y lvm2

Primero identifico con el fdisk de linux, para ver la ruta dentro de /dev/ donde se encuentra el filesystem:
terminal:~ # fdisk -l

 

Device Boot Start End Blocks Id System

 

/dev/hda1 * 1 13 104391 83 Linux

/dev/hda2 14 3648 29198137+ 8e Linux LVM

Read more

Laboratorio de base de datos casero HP MiniServer N54L

Laboratorio de base de datos casero HP MiniServer N54L
Laboratorio de base de datos casero HP MiniServer N54L

 

Laboratorio de base de datos casero HP MiniServer N54L

Tengo muchísimo tiempo deseando tener una computadora únicamente dedicada a un laboratorio de software, solo que cuando empezaba a hacer la planeación para armar un equipo que cumpla mis necesidades siempre me detenía el costo; hasta que encontré esta excelente opción de HP, el «HP MicroServer N54L»

Este servidor es bastante sencillo, las características son:
Procesador AMD DualCore 2.4 ghz
viene con 2GB RAM y un disco duro SATA3 de 250GB (7500 RPM)
como el objetivo principal de este servidor es para un equipo de virtualización, además compre 16GB de ram «Kingston HyperBlu de 1650 GHZ» y pronto comprare un disco duro Western Digital Green de 2TB

El costo total fueron 385 dlls + 30 dlls de envio + 100 dlls por los 16GB de memoria RAM

Lo primero que instalare en este servidor es:
Sistema de virtualización con Xen Server
1 – máquina virtual Oracle Linux 6.4 con Oracle Database 11g instalado
2 – Oracle Linux 6.4 con Tuxedo, JDK, WebLogic y PeopleSoft Finanzas
3 – máquina virtual con Centos minimal, con un webserver

esto esta bien para iniciar en lo que compro otro disco duro.

Oracle OFA o el estandar OFA

OFA o «Oracle Flexible Arquitecture» es la guia oficial que saco Oracle que especifica un estandar para la creacion de archivos y directorios para una correcta administracion de las bases de datos de Oracle.

Basicamente, si no existiera este estandar los DBA’s pondrian las carpetas y los archivos de los datafiles donde ellos quisieran, causando problemas de espacios, consistencias, los respaldos se volverian mas complicados, etc.

Seguir el OFA, simplemente significa crear las carpetas en el lugar adecuado siguiendo un solo orden, las ventajas son:

  • Organizar grandes cantidades de datos y software en el disco para mantener un orden y para evitar cuellos de botella.
  • Facilitar tareas administrativas sobre la misma información, como respaldos.
  • Facilitar el cambio entre distintas bases de datos Oracle.
  • Manejar de manera adecuada el crecimiento de las bases de datos Oracle.
  • Ayudar a evitar la defragmentación y evitar la contención de datos.

Continuar leyendo …

Read more

Configurar replicacion en MySQL

Instalacion de la replicacion de MySQL en ambiente maestro-esclavo para alta disponibilidad

Crear instancia de DataGuard

Nota: la instalacion de Oracle RDBMS se instala en la BD primaria y Standby, en este caso en la standby solo tiene la instalacion. …

Desarrollo de aplicación de reconocimiento de rostros y emociones

Este es uno de los desarrollos hechos por nuestro equipo, tiene como funcionalidad ser un demo de la capacidad de nuestra …