Testimonials

Style 1

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.

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;

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.

La versión de Hadoop 2.6 mejoro mucho respecto a las versiones anteriores, esta versión mejoro dramáticamente el HDFS y el MapReduce. esta guía esta hecha para ayudarte a instalar Hadoop 2.6 en CenOS/RHEL 7/6/5 y Oracle Linux.

Si estas aqui, es por que tienes interés en mejorar tus conocimientos de BigData y leíste en algún lado que Hadoop es el primer paso y en ves de buscar cursos buscas guias para poder practicar por tu propia cuenta, Bien hecho, es la decision correcta

Este articulo no incluye la instalación general del sistema operativo o del Java, solo es la configuración mas básica para poder iniciar.

hadoop-logo

Para llevar a cabo esta guía, es necesario que tengas una instalación ya terminada de tu sistema operativo Linux, por bien realizada me refiero a que ya esta instalada con todas las dependencias necesarias, Java 1.8 instalado, la IP asignada como estática, tu ip estática declarada en /etc/hosts, firewall desactivado, SELINUX desactivado y si estas en una maquina virtual, el virtual guest addons completamente instalados sin ningún error, de no tenerlo todo o no estar seguro, haré otros posts al respecto y los vinculare en las siguientes ligas:

Instalando Java 8 en CenOS/RHEL 7/6/5 y Oracle Linux

Instalando una maquina virtual correctamente con CentOS/RHEL 7/6/5 y Oracle Linux

Solucionar problema de instalación de virtual guest addons en VMWare con CenOS/RHEL 7/6/5 y Oracle Linux

Paso 1: Instalación de JAVA

Java es el principal requerimiento para ejecutar hadoop en cualquier sistema, asi que asegúrate que lo tienes correctamente instalado con el comando java -version

# java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

de no aparecer de esta manera, necesitas ir a la liga de instalacion que comente mas arriba.

 

Paso 2: crear el usuario de Hadoop

Recomiendo crear un usuario normal (no root) para que funcione Hadoop. asi que crea una cuenta de sistema con los siguientes comandos

# adduser hadoop
# passwd hadoop

Una ves creado el usuario, switcheamos al usuario hadoop, para continuar trabajando, con el comando

# su - hadoop

después de crear la cuenta, le asignas una contraseña de tu elección, al terminar de hacer esto, es necesario que crees una llave ssh, para permitir que el servidor se pueda conectar consigo mismo a través de una sesión de ssh

# su - hadoop
$ ssh-keygen -t rsa
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 0600 ~/.ssh/authorized_keys

al hacer esto, verificamos que se hayan creado adecuadamente las llaves anteriores, si es la primera ves que escribimos este comando, nos hara una pregunta el sistema operativo, le escribimos YES

$ ssh localhost
$ exit

(nota: si le pusimos un nombre a nuestro servidor, por decir TESTPROD o algo asi, reemplazamos la palabra localhost, por ej. ssh TESTPROD)

Paso 3: Descargamos Hadoop 2.6.0

Ahora descargamos Hadoop de la pagina de apache, si esta muy lento, podemos probar algun mirror que sea mas rápido en el momento, en esta secuencia de comandos, lo descargamos desde la linea de comando, luego lo descomprimimos con el comando tar y luego se genera una carpeta llamada hadoop-2.6.0 esa la renombramos a simplemente hadoop

$ cd ~
$ wget http://apache.claz.org/hadoop/common/hadoop-2.6.0/hadoop-2.6.0.tar.gz
$ tar xzf hadoop-2.6.0.tar.gz
$ mv hadoop-2.6.0 hadoop

Paso 4: configurar el modo pseudo-distribuido en Hadoop

4.1  Configurar y setear las variables de ambiente

para hacer esto, nos vamos al directorio base de nuestro usuario hadoop, (por lo general es /home/hadoop) despues editamos el archivo .bashr

bash profile configurado para Hadoop

El archivo .bash_profile debe de quedar algo asi

c o .bash_profile o .profile esto depende de la distribución que tengamos instalada, para editar los archivos usamos nano o vi , segun los gustos de cada quien, al final del archivo, agregamos:

export HADOOP_HOME=/home/hadoop/hadoop
export HADOOP_INSTALL=$HADOOP_HOME
export HADOOP_MAPRED_HOME=$HADOOP_HOME
export HADOOP_COMMON_HOME=$HADOOP_HOME
export HADOOP_HDFS_HOME=$HADOOP_HOME
export YARN_HOME=$HADOOP_HOME
export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native
export PATH=$PATH:$HADOOP_HOME/sbin:$HADOOP_HOME/bin

después de eso, aplicamos los cambios en el perfil de nuestro usuario activo, eso se puede hacer, saliendo y volviendo a entrar al usuario hadoop o con el comando source

source .bashrc

Ahora editamos el archivo $HADOOP_HOME/hadoop/hadoop-env.sh y ponemos fija la variable del JAVA_HOME.

dentro del archivo anterior buscamos la linea que comience con export JAVA_HOME y la reemplazamos por:

export JAVA_HOME=/opt/jdk1.8.0_66/

donde /opt/jdk.. sea la dirección donde esta nuestra instalación de JAVA

4.2 Edita el archivo de configuración de la aplicación de Hadoop

Hadoop tiene muchos archivos de configuración diferentes, los cuales se necesitan configurar según los requerimientos de tu infraestructura, esta configuración es especifica para una implementacion de un solo nodo, primero nos cambiamos a la siguiente carpeta:

$ cd $HADOOP_HOME/etc/hadoop

dentro de esta carpeta editamos el archivo core-site.xml , donde ponemos lo siguiente (nota, el tag de configuration no debe de repetirse):

core-site

<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://localhost:9000</value>
</property>
</configuration>

 

Editamos el archivo hdfs-site.xml

hdf-site

<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.name.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/namenode</value>
</property>
<property>
<name>dfs.data.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/datanode</value>
</property>
</configuration>

Editamos mapred-site.xml

mapred-site

<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
</configuration>

Editamos yarn-site.xml

yarn-site

<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
</configuration>

4.3 Formateamos con Namenode

Ahora formateamos el namenode usando los siguientes comando, asegúrate donde se encuentra el directorio de almacenamiento en la salida del comando

$ hdfs namenode -format

si todo sale bien, en este comando te despliega una linea que dice Storage directory, allí es donde va a guardar tu información

Paso 5: Iniciamos el cluster de Hadoop

Ya vamos a iniciar el cluster utilizando los scripts que vienen dentro de la carpeta de hadoop, todos estos scripts se encuentran dentro del directorio sbin, necesitamos entrar allí y ejecutarlos todos de uno por uno, en este mismo orden, si marca algún error, verifica que todos los pasos anteriores se hayan hecho bien.

cd $HADOOP_HOME/sbin/

ahora ejecutamos start-dfs.sh

$ start-dfs.sh

dfs

Ahora ejecutamos start-yarn.sh

start-yarn.sh

yarn

Paso 6: accedamos a los servicios de Hadoop desde un navegador.

Los servicios de Hadoop Namenode por defecto se inician en el puerto 50070. asi que accede a tu servidor hacia ese puerto, puede ser desde dentro de la maquina física como localhost, o si estas en una maquina virtual, desde tu maquina Host poniendo la ip del servidor en ves de localhost

http://localhost:50070/

50070

 

Ahora accedamos al puerto 8088 para obtener información sobre el cluster y todas las aplicaciones

