Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit TeamsCambios recientesSend via e-MailImprimirEnlace permanente × Tabla de Contenidos Procesos del Servidor de Rèplica Procesos y solución de problemas del replicador RÉPLICA COLA DE ENTRADA (IQUEUE) SELECTIVIDAD Solución de Problemas de Réplica Master_replica_errorlog Master_replica_iqueue Replicator.ini Campos de fecha Procesos del Servidor de Rèplica Procesos y solución de problemas del replicador El Servicio de Réplica se puede dividir en 3 subprocesos “independientes”. RÉPLICA Por réplica entendemos el proceso de transmisión de datos entre los distintos dispositivos involucrados en el proyecto y el servidor de réplica. Entre las tareas de este proceso tendríamos: Gestión de las conexiones, tanto las transmisiones con los dispositivos como las de Base de Datos. Control de Errores. Encriptación de la transmisión. Gestión de lotes de operaciones (Cuando se transmiten las operaciones en “lotes” ó paquetes p.ej:de 50 en 50). Compresión/Descompresión de la información. … COLA DE ENTRADA (IQUEUE) La cola de entrada es una tabla del servidor de réplica llamada master_replica_iqueue. Dicha tabla se va llenando con las operaciones que van replicando los distintos dispositivos, tal cual están en éstos, es decir, con el formato de fecha, ids, etc que tengan éstos. Las ventajas de esta tabla son importantes: VENTAJAS TABLA master_replica_iqueue Las operaciones se transmiten más rápidamente. No hay que esperar a que el servidor de réplica pueda atendernos para transmitir las operaciones que tengamos en los dispositivos, se van almacenando en esta tabla y cuando el servidor pueda procesarlas lo hará, el dispositivo simplemente transmite las operaciones y se olvida. Los posibles problemas que puedan producirse se resuelven en el servidor, de esta forma, evitamos que una operación errónea en un dispositivo deje sin transmitir el resto de operaciones de dicho dispositivo, con el inconveniente que supone conectarnos al dispositivo remoto. SELECTIVIDAD La selectividad es un proceso que permite una réplica SELECTIVA de las operaciones recibidas en el servidor, es decir, no se replica todo lo que llega, a todos los dispositivos. Las operaciones han de pasar una serie de “Condiciones”, que son las que indican si una operación se enviará a un dispositivo o no. P.Ej: Los clientes de Sevilla solamente los van a recibir los dispositivos de aquella provincia. Solución de Problemas de Réplica Cuando tenemos un problema de réplica, lo primero que hacemos es identificar si este está en el Servidor o en el Cliente. La primera vez que echamos a andar un servidor de réplica pondremos el log a 6 para que nos muestre todos los posibles errores de conexión/configuración que podamos tener. A la hora de localizar un fallo en la réplica éste será el orden de cosas a verificar: master_replica_errorlog master_replica_iqueue ficheros de log visor de sucesos Master_replica_errorlog En esta tabla tendremos registros con los errores que se vayan produciendo en la réplica. Si el campo DESCRIPTION tiene un valor que comienza por “[FROM XXX]” quiere decir que el error SE PRODUJO EN EL DISPOSITIVO CLIENTE DE REPLICA (NO se produjo en el servidor). Master_replica_iqueue En esta tabla tendremos los registros que han ido replicando los clientes tal cual estaban en éstos, es decir, con el formato de fechas, ids, etc. Cuando el server tenga tiempo de atender éstas operaciones las irá transformando en las ids y el formato de fecha correspondiente. Una de las SQL que se miran para ver el estado de la réplica es para revisar si hay operaciones “atascadas” en el iqueue. SELECT count(*),mid FROM master_replica_iqueue GROUP BY mid Esta consulta puede devolvernos registros que el servidor debe ir procesando y hemos de refrescar el resultado de la consulta. En el caso en que las operaciones de un determinado mid no se procesen hemos de ver que problema tiene ese mid en concreto y para ello ejecutaremos: SELECT min(id) from master_replica_iqueue where mid=XXX, pues será dicha operación probablemente la que esté fallando e impida se que procesen el resto de operaciones de dicho mid. Si en algún momento nos interesase ver las sql que entran en el master_replica_iqueue y que no se procese la selectividad ni se monitoree la BD hemos de hacer un par de cambios en el replicator.ini: Hemos de quitar la licencia de BD de la clave [Monitor-dbs] En [db-1] o en la clave que corresponda hemos de poner Automonitor=false Reiniciar el servicio de réplica para que los cambios surtan efecto. Replicator.ini Es el fichero de configuración del servidor de réplica, hay que acordarse de no poner espacios a la hora de asignar valores y reiniciar el servicio si se hace algún cambio en este fichero. El nivel de log por defecto cuando se instala el servidor de replica es 0, tanto para el servidor como para cada base de datos monitorizada por éste, dicho valor debería cambiarse por 1 (loglevel=1) para que se registren en el log los fallos más relevantes que puedan ocurrir sin tener ficheros de log monstruosos. Debemos cambiar loglevel=1 tanto en la clave [server] como en [db-1] o la que corresponda. Por otra parte podemos cambiar la carpeta donde se guardan los ficheros de log con la clave logdir=c:\windows…. La ruta donde por defecto se almacenan los ficheros de log es: C:\Windows\System32\Logfiles\CGSoftRpl Campos de fecha En la tabla master_replica_slave hemos de configurar el formato de fecha que maneja cada uno de los dispositivos involucrados en un proyecto. Para ello disponemos de 3 campos: ULDATE Indica el formato de fecha de las operaciones escritas directamente en la cola, como por ejemplo las interfaces. RPDATE Indica el formato de fecha de las operaciones subidas por los clientes vía réplica. DLDATE Indica el formato de fecha que esperan los clientes en las operaciones que le llegan vía réplica. En principio esto parece claro, pero como siempre hay confusiones, vamos a extendernos un rato poniendo un ejemplo: La base de datos es MySQL, por lo que en la sección [dbms-x] se configura DateMask=ymd Todas las operaciones que están en la cola y que han llegado vía réplica estarán con la fecha en este formato. Ahora tenemos un cliente de interface, que llamamos 9999 y que escribe en la cola directamente, ya que las operaciones de interface no llegan vía réplica. La interface tampoco replica, por lo que los campos RPDATE y DLDATE no valen para nada. Su campo ULDATE tendrá valor “ymd” ya que las operaciones que inserta en la cola estarán en el formato de la base de datos. Tenemos un cliente de PDA COM (SQL CE) que envía y recibe las operaciones vía réplica en formato “mdy”. Para este cliente el campo ULDATE no tiene sentido porque no tiene acceso directo a la cola. Sus campos RPDATE y DLDATE tendrán que valer “mdy”. Tenemos un cliente Android (Sqlite) que envía y recibe las operaciones con formato de fecha “ymd”. Para este cliente el campo ULDATE tampoco tiene sentido, y sus campos DLDATE y RPDATE valdrán “ymd”. Si tenemos PCs que trabajen directamente con la base de datos del servidor y que usan su formato de fecha “ymd”, configuramos el cliente con MID -1 con valor ULDATE “ymd”. Los campos RPDATE y DLDATE no tienen sentido para estos terminales, ya que ellos realmente no replican.