poner_a_funcionar_stand_by

# Entrada en producción de la base de datos de stand by

1. Se debe tener lista una máquina virtual de stand by al día (con un desfase máximo de 4 horas con respecto a la máquina de producción), de ahora en adelante esta máquina se va a llamar _máquina A_

2. Se debe disponer de una máquina virtual con un OVA de producción relativamente actualizada (puede ser la de restauración semestral). Preferiblemente estas dos máquinas virtuales deben estar en el mismo hardware, de ahora en adelante nos referiremos a esta máquina como _máquina B_

3. En la máquina virtual que está actualmente en producción en el CDA, esta será, para efectos de este instructivo, la _máquina C_. Se debe cambiar la IP en la opción de "Editar IP del servidor" para evitar que entre en conflicto cuando se vuelva a encender. Se debe tomar nota de la IP antes de la modificación para poder ponersela después a la máquina B. Si esta máquina virtual no está disponible, omitir este paso.

4. En la máquina A y en la máquina B se debe eliminar el archivo k.bin, para evitar que la base de datos se restaure al iniciarla

5. Si la máquina B tiene ya información, asegúrese de que la carpeta compartida no contiene un archivo k.bin, para evitar que se restaure la base de datos al encender la máquina

6. Si la máquina B es nueva:
	A. Enciendala
	B. Configure el número de licencia.
	C. Configure el logo del CDA

7. Actualícela la máquina B con la misma versión que tenga la máquina C

8. Apague la máquina C (si está disponible), use un apagado "por las buenas" para que Posgresql envíe el último paquete

9. Espere unos segundos a que la máquina A se actualice con los últimos datos de la máquina C

10. Desactive el modo stand by de la máquina A eliminando el archivo /postgresql/9.3/main/recovery.conf

11. Cambie la configuración del postgresql de la máquina A para escuchar por TCP/IP modificando la línea `listen_addresses = ''` por `listen_addresses = '*'` en el archivo /etc/postgresql/9.3/main/postgresql.conf

12. Permita el acceso a la base de datos de la máuqina A desde afuera:
A. Si la máquina B y la máquina A están en el mismo servidor físico, agregue esta línea al archivo /etc/postgresql/9.3/main/pg_hba.conf

host    tecnimaq_pro    tecnimaq    192.168.56.0/24    				md5

B. Si la máquina B y la máquina A están servidores diferentes, agregue esta línea al archivo /etc/postgresql/9.3/main/pg_hba.conf

host    tecnimaq_pro    tecnimaq    192.168.1.0/24    				md5

Hay que tener cuidado que el rango de IP en la línea que se agreca corresponde al rango de red del CDA. Por ejemplo, si Tecni-RTM funciona en la IP 192.168.0.200, la línea que hay que agregar a pg_hba.conf es:

host    tecnimaq_pro    tecnimaq    192.168.0.0/24    				md5

13. Verifique la IP de la máquina A para poder configurarla en la máquina B

14. Reinicie postgresql de la máquina A:

sudo systemctl restart [email protected]

15. En la máquina B, en el archivo ~/tesla/config/database.yml configure la IP de la máquina A que averiguó en el paso 13, cambiando las líneas:

  host: /var/run/postgresql
  socket: /var/run/postgresql/.s.PGSQL.5432

por estas otras:

  host: 192.168.56.102
  port: 5432

Tenga en cuenta que en la variable 'host' debe estar la IP de la máquina A. El puerto siempre es el mismo

16. En la máquina B, en el archivo ~/tesla/lib/scripts/colas.rb cambie el host en la configuración de postgres reemplazando la línea que dice:

  database = PG.connect dbname: 'tecnimaq_pro', user: 'tecnimaq', password: 'foobar', host: '/var/run/postgresql'

por

  database = PG.connect dbname: 'tecnimaq_pro', user: 'tecnimaq', password: 'foobar', host: '192.168.56.102'

Es decir, cambiar el parámetro 'host' por la IP de la máquina A que sacó en el paso 13

17. Reinicie el servicio de tesla y el servicio de colas en la máquina B

sudo service tesla restart
sudo service colas restart

18. Tecni-RTM quedará ya funcionando en la máquina B, pero falta configurarle la IP. Para eso, inicie sesión web en la máquina B y en la parte de "Editar IP del servidor" ingrese los datos que tomó en el paso 3 antes de modificar la IP del servidor

19. Reinicie la máquina B, tenga en cuenta que cada vez que actualice o reinicie la máquina B va a tener que repetir los pasos 15, 16 y 17

20. En este punto ya debería todo estar funcionando perfectamente y toda la información al día, pero el sistema está funcionando en dos máquinas virtuales independientes. Es necesario, lo más pronto posible, migrar la base de datos de la máquina A a la máquina B.

21. Al finalizar la jornada, comprimir la carpeta /postgresql/9.3/main de la máquina A

sudo service monit stop
sudo systemctl stop [email protected]
cd /postgresql/9.3/
sudo tar -zcvf main.tar.gz main/
sudo mv main.tar.gz /media/sf_restaurar_backup

22. Apagar la máquina A

23. Descomprimir esa carpeta en la máquina B en la misma ruta

sudo service monit stop
sudo systemctl stop [email protected]
cp /postgresql/9.3
sudo mv main main-bkp
sudo tar -zxvf /media/sf_restaurar_backup/main.tar.gz

24. Reiniciar la máquina B. Debería funcionar correctamente todo sin tener que repetir los pasos 15, 16 y 17. La máquina B ya funciona sin que la máquina A esté encendida.

25. Poner nuevamente a funcionar el backup en la nube de la máquina B con el instructivo ManualInternoBackupNube

26. Poner a funcionar la máquina de stand by en otra máquina