http://localhost:8088/

8088

 

Accedamos al puerto 50090 para obtener información sobre el namenode secundario

 

http://localhost:50090/

50090

 

Accedamos al puerto 50075 para obtener datos del datanode principal

http://localhost:50075/

50075

 

Paso 7: probemos Hadoop como nodo sencillo

7.1 Creemos los directorios HDFS necesarios para los siguientes comando

entramos a la carpeta $HADOOP_HOME/bin/ , desde aqui ejecutamos los siguientes comando, para crear las carpetas dentro del storage de HADOOP, esto se hace con el comando hdfs

$ ./hdfs dfs -mkdir /user
$ ./hdfs dfs -mkdir /user/hadoop

7.2 ahora a manera de ejemplo copiamos algún conjunto de archivos de texto dentro de las carpetas del storage HDFS
que acabamos de crear, para cuestiones de ejemplo, copiare los logs del servidor web, pero puedes meter los archivos que quieras, recuerda que estos archivos son los que serán o pueden ser analizados por medio del big data, así que lo ideal seria un compendio de muchísima información en texto plano.

$ hdfs dfs -put /var/log/httpd logs

7.3 ahora entramos con el navegador y ver el filesystem distribuido con la siguiente liga:

http://localhost:50070/explorer.html#/user/hadoop/logs

explora

 

7.4 si quisiéramos hacer lo opuesto y extraer datos del HDFS es con el comando

$ ./hdfs dfs -get logs /tmp/logs
$ ls -l /tmp/logs/

 

LISTO!, si acabaste exitosamente esta guía y no te quedaron claros algunos términos, necesitas leer nuestra pagina de explicación de big data, haciendo click aquí

 

Si todo quedo entendido, sigue la parte interesante y hacer funcionar el big data, puedes seguir este tutorial para utilizar el MapReduce y el WordCount

hadoop

1 validar liga de apex
 
2 Entrar a herramienta asadmin con root
 
3 start-domain o stop domain para detener o iniciar servicios de apex
 
4 Configurar el archivo de configuracion
78 /disco2/apex/ords.wars
62 /u01/apex/ords.wars
Este archivo se corre con java -jar ordswars
java -jar ords.war 
 
tip Ctrl +r
Hostaname: de la base de datos
MDC110CSI
SID: DEV o PROD
 
Usuario: OracleApex
Password : Oracle
 
Después Entrar a la liga administrativa de Glasfish
Aplicacions -> Redeploy -> OK
 
Verificar liga

Style 2

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.

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;

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.

La versión de Hadoop 2.6 mejoro mucho respecto a las versiones anteriores, esta versión mejoro dramáticamente el HDFS y el MapReduce. esta guía esta hecha para ayudarte a instalar Hadoop 2.6 en CenOS/RHEL 7/6/5 y Oracle Linux.

Si estas aqui, es por que tienes interés en mejorar tus conocimientos de BigData y leíste en algún lado que Hadoop es el primer paso y en ves de buscar cursos buscas guias para poder practicar por tu propia cuenta, Bien hecho, es la decision correcta

Este articulo no incluye la instalación general del sistema operativo o del Java, solo es la configuración mas básica para poder iniciar.

hadoop-logo

Para llevar a cabo esta guía, es necesario que tengas una instalación ya terminada de tu sistema operativo Linux, por bien realizada me refiero a que ya esta instalada con todas las dependencias necesarias, Java 1.8 instalado, la IP asignada como estática, tu ip estática declarada en /etc/hosts, firewall desactivado, SELINUX desactivado y si estas en una maquina virtual, el virtual guest addons completamente instalados sin ningún error, de no tenerlo todo o no estar seguro, haré otros posts al respecto y los vinculare en las siguientes ligas:

Instalando Java 8 en CenOS/RHEL 7/6/5 y Oracle Linux

Instalando una maquina virtual correctamente con CentOS/RHEL 7/6/5 y Oracle Linux

Solucionar problema de instalación de virtual guest addons en VMWare con CenOS/RHEL 7/6/5 y Oracle Linux

Paso 1: Instalación de JAVA

Java es el principal requerimiento para ejecutar hadoop en cualquier sistema, asi que asegúrate que lo tienes correctamente instalado con el comando java -version

# java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

de no aparecer de esta manera, necesitas ir a la liga de instalacion que comente mas arriba.

 

Paso 2: crear el usuario de Hadoop

Recomiendo crear un usuario normal (no root) para que funcione Hadoop. asi que crea una cuenta de sistema con los siguientes comandos

# adduser hadoop
# passwd hadoop

Una ves creado el usuario, switcheamos al usuario hadoop, para continuar trabajando, con el comando

# su - hadoop

después de crear la cuenta, le asignas una contraseña de tu elección, al terminar de hacer esto, es necesario que crees una llave ssh, para permitir que el servidor se pueda conectar consigo mismo a través de una sesión de ssh

# su - hadoop
$ ssh-keygen -t rsa
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 0600 ~/.ssh/authorized_keys

al hacer esto, verificamos que se hayan creado adecuadamente las llaves anteriores, si es la primera ves que escribimos este comando, nos hara una pregunta el sistema operativo, le escribimos YES

$ ssh localhost
$ exit

(nota: si le pusimos un nombre a nuestro servidor, por decir TESTPROD o algo asi, reemplazamos la palabra localhost, por ej. ssh TESTPROD)

Paso 3: Descargamos Hadoop 2.6.0

Ahora descargamos Hadoop de la pagina de apache, si esta muy lento, podemos probar algun mirror que sea mas rápido en el momento, en esta secuencia de comandos, lo descargamos desde la linea de comando, luego lo descomprimimos con el comando tar y luego se genera una carpeta llamada hadoop-2.6.0 esa la renombramos a simplemente hadoop

$ cd ~
$ wget http://apache.claz.org/hadoop/common/hadoop-2.6.0/hadoop-2.6.0.tar.gz
$ tar xzf hadoop-2.6.0.tar.gz
$ mv hadoop-2.6.0 hadoop

Paso 4: configurar el modo pseudo-distribuido en Hadoop

4.1  Configurar y setear las variables de ambiente

para hacer esto, nos vamos al directorio base de nuestro usuario hadoop, (por lo general es /home/hadoop) despues editamos el archivo .bashr

bash profile configurado para Hadoop

El archivo .bash_profile debe de quedar algo asi

c o .bash_profile o .profile esto depende de la distribución que tengamos instalada, para editar los archivos usamos nano o vi , segun los gustos de cada quien, al final del archivo, agregamos:

export HADOOP_HOME=/home/hadoop/hadoop
export HADOOP_INSTALL=$HADOOP_HOME
export HADOOP_MAPRED_HOME=$HADOOP_HOME
export HADOOP_COMMON_HOME=$HADOOP_HOME
export HADOOP_HDFS_HOME=$HADOOP_HOME
export YARN_HOME=$HADOOP_HOME
export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native
export PATH=$PATH:$HADOOP_HOME/sbin:$HADOOP_HOME/bin

después de eso, aplicamos los cambios en el perfil de nuestro usuario activo, eso se puede hacer, saliendo y volviendo a entrar al usuario hadoop o con el comando source

source .bashrc

Ahora editamos el archivo $HADOOP_HOME/hadoop/hadoop-env.sh y ponemos fija la variable del JAVA_HOME.

dentro del archivo anterior buscamos la linea que comience con export JAVA_HOME y la reemplazamos por:

export JAVA_HOME=/opt/jdk1.8.0_66/

donde /opt/jdk.. sea la dirección donde esta nuestra instalación de JAVA

4.2 Edita el archivo de configuración de la aplicación de Hadoop

Hadoop tiene muchos archivos de configuración diferentes, los cuales se necesitan configurar según los requerimientos de tu infraestructura, esta configuración es especifica para una implementacion de un solo nodo, primero nos cambiamos a la siguiente carpeta:

$ cd $HADOOP_HOME/etc/hadoop

dentro de esta carpeta editamos el archivo core-site.xml , donde ponemos lo siguiente (nota, el tag de configuration no debe de repetirse):

core-site

<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://localhost:9000</value>
</property>
</configuration>

 

Editamos el archivo hdfs-site.xml

hdf-site

<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.name.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/namenode</value>
</property>
<property>
<name>dfs.data.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/datanode</value>
</property>
</configuration>

Editamos mapred-site.xml

mapred-site

<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
</configuration>

Editamos yarn-site.xml

yarn-site

<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
</configuration>

4.3 Formateamos con Namenode

Ahora formateamos el namenode usando los siguientes comando, asegúrate donde se encuentra el directorio de almacenamiento en la salida del comando

$ hdfs namenode -format

si todo sale bien, en este comando te despliega una linea que dice Storage directory, allí es donde va a guardar tu información

Paso 5: Iniciamos el cluster de Hadoop

Ya vamos a iniciar el cluster utilizando los scripts que vienen dentro de la carpeta de hadoop, todos estos scripts se encuentran dentro del directorio sbin, necesitamos entrar allí y ejecutarlos todos de uno por uno, en este mismo orden, si marca algún error, verifica que todos los pasos anteriores se hayan hecho bien.

cd $HADOOP_HOME/sbin/

ahora ejecutamos start-dfs.sh

$ start-dfs.sh

dfs

Ahora ejecutamos start-yarn.sh

start-yarn.sh

yarn

Paso 6: accedamos a los servicios de Hadoop desde un navegador.

Los servicios de Hadoop Namenode por defecto se inician en el puerto 50070. asi que accede a tu servidor hacia ese puerto, puede ser desde dentro de la maquina física como localhost, o si estas en una maquina virtual, desde tu maquina Host poniendo la ip del servidor en ves de localhost

http://localhost:50070/

50070

 

Ahora accedamos al puerto 8088 para obtener información sobre el cluster y todas las aplicaciones

http://localhost:8088/

8088

 

Accedamos al puerto 50090 para obtener información sobre el namenode secundario

 

http://localhost:50090/

50090

 

Accedamos al puerto 50075 para obtener datos del datanode principal

http://localhost:50075/

50075

 

Paso 7: probemos Hadoop como nodo sencillo

7.1 Creemos los directorios HDFS necesarios para los siguientes comando

entramos a la carpeta $HADOOP_HOME/bin/ , desde aqui ejecutamos los siguientes comando, para crear las carpetas dentro del storage de HADOOP, esto se hace con el comando hdfs

$ ./hdfs dfs -mkdir /user
$ ./hdfs dfs -mkdir /user/hadoop

7.2 ahora a manera de ejemplo copiamos algún conjunto de archivos de texto dentro de las carpetas del storage HDFS
que acabamos de crear, para cuestiones de ejemplo, copiare los logs del servidor web, pero puedes meter los archivos que quieras, recuerda que estos archivos son los que serán o pueden ser analizados por medio del big data, así que lo ideal seria un compendio de muchísima información en texto plano.

$ hdfs dfs -put /var/log/httpd logs

7.3 ahora entramos con el navegador y ver el filesystem distribuido con la siguiente liga:

http://localhost:50070/explorer.html#/user/hadoop/logs

explora

 

7.4 si quisiéramos hacer lo opuesto y extraer datos del HDFS es con el comando

$ ./hdfs dfs -get logs /tmp/logs
$ ls -l /tmp/logs/

 

LISTO!, si acabaste exitosamente esta guía y no te quedaron claros algunos términos, necesitas leer nuestra pagina de explicación de big data, haciendo click aquí

 

Si todo quedo entendido, sigue la parte interesante y hacer funcionar el big data, puedes seguir este tutorial para utilizar el MapReduce y el WordCount

hadoop

1 validar liga de apex
 
2 Entrar a herramienta asadmin con root
 
3 start-domain o stop domain para detener o iniciar servicios de apex
 
4 Configurar el archivo de configuracion
78 /disco2/apex/ords.wars
62 /u01/apex/ords.wars
Este archivo se corre con java -jar ordswars
java -jar ords.war 
 
tip Ctrl +r
Hostaname: de la base de datos
MDC110CSI
SID: DEV o PROD
 
Usuario: OracleApex
Password : Oracle
 
Después Entrar a la liga administrativa de Glasfish
Aplicacions -> Redeploy -> OK
 
Verificar liga

Style 3

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.

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;

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.

La versión de Hadoop 2.6 mejoro mucho respecto a las versiones anteriores, esta versión mejoro dramáticamente el HDFS y el MapReduce. esta guía esta hecha para ayudarte a instalar Hadoop 2.6 en CenOS/RHEL 7/6/5 y Oracle Linux.

Si estas aqui, es por que tienes interés en mejorar tus conocimientos de BigData y leíste en algún lado que Hadoop es el primer paso y en ves de buscar cursos buscas guias para poder practicar por tu propia cuenta, Bien hecho, es la decision correcta

Este articulo no incluye la instalación general del sistema operativo o del Java, solo es la configuración mas básica para poder iniciar.

hadoop-logo

Para llevar a cabo esta guía, es necesario que tengas una instalación ya terminada de tu sistema operativo Linux, por bien realizada me refiero a que ya esta instalada con todas las dependencias necesarias, Java 1.8 instalado, la IP asignada como estática, tu ip estática declarada en /etc/hosts, firewall desactivado, SELINUX desactivado y si estas en una maquina virtual, el virtual guest addons completamente instalados sin ningún error, de no tenerlo todo o no estar seguro, haré otros posts al respecto y los vinculare en las siguientes ligas:

Instalando Java 8 en CenOS/RHEL 7/6/5 y Oracle Linux

Instalando una maquina virtual correctamente con CentOS/RHEL 7/6/5 y Oracle Linux

Solucionar problema de instalación de virtual guest addons en VMWare con CenOS/RHEL 7/6/5 y Oracle Linux

Paso 1: Instalación de JAVA

Java es el principal requerimiento para ejecutar hadoop en cualquier sistema, asi que asegúrate que lo tienes correctamente instalado con el comando java -version

# java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

de no aparecer de esta manera, necesitas ir a la liga de instalacion que comente mas arriba.

 

Paso 2: crear el usuario de Hadoop

Recomiendo crear un usuario normal (no root) para que funcione Hadoop. asi que crea una cuenta de sistema con los siguientes comandos

# adduser hadoop
# passwd hadoop

Una ves creado el usuario, switcheamos al usuario hadoop, para continuar trabajando, con el comando

# su - hadoop

después de crear la cuenta, le asignas una contraseña de tu elección, al terminar de hacer esto, es necesario que crees una llave ssh, para permitir que el servidor se pueda conectar consigo mismo a través de una sesión de ssh

# su - hadoop
$ ssh-keygen -t rsa
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 0600 ~/.ssh/authorized_keys

al hacer esto, verificamos que se hayan creado adecuadamente las llaves anteriores, si es la primera ves que escribimos este comando, nos hara una pregunta el sistema operativo, le escribimos YES

$ ssh localhost
$ exit

(nota: si le pusimos un nombre a nuestro servidor, por decir TESTPROD o algo asi, reemplazamos la palabra localhost, por ej. ssh TESTPROD)

Paso 3: Descargamos Hadoop 2.6.0

Ahora descargamos Hadoop de la pagina de apache, si esta muy lento, podemos probar algun mirror que sea mas rápido en el momento, en esta secuencia de comandos, lo descargamos desde la linea de comando, luego lo descomprimimos con el comando tar y luego se genera una carpeta llamada hadoop-2.6.0 esa la renombramos a simplemente hadoop

$ cd ~
$ wget http://apache.claz.org/hadoop/common/hadoop-2.6.0/hadoop-2.6.0.tar.gz
$ tar xzf hadoop-2.6.0.tar.gz
$ mv hadoop-2.6.0 hadoop

Paso 4: configurar el modo pseudo-distribuido en Hadoop

4.1  Configurar y setear las variables de ambiente

para hacer esto, nos vamos al directorio base de nuestro usuario hadoop, (por lo general es /home/hadoop) despues editamos el archivo .bashr

bash profile configurado para Hadoop

El archivo .bash_profile debe de quedar algo asi

c o .bash_profile o .profile esto depende de la distribución que tengamos instalada, para editar los archivos usamos nano o vi , segun los gustos de cada quien, al final del archivo, agregamos:

export HADOOP_HOME=/home/hadoop/hadoop
export HADOOP_INSTALL=$HADOOP_HOME
export HADOOP_MAPRED_HOME=$HADOOP_HOME
export HADOOP_COMMON_HOME=$HADOOP_HOME
export HADOOP_HDFS_HOME=$HADOOP_HOME
export YARN_HOME=$HADOOP_HOME
export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native
export PATH=$PATH:$HADOOP_HOME/sbin:$HADOOP_HOME/bin

después de eso, aplicamos los cambios en el perfil de nuestro usuario activo, eso se puede hacer, saliendo y volviendo a entrar al usuario hadoop o con el comando source

source .bashrc

Ahora editamos el archivo $HADOOP_HOME/hadoop/hadoop-env.sh y ponemos fija la variable del JAVA_HOME.

dentro del archivo anterior buscamos la linea que comience con export JAVA_HOME y la reemplazamos por:

export JAVA_HOME=/opt/jdk1.8.0_66/

donde /opt/jdk.. sea la dirección donde esta nuestra instalación de JAVA

4.2 Edita el archivo de configuración de la aplicación de Hadoop

Hadoop tiene muchos archivos de configuración diferentes, los cuales se necesitan configurar según los requerimientos de tu infraestructura, esta configuración es especifica para una implementacion de un solo nodo, primero nos cambiamos a la siguiente carpeta:

$ cd $HADOOP_HOME/etc/hadoop

dentro de esta carpeta editamos el archivo core-site.xml , donde ponemos lo siguiente (nota, el tag de configuration no debe de repetirse):

core-site

<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://localhost:9000</value>
</property>
</configuration>

 

Editamos el archivo hdfs-site.xml

hdf-site

<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.name.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/namenode</value>
</property>
<property>
<name>dfs.data.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/datanode</value>
</property>
</configuration>

Editamos mapred-site.xml

mapred-site

<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
</configuration>

Editamos yarn-site.xml

yarn-site

<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
</configuration>

4.3 Formateamos con Namenode

Ahora formateamos el namenode usando los siguientes comando, asegúrate donde se encuentra el directorio de almacenamiento en la salida del comando

$ hdfs namenode -format

si todo sale bien, en este comando te despliega una linea que dice Storage directory, allí es donde va a guardar tu información

Paso 5: Iniciamos el cluster de Hadoop

Ya vamos a iniciar el cluster utilizando los scripts que vienen dentro de la carpeta de hadoop, todos estos scripts se encuentran dentro del directorio sbin, necesitamos entrar allí y ejecutarlos todos de uno por uno, en este mismo orden, si marca algún error, verifica que todos los pasos anteriores se hayan hecho bien.

cd $HADOOP_HOME/sbin/

ahora ejecutamos start-dfs.sh

$ start-dfs.sh

dfs

Ahora ejecutamos start-yarn.sh

start-yarn.sh

yarn

Paso 6: accedamos a los servicios de Hadoop desde un navegador.

Los servicios de Hadoop Namenode por defecto se inician en el puerto 50070. asi que accede a tu servidor hacia ese puerto, puede ser desde dentro de la maquina física como localhost, o si estas en una maquina virtual, desde tu maquina Host poniendo la ip del servidor en ves de localhost

http://localhost:50070/

50070

 

Ahora accedamos al puerto 8088 para obtener información sobre el cluster y todas las aplicaciones

http://localhost:8088/

8088

 

Accedamos al puerto 50090 para obtener información sobre el namenode secundario

 

http://localhost:50090/

50090

 

Accedamos al puerto 50075 para obtener datos del datanode principal

http://localhost:50075/

50075

 

Paso 7: probemos Hadoop como nodo sencillo

7.1 Creemos los directorios HDFS necesarios para los siguientes comando

entramos a la carpeta $HADOOP_HOME/bin/ , desde aqui ejecutamos los siguientes comando, para crear las carpetas dentro del storage de HADOOP, esto se hace con el comando hdfs

$ ./hdfs dfs -mkdir /user
$ ./hdfs dfs -mkdir /user/hadoop

7.2 ahora a manera de ejemplo copiamos algún conjunto de archivos de texto dentro de las carpetas del storage HDFS
que acabamos de crear, para cuestiones de ejemplo, copiare los logs del servidor web, pero puedes meter los archivos que quieras, recuerda que estos archivos son los que serán o pueden ser analizados por medio del big data, así que lo ideal seria un compendio de muchísima información en texto plano.

$ hdfs dfs -put /var/log/httpd logs

7.3 ahora entramos con el navegador y ver el filesystem distribuido con la siguiente liga:

http://localhost:50070/explorer.html#/user/hadoop/logs

explora

 

7.4 si quisiéramos hacer lo opuesto y extraer datos del HDFS es con el comando

$ ./hdfs dfs -get logs /tmp/logs
$ ls -l /tmp/logs/

 

LISTO!, si acabaste exitosamente esta guía y no te quedaron claros algunos términos, necesitas leer nuestra pagina de explicación de big data, haciendo click aquí

 

Si todo quedo entendido, sigue la parte interesante y hacer funcionar el big data, puedes seguir este tutorial para utilizar el MapReduce y el WordCount

hadoop

1 validar liga de apex
 
2 Entrar a herramienta asadmin con root
 
3 start-domain o stop domain para detener o iniciar servicios de apex
 
4 Configurar el archivo de configuracion
78 /disco2/apex/ords.wars
62 /u01/apex/ords.wars
Este archivo se corre con java -jar ordswars
java -jar ords.war 
 
tip Ctrl +r
Hostaname: de la base de datos
MDC110CSI
SID: DEV o PROD
 
Usuario: OracleApex
Password : Oracle
 
Después Entrar a la liga administrativa de Glasfish
Aplicacions -> Redeploy -> OK
 
Verificar liga

Style 4

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.

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;

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.

La versión de Hadoop 2.6 mejoro mucho respecto a las versiones anteriores, esta versión mejoro dramáticamente el HDFS y el MapReduce. esta guía esta hecha para ayudarte a instalar Hadoop 2.6 en CenOS/RHEL 7/6/5 y Oracle Linux.

Si estas aqui, es por que tienes interés en mejorar tus conocimientos de BigData y leíste en algún lado que Hadoop es el primer paso y en ves de buscar cursos buscas guias para poder practicar por tu propia cuenta, Bien hecho, es la decision correcta

Este articulo no incluye la instalación general del sistema operativo o del Java, solo es la configuración mas básica para poder iniciar.

hadoop-logo

Para llevar a cabo esta guía, es necesario que tengas una instalación ya terminada de tu sistema operativo Linux, por bien realizada me refiero a que ya esta instalada con todas las dependencias necesarias, Java 1.8 instalado, la IP asignada como estática, tu ip estática declarada en /etc/hosts, firewall desactivado, SELINUX desactivado y si estas en una maquina virtual, el virtual guest addons completamente instalados sin ningún error, de no tenerlo todo o no estar seguro, haré otros posts al respecto y los vinculare en las siguientes ligas:

Instalando Java 8 en CenOS/RHEL 7/6/5 y Oracle Linux

Instalando una maquina virtual correctamente con CentOS/RHEL 7/6/5 y Oracle Linux

Solucionar problema de instalación de virtual guest addons en VMWare con CenOS/RHEL 7/6/5 y Oracle Linux

Paso 1: Instalación de JAVA

Java es el principal requerimiento para ejecutar hadoop en cualquier sistema, asi que asegúrate que lo tienes correctamente instalado con el comando java -version

# java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

de no aparecer de esta manera, necesitas ir a la liga de instalacion que comente mas arriba.

 

Paso 2: crear el usuario de Hadoop

Recomiendo crear un usuario normal (no root) para que funcione Hadoop. asi que crea una cuenta de sistema con los siguientes comandos

# adduser hadoop
# passwd hadoop

Una ves creado el usuario, switcheamos al usuario hadoop, para continuar trabajando, con el comando

# su - hadoop

después de crear la cuenta, le asignas una contraseña de tu elección, al terminar de hacer esto, es necesario que crees una llave ssh, para permitir que el servidor se pueda conectar consigo mismo a través de una sesión de ssh

# su - hadoop
$ ssh-keygen -t rsa
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 0600 ~/.ssh/authorized_keys

al hacer esto, verificamos que se hayan creado adecuadamente las llaves anteriores, si es la primera ves que escribimos este comando, nos hara una pregunta el sistema operativo, le escribimos YES

$ ssh localhost
$ exit

(nota: si le pusimos un nombre a nuestro servidor, por decir TESTPROD o algo asi, reemplazamos la palabra localhost, por ej. ssh TESTPROD)

Paso 3: Descargamos Hadoop 2.6.0

Ahora descargamos Hadoop de la pagina de apache, si esta muy lento, podemos probar algun mirror que sea mas rápido en el momento, en esta secuencia de comandos, lo descargamos desde la linea de comando, luego lo descomprimimos con el comando tar y luego se genera una carpeta llamada hadoop-2.6.0 esa la renombramos a simplemente hadoop

$ cd ~
$ wget http://apache.claz.org/hadoop/common/hadoop-2.6.0/hadoop-2.6.0.tar.gz
$ tar xzf hadoop-2.6.0.tar.gz
$ mv hadoop-2.6.0 hadoop

Paso 4: configurar el modo pseudo-distribuido en Hadoop

4.1  Configurar y setear las variables de ambiente

para hacer esto, nos vamos al directorio base de nuestro usuario hadoop, (por lo general es /home/hadoop) despues editamos el archivo .bashr

bash profile configurado para Hadoop

El archivo .bash_profile debe de quedar algo asi

c o .bash_profile o .profile esto depende de la distribución que tengamos instalada, para editar los archivos usamos nano o vi , segun los gustos de cada quien, al final del archivo, agregamos:

export HADOOP_HOME=/home/hadoop/hadoop
export HADOOP_INSTALL=$HADOOP_HOME
export HADOOP_MAPRED_HOME=$HADOOP_HOME
export HADOOP_COMMON_HOME=$HADOOP_HOME
export HADOOP_HDFS_HOME=$HADOOP_HOME
export YARN_HOME=$HADOOP_HOME
export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native
export PATH=$PATH:$HADOOP_HOME/sbin:$HADOOP_HOME/bin

después de eso, aplicamos los cambios en el perfil de nuestro usuario activo, eso se puede hacer, saliendo y volviendo a entrar al usuario hadoop o con el comando source

source .bashrc

Ahora editamos el archivo $HADOOP_HOME/hadoop/hadoop-env.sh y ponemos fija la variable del JAVA_HOME.

dentro del archivo anterior buscamos la linea que comience con export JAVA_HOME y la reemplazamos por:

export JAVA_HOME=/opt/jdk1.8.0_66/

donde /opt/jdk.. sea la dirección donde esta nuestra instalación de JAVA

4.2 Edita el archivo de configuración de la aplicación de Hadoop

Hadoop tiene muchos archivos de configuración diferentes, los cuales se necesitan configurar según los requerimientos de tu infraestructura, esta configuración es especifica para una implementacion de un solo nodo, primero nos cambiamos a la siguiente carpeta:

$ cd $HADOOP_HOME/etc/hadoop

dentro de esta carpeta editamos el archivo core-site.xml , donde ponemos lo siguiente (nota, el tag de configuration no debe de repetirse):

core-site

<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://localhost:9000</value>
</property>
</configuration>

 

Editamos el archivo hdfs-site.xml

hdf-site

<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.name.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/namenode</value>
</property>
<property>
<name>dfs.data.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/datanode</value>
</property>
</configuration>

Editamos mapred-site.xml

mapred-site

<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
</configuration>

Editamos yarn-site.xml

yarn-site

<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
</configuration>

4.3 Formateamos con Namenode

Ahora formateamos el namenode usando los siguientes comando, asegúrate donde se encuentra el directorio de almacenamiento en la salida del comando

$ hdfs namenode -format

si todo sale bien, en este comando te despliega una linea que dice Storage directory, allí es donde va a guardar tu información

Paso 5: Iniciamos el cluster de Hadoop

Ya vamos a iniciar el cluster utilizando los scripts que vienen dentro de la carpeta de hadoop, todos estos scripts se encuentran dentro del directorio sbin, necesitamos entrar allí y ejecutarlos todos de uno por uno, en este mismo orden, si marca algún error, verifica que todos los pasos anteriores se hayan hecho bien.

cd $HADOOP_HOME/sbin/

ahora ejecutamos start-dfs.sh

$ start-dfs.sh

dfs

Ahora ejecutamos start-yarn.sh

start-yarn.sh

yarn

Paso 6: accedamos a los servicios de Hadoop desde un navegador.

Los servicios de Hadoop Namenode por defecto se inician en el puerto 50070. asi que accede a tu servidor hacia ese puerto, puede ser desde dentro de la maquina física como localhost, o si estas en una maquina virtual, desde tu maquina Host poniendo la ip del servidor en ves de localhost

http://localhost:50070/

50070

 

Ahora accedamos al puerto 8088 para obtener información sobre el cluster y todas las aplicaciones

http://localhost:8088/

8088

 

Accedamos al puerto 50090 para obtener información sobre el namenode secundario

 

http://localhost:50090/

50090

 

Accedamos al puerto 50075 para obtener datos del datanode principal

http://localhost:50075/

50075

 

Paso 7: probemos Hadoop como nodo sencillo

7.1 Creemos los directorios HDFS necesarios para los siguientes comando

entramos a la carpeta $HADOOP_HOME/bin/ , desde aqui ejecutamos los siguientes comando, para crear las carpetas dentro del storage de HADOOP, esto se hace con el comando hdfs

$ ./hdfs dfs -mkdir /user
$ ./hdfs dfs -mkdir /user/hadoop

7.2 ahora a manera de ejemplo copiamos algún conjunto de archivos de texto dentro de las carpetas del storage HDFS
que acabamos de crear, para cuestiones de ejemplo, copiare los logs del servidor web, pero puedes meter los archivos que quieras, recuerda que estos archivos son los que serán o pueden ser analizados por medio del big data, así que lo ideal seria un compendio de muchísima información en texto plano.

$ hdfs dfs -put /var/log/httpd logs

7.3 ahora entramos con el navegador y ver el filesystem distribuido con la siguiente liga:

http://localhost:50070/explorer.html#/user/hadoop/logs

explora

 

7.4 si quisiéramos hacer lo opuesto y extraer datos del HDFS es con el comando

$ ./hdfs dfs -get logs /tmp/logs
$ ls -l /tmp/logs/

 

LISTO!, si acabaste exitosamente esta guía y no te quedaron claros algunos términos, necesitas leer nuestra pagina de explicación de big data, haciendo click aquí

 

Si todo quedo entendido, sigue la parte interesante y hacer funcionar el big data, puedes seguir este tutorial para utilizar el MapReduce y el WordCount

hadoop

1 validar liga de apex
 
2 Entrar a herramienta asadmin con root
 
3 start-domain o stop domain para detener o iniciar servicios de apex
 
4 Configurar el archivo de configuracion
78 /disco2/apex/ords.wars
62 /u01/apex/ords.wars
Este archivo se corre con java -jar ordswars
java -jar ords.war 
 
tip Ctrl +r
Hostaname: de la base de datos
MDC110CSI
SID: DEV o PROD
 
Usuario: OracleApex
Password : Oracle
 
Después Entrar a la liga administrativa de Glasfish
Aplicacions -> Redeploy -> OK
 
Verificar liga

Style 5

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.

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;

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.

La versión de Hadoop 2.6 mejoro mucho respecto a las versiones anteriores, esta versión mejoro dramáticamente el HDFS y el MapReduce. esta guía esta hecha para ayudarte a instalar Hadoop 2.6 en CenOS/RHEL 7/6/5 y Oracle Linux.

Si estas aqui, es por que tienes interés en mejorar tus conocimientos de BigData y leíste en algún lado que Hadoop es el primer paso y en ves de buscar cursos buscas guias para poder practicar por tu propia cuenta, Bien hecho, es la decision correcta

Este articulo no incluye la instalación general del sistema operativo o del Java, solo es la configuración mas básica para poder iniciar.

hadoop-logo

Para llevar a cabo esta guía, es necesario que tengas una instalación ya terminada de tu sistema operativo Linux, por bien realizada me refiero a que ya esta instalada con todas las dependencias necesarias, Java 1.8 instalado, la IP asignada como estática, tu ip estática declarada en /etc/hosts, firewall desactivado, SELINUX desactivado y si estas en una maquina virtual, el virtual guest addons completamente instalados sin ningún error, de no tenerlo todo o no estar seguro, haré otros posts al respecto y los vinculare en las siguientes ligas:

Instalando Java 8 en CenOS/RHEL 7/6/5 y Oracle Linux

Instalando una maquina virtual correctamente con CentOS/RHEL 7/6/5 y Oracle Linux

Solucionar problema de instalación de virtual guest addons en VMWare con CenOS/RHEL 7/6/5 y Oracle Linux

Paso 1: Instalación de JAVA

Java es el principal requerimiento para ejecutar hadoop en cualquier sistema, asi que asegúrate que lo tienes correctamente instalado con el comando java -version

# java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

de no aparecer de esta manera, necesitas ir a la liga de instalacion que comente mas arriba.

 

Paso 2: crear el usuario de Hadoop

Recomiendo crear un usuario normal (no root) para que funcione Hadoop. asi que crea una cuenta de sistema con los siguientes comandos

# adduser hadoop
# passwd hadoop

Una ves creado el usuario, switcheamos al usuario hadoop, para continuar trabajando, con el comando

# su - hadoop

después de crear la cuenta, le asignas una contraseña de tu elección, al terminar de hacer esto, es necesario que crees una llave ssh, para permitir que el servidor se pueda conectar consigo mismo a través de una sesión de ssh

# su - hadoop
$ ssh-keygen -t rsa
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 0600 ~/.ssh/authorized_keys

al hacer esto, verificamos que se hayan creado adecuadamente las llaves anteriores, si es la primera ves que escribimos este comando, nos hara una pregunta el sistema operativo, le escribimos YES

$ ssh localhost
$ exit

(nota: si le pusimos un nombre a nuestro servidor, por decir TESTPROD o algo asi, reemplazamos la palabra localhost, por ej. ssh TESTPROD)

Paso 3: Descargamos Hadoop 2.6.0

Ahora descargamos Hadoop de la pagina de apache, si esta muy lento, podemos probar algun mirror que sea mas rápido en el momento, en esta secuencia de comandos, lo descargamos desde la linea de comando, luego lo descomprimimos con el comando tar y luego se genera una carpeta llamada hadoop-2.6.0 esa la renombramos a simplemente hadoop

$ cd ~
$ wget http://apache.claz.org/hadoop/common/hadoop-2.6.0/hadoop-2.6.0.tar.gz
$ tar xzf hadoop-2.6.0.tar.gz
$ mv hadoop-2.6.0 hadoop

Paso 4: configurar el modo pseudo-distribuido en Hadoop

4.1  Configurar y setear las variables de ambiente

para hacer esto, nos vamos al directorio base de nuestro usuario hadoop, (por lo general es /home/hadoop) despues editamos el archivo .bashr

bash profile configurado para Hadoop

El archivo .bash_profile debe de quedar algo asi

c o .bash_profile o .profile esto depende de la distribución que tengamos instalada, para editar los archivos usamos nano o vi , segun los gustos de cada quien, al final del archivo, agregamos:

export HADOOP_HOME=/home/hadoop/hadoop
export HADOOP_INSTALL=$HADOOP_HOME
export HADOOP_MAPRED_HOME=$HADOOP_HOME
export HADOOP_COMMON_HOME=$HADOOP_HOME
export HADOOP_HDFS_HOME=$HADOOP_HOME
export YARN_HOME=$HADOOP_HOME
export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native
export PATH=$PATH:$HADOOP_HOME/sbin:$HADOOP_HOME/bin

después de eso, aplicamos los cambios en el perfil de nuestro usuario activo, eso se puede hacer, saliendo y volviendo a entrar al usuario hadoop o con el comando source

source .bashrc

Ahora editamos el archivo $HADOOP_HOME/hadoop/hadoop-env.sh y ponemos fija la variable del JAVA_HOME.

dentro del archivo anterior buscamos la linea que comience con export JAVA_HOME y la reemplazamos por:

export JAVA_HOME=/opt/jdk1.8.0_66/

donde /opt/jdk.. sea la dirección donde esta nuestra instalación de JAVA

4.2 Edita el archivo de configuración de la aplicación de Hadoop

Hadoop tiene muchos archivos de configuración diferentes, los cuales se necesitan configurar según los requerimientos de tu infraestructura, esta configuración es especifica para una implementacion de un solo nodo, primero nos cambiamos a la siguiente carpeta:

$ cd $HADOOP_HOME/etc/hadoop

dentro de esta carpeta editamos el archivo core-site.xml , donde ponemos lo siguiente (nota, el tag de configuration no debe de repetirse):

core-site

<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://localhost:9000</value>
</property>
</configuration>

 

Editamos el archivo hdfs-site.xml

hdf-site

<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.name.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/namenode</value>
</property>
<property>
<name>dfs.data.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/datanode</value>
</property>
</configuration>

Editamos mapred-site.xml

mapred-site

<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
</configuration>

Editamos yarn-site.xml

yarn-site

<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
</configuration>

4.3 Formateamos con Namenode

Ahora formateamos el namenode usando los siguientes comando, asegúrate donde se encuentra el directorio de almacenamiento en la salida del comando

$ hdfs namenode -format

si todo sale bien, en este comando te despliega una linea que dice Storage directory, allí es donde va a guardar tu información

Paso 5: Iniciamos el cluster de Hadoop

Ya vamos a iniciar el cluster utilizando los scripts que vienen dentro de la carpeta de hadoop, todos estos scripts se encuentran dentro del directorio sbin, necesitamos entrar allí y ejecutarlos todos de uno por uno, en este mismo orden, si marca algún error, verifica que todos los pasos anteriores se hayan hecho bien.

cd $HADOOP_HOME/sbin/

ahora ejecutamos start-dfs.sh

$ start-dfs.sh

dfs

Ahora ejecutamos start-yarn.sh

start-yarn.sh

yarn

Paso 6: accedamos a los servicios de Hadoop desde un navegador.

Los servicios de Hadoop Namenode por defecto se inician en el puerto 50070. asi que accede a tu servidor hacia ese puerto, puede ser desde dentro de la maquina física como localhost, o si estas en una maquina virtual, desde tu maquina Host poniendo la ip del servidor en ves de localhost

http://localhost:50070/

50070

 

Ahora accedamos al puerto 8088 para obtener información sobre el cluster y todas las aplicaciones

http://localhost:8088/

8088

 

Accedamos al puerto 50090 para obtener información sobre el namenode secundario

 

http://localhost:50090/

50090

 

Accedamos al puerto 50075 para obtener datos del datanode principal

http://localhost:50075/

50075

 

Paso 7: probemos Hadoop como nodo sencillo

7.1 Creemos los directorios HDFS necesarios para los siguientes comando

entramos a la carpeta $HADOOP_HOME/bin/ , desde aqui ejecutamos los siguientes comando, para crear las carpetas dentro del storage de HADOOP, esto se hace con el comando hdfs

$ ./hdfs dfs -mkdir /user
$ ./hdfs dfs -mkdir /user/hadoop

7.2 ahora a manera de ejemplo copiamos algún conjunto de archivos de texto dentro de las carpetas del storage HDFS
que acabamos de crear, para cuestiones de ejemplo, copiare los logs del servidor web, pero puedes meter los archivos que quieras, recuerda que estos archivos son los que serán o pueden ser analizados por medio del big data, así que lo ideal seria un compendio de muchísima información en texto plano.

$ hdfs dfs -put /var/log/httpd logs

7.3 ahora entramos con el navegador y ver el filesystem distribuido con la siguiente liga:

http://localhost:50070/explorer.html#/user/hadoop/logs

explora

 

7.4 si quisiéramos hacer lo opuesto y extraer datos del HDFS es con el comando

$ ./hdfs dfs -get logs /tmp/logs
$ ls -l /tmp/logs/

 

LISTO!, si acabaste exitosamente esta guía y no te quedaron claros algunos términos, necesitas leer nuestra pagina de explicación de big data, haciendo click aquí

 

Si todo quedo entendido, sigue la parte interesante y hacer funcionar el big data, puedes seguir este tutorial para utilizar el MapReduce y el WordCount

hadoop

1 validar liga de apex
 
2 Entrar a herramienta asadmin con root
 
3 start-domain o stop domain para detener o iniciar servicios de apex
 
4 Configurar el archivo de configuracion
78 /disco2/apex/ords.wars
62 /u01/apex/ords.wars
Este archivo se corre con java -jar ordswars
java -jar ords.war 
 
tip Ctrl +r
Hostaname: de la base de datos
MDC110CSI
SID: DEV o PROD
 
Usuario: OracleApex
Password : Oracle
 
Después Entrar a la liga administrativa de Glasfish
Aplicacions -> Redeploy -> OK
 
Verificar liga

Style 6

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.

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;

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.

La versión de Hadoop 2.6 mejoro mucho respecto a las versiones anteriores, esta versión mejoro dramáticamente el HDFS y el MapReduce. esta guía esta hecha para ayudarte a instalar Hadoop 2.6 en CenOS/RHEL 7/6/5 y Oracle Linux.

Si estas aqui, es por que tienes interés en mejorar tus conocimientos de BigData y leíste en algún lado que Hadoop es el primer paso y en ves de buscar cursos buscas guias para poder practicar por tu propia cuenta, Bien hecho, es la decision correcta

Este articulo no incluye la instalación general del sistema operativo o del Java, solo es la configuración mas básica para poder iniciar.

hadoop-logo

Para llevar a cabo esta guía, es necesario que tengas una instalación ya terminada de tu sistema operativo Linux, por bien realizada me refiero a que ya esta instalada con todas las dependencias necesarias, Java 1.8 instalado, la IP asignada como estática, tu ip estática declarada en /etc/hosts, firewall desactivado, SELINUX desactivado y si estas en una maquina virtual, el virtual guest addons completamente instalados sin ningún error, de no tenerlo todo o no estar seguro, haré otros posts al respecto y los vinculare en las siguientes ligas:

Instalando Java 8 en CenOS/RHEL 7/6/5 y Oracle Linux

Instalando una maquina virtual correctamente con CentOS/RHEL 7/6/5 y Oracle Linux

Solucionar problema de instalación de virtual guest addons en VMWare con CenOS/RHEL 7/6/5 y Oracle Linux

Paso 1: Instalación de JAVA

Java es el principal requerimiento para ejecutar hadoop en cualquier sistema, asi que asegúrate que lo tienes correctamente instalado con el comando java -version

# java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

de no aparecer de esta manera, necesitas ir a la liga de instalacion que comente mas arriba.

 

Paso 2: crear el usuario de Hadoop

Recomiendo crear un usuario normal (no root) para que funcione Hadoop. asi que crea una cuenta de sistema con los siguientes comandos

# adduser hadoop
# passwd hadoop

Una ves creado el usuario, switcheamos al usuario hadoop, para continuar trabajando, con el comando

# su - hadoop

después de crear la cuenta, le asignas una contraseña de tu elección, al terminar de hacer esto, es necesario que crees una llave ssh, para permitir que el servidor se pueda conectar consigo mismo a través de una sesión de ssh

# su - hadoop
$ ssh-keygen -t rsa
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 0600 ~/.ssh/authorized_keys

al hacer esto, verificamos que se hayan creado adecuadamente las llaves anteriores, si es la primera ves que escribimos este comando, nos hara una pregunta el sistema operativo, le escribimos YES

$ ssh localhost
$ exit

(nota: si le pusimos un nombre a nuestro servidor, por decir TESTPROD o algo asi, reemplazamos la palabra localhost, por ej. ssh TESTPROD)

Paso 3: Descargamos Hadoop 2.6.0

Ahora descargamos Hadoop de la pagina de apache, si esta muy lento, podemos probar algun mirror que sea mas rápido en el momento, en esta secuencia de comandos, lo descargamos desde la linea de comando, luego lo descomprimimos con el comando tar y luego se genera una carpeta llamada hadoop-2.6.0 esa la renombramos a simplemente hadoop

$ cd ~
$ wget http://apache.claz.org/hadoop/common/hadoop-2.6.0/hadoop-2.6.0.tar.gz
$ tar xzf hadoop-2.6.0.tar.gz
$ mv hadoop-2.6.0 hadoop

Paso 4: configurar el modo pseudo-distribuido en Hadoop

4.1  Configurar y setear las variables de ambiente

para hacer esto, nos vamos al directorio base de nuestro usuario hadoop, (por lo general es /home/hadoop) despues editamos el archivo .bashr

bash profile configurado para Hadoop

El archivo .bash_profile debe de quedar algo asi

c o .bash_profile o .profile esto depende de la distribución que tengamos instalada, para editar los archivos usamos nano o vi , segun los gustos de cada quien, al final del archivo, agregamos:

export HADOOP_HOME=/home/hadoop/hadoop
export HADOOP_INSTALL=$HADOOP_HOME
export HADOOP_MAPRED_HOME=$HADOOP_HOME
export HADOOP_COMMON_HOME=$HADOOP_HOME
export HADOOP_HDFS_HOME=$HADOOP_HOME
export YARN_HOME=$HADOOP_HOME
export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native
export PATH=$PATH:$HADOOP_HOME/sbin:$HADOOP_HOME/bin

después de eso, aplicamos los cambios en el perfil de nuestro usuario activo, eso se puede hacer, saliendo y volviendo a entrar al usuario hadoop o con el comando source

source .bashrc

Ahora editamos el archivo $HADOOP_HOME/hadoop/hadoop-env.sh y ponemos fija la variable del JAVA_HOME.

dentro del archivo anterior buscamos la linea que comience con export JAVA_HOME y la reemplazamos por:

export JAVA_HOME=/opt/jdk1.8.0_66/

donde /opt/jdk.. sea la dirección donde esta nuestra instalación de JAVA

4.2 Edita el archivo de configuración de la aplicación de Hadoop

Hadoop tiene muchos archivos de configuración diferentes, los cuales se necesitan configurar según los requerimientos de tu infraestructura, esta configuración es especifica para una implementacion de un solo nodo, primero nos cambiamos a la siguiente carpeta:

$ cd $HADOOP_HOME/etc/hadoop

dentro de esta carpeta editamos el archivo core-site.xml , donde ponemos lo siguiente (nota, el tag de configuration no debe de repetirse):

core-site

<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://localhost:9000</value>
</property>
</configuration>

 

Editamos el archivo hdfs-site.xml

hdf-site

<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.name.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/namenode</value>
</property>
<property>
<name>dfs.data.dir</name>
<value>file:///home/hadoop/hadoopdata/hdfs/datanode</value>
</property>
</configuration>

Editamos mapred-site.xml

mapred-site

<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
</configuration>

Editamos yarn-site.xml

yarn-site

<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
</configuration>

4.3 Formateamos con Namenode

Ahora formateamos el namenode usando los siguientes comando, asegúrate donde se encuentra el directorio de almacenamiento en la salida del comando

$ hdfs namenode -format

si todo sale bien, en este comando te despliega una linea que dice Storage directory, allí es donde va a guardar tu información

Paso 5: Iniciamos el cluster de Hadoop

Ya vamos a iniciar el cluster utilizando los scripts que vienen dentro de la carpeta de hadoop, todos estos scripts se encuentran dentro del directorio sbin, necesitamos entrar allí y ejecutarlos todos de uno por uno, en este mismo orden, si marca algún error, verifica que todos los pasos anteriores se hayan hecho bien.

cd $HADOOP_HOME/sbin/

ahora ejecutamos start-dfs.sh

$ start-dfs.sh

dfs

Ahora ejecutamos start-yarn.sh

start-yarn.sh

yarn

Paso 6: accedamos a los servicios de Hadoop desde un navegador.

Los servicios de Hadoop Namenode por defecto se inician en el puerto 50070. asi que accede a tu servidor hacia ese puerto, puede ser desde dentro de la maquina física como localhost, o si estas en una maquina virtual, desde tu maquina Host poniendo la ip del servidor en ves de localhost

http://localhost:50070/

50070

 

Ahora accedamos al puerto 8088 para obtener información sobre el cluster y todas las aplicaciones

http://localhost:8088/

8088

 

Accedamos al puerto 50090 para obtener información sobre el namenode secundario

 

http://localhost:50090/

50090

 

Accedamos al puerto 50075 para obtener datos del datanode principal

http://localhost:50075/

50075

 

Paso 7: probemos Hadoop como nodo sencillo

7.1 Creemos los directorios HDFS necesarios para los siguientes comando

entramos a la carpeta $HADOOP_HOME/bin/ , desde aqui ejecutamos los siguientes comando, para crear las carpetas dentro del storage de HADOOP, esto se hace con el comando hdfs

$ ./hdfs dfs -mkdir /user
$ ./hdfs dfs -mkdir /user/hadoop

7.2 ahora a manera de ejemplo copiamos algún conjunto de archivos de texto dentro de las carpetas del storage HDFS
que acabamos de crear, para cuestiones de ejemplo, copiare los logs del servidor web, pero puedes meter los archivos que quieras, recuerda que estos archivos son los que serán o pueden ser analizados por medio del big data, así que lo ideal seria un compendio de muchísima información en texto plano.

$ hdfs dfs -put /var/log/httpd logs

7.3 ahora entramos con el navegador y ver el filesystem distribuido con la siguiente liga:

http://localhost:50070/explorer.html#/user/hadoop/logs

explora

 

7.4 si quisiéramos hacer lo opuesto y extraer datos del HDFS es con el comando

$ ./hdfs dfs -get logs /tmp/logs
$ ls -l /tmp/logs/

 

LISTO!, si acabaste exitosamente esta guía y no te quedaron claros algunos términos, necesitas leer nuestra pagina de explicación de big data, haciendo click aquí

 

Si todo quedo entendido, sigue la parte interesante y hacer funcionar el big data, puedes seguir este tutorial para utilizar el MapReduce y el WordCount

hadoop

1 validar liga de apex
 
2 Entrar a herramienta asadmin con root
 
3 start-domain o stop domain para detener o iniciar servicios de apex
 
4 Configurar el archivo de configuracion
78 /disco2/apex/ords.wars
62 /u01/apex/ords.wars
Este archivo se corre con java -jar ordswars
java -jar ords.war 
 
tip Ctrl +r
Hostaname: de la base de datos
MDC110CSI
SID: DEV o PROD
 
Usuario: OracleApex
Password : Oracle
 
Después Entrar a la liga administrativa de Glasfish
Aplicacions -> Redeploy -> OK
 
Verificar liga

Menú