Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit TeamsCambios recientesSend via e-MailImprimirEnlace permanente × Tabla de Contenidos Replica de Datos Introducción Tablas Necesarias Descripción de las Tablas Tablas Obligatorias Tablas para Réplica Selectiva Tablas para Réplica de Ficheros master_replica_queue master_replica_slave rl Problemas Frecuentes Replica de Datos Introducción A diferencia de otros sistemas de réplica existentes, la réplica XOne es capaz de enfrentar distintos Sistemas Gestores de Base de Datos. Una configuración de ejemplo puede ser la siguiente: BD del servidor MSSQL SERVER Clientes SQLITE, MSSQLSERVER CE, MYSQL, ORACLE… La maquinaria incluso es capaz de aplicar selectividad de forma que no todos los clientes tengan que recibir una versión completa de la BD principal. Todo lo anterior optimizado para poder convertir cualquier ERP del cliente fácilmente en un entorno movilizado, en el que los distintos métodos de transmisión de datos y variedad de terminales no sean un problema y pueda ser configurado fácilmente. El funcionamiento básico se basa en la replicación de las operaciones INSERT, DELETE y UPDATE de SQL entre los clientes a través de un servidor de réplica que es el encargado de mantener la integridad de la BD principal. Un cliente que puede ser un Android, PC, Windows Mobile, :BlackBerry, iPhone, Symbian o Windows Phone, con distintos DBMS, envían sus operaciones al servidor de réplica y éste a su vez replicará dichas operaciones a los demás clientes. Tablas Necesarias La réplica(Servidor) necesita de las siguientes tablas en la Base de Datos para su correcto funcionamiento: RÉPLICA SERVIDOR OBSERVACIONES OBLIGATORIAS master_replica_queue master_replica_iqueue master_replica_slave master_replica_cmdlog master_replica_errorlog master_replica_excluded rl - Sólo con éstas tablas, tenemos réplica SIMPLE, es decir, se replican TODAS las operaciones. SELECTIVA master_replica_squeue master_replica_selected - Con la réplica selectiva podemos configurar que NO se repliquen todas las operaciones a todos los clientes. Se configura el campo CONDITIONAL=1 en la tabla master_replica_slave y se debe configurar la tabla master_replica_selected. - Podemos hacer que la selectividad sea agrupada (inteligente) en el servidor, agregando un campo TBL en la tabla master_replica_queue, para agrupar aquellas operaciones que se hagan sobre la misma tabla en una única consulta (El DBMS utilizado en el servidor debe permitir subconsultas). FICHEROS master_replica_fields master_replica_files - Hay que configurar un campo en la tabla master_replica_slave con la ruta donde se guardan los ficheros en el servidor (Recordar dar permisos a la carpeta). OPTATIVAS master_replica_bypassed -En esta tabla se incluyen aquellas tablas que no quieras que se replique la información a otros móviles, es decir, operaciones que se realizan en un movil y no quieres que vayan a otros. Lo que hace esta tabla es que cuando llega una operación (iqueue) de una de los registros de tablas, es no enviar esa operación al queue sino que la pasa a la tabla MASTER_REPLICA_BYPASSED_QUEUE. (Campos ID, TBL). (SELECT TBL FROM master_replica_bypassed ORDER BY ID) master_replica_bypassed_queue - Recibe datos de MASTER_REPLICA_BYPASSED. Esta tabla tiene que tener la misma estructura de MASTER_REPLICA_QUEUE. Descripción de las Tablas Tablas Obligatorias Tabla Descripción master_replica_queue - En el servidor hay un histórico de las operaciones que se han ejecutado correctamente y en el cliente contiene las operaciones pendientes de replicar hacia el servidor. - Esta tabla la rellena el servidor de réplica, NO SE TIENE QUE CONFIGURAR NADA, solamente es un histórico de las operaciones realizadas. - Esta tabla debe encontrarse tanto en el servidor de réplica como en los clientes. master_replica_iqueue - Tabla donde se van insertando las operaciones que llegan de los distintos dispositivos clientes de la réplica. - Los registros de esta tabla serán analizados por el servicio de réplica según la selectividad especificada en la tabla master_replica_selected e irá rellenando la tabla master_replica_squeue con los registros que vayan dirigidos a cada dispositivo. master_replica_slave - Contiene información de los clientes de réplica, hasta que operación han replicado, formato de fecha de la BD del cliente, si tiene replica condicional, si se utilizan lotes, etc. - Se va actualizando automáticamente según van replicando los clientes. - Esta tabla se configura casi en su totalidad con xnetsetup2, la utilidad de CGSOFT para firmar los clientes de réplica. master_replica_cmdlog - Vacía, utilizada internamente por el sistema, no hay nada que configurar. master_replica_errorlog - Log con los errores garrafales que se van produciendo, para un log más detallado ver el fichero de log que se puede configurar en el replicator.ini. master_replica_excluded - Información de las tablas de la BD y su campo ID (clave primaria) para que la réplica no inserte el valor de dicho campo desde el servidor hacia el cliente puesto que la gran mayoría de DBMS no aceptan una inserción de valor para un campo autonumérico. Ejemplo: El servidor envía un UPDATE de un producto y éste registro no existe en la BD del cliente de réplica, por alguna razón: error, borrado accidental… En este caso el servidor envía una copia del registro de ese producto para que el cliente lo inserte en su BD, pero a dicho INSERT no se le puede poner valor para el campo ID (clave primaria), puesto que al ser autonumérico en la mayoría de DBMS generaría un error la inserción de valor en dicho campo. rl :- El corazón de la réplica, contiene las relaciones entre tablas del fichero mappings.xml de forma que el servidor de réplica sea capaz de mantener la integridad referencial de las operaciones replicadas. CGSOFT provee una herramienta que analiza el fichero mappings.xml y genera esta tabla. Tablas para Réplica Selectiva master_replica_squeue Cola de operaciones que tienen que replicar los clientes que tienen configurada réplica selectiva, contiene las ID de la tabla master_replica_queue que tiene que ejecutar cada cliente de réplica selectiva. master_replica_selected Aquí se configuran, tabla por tabla, las condiciones que se tienen que cumplir para que la operación se ejecute en los clientes de la réplica selectiva. Tablas para Réplica de Ficheros master_replica_fiels Información de las tablas y los campos donde se almacena el nombre del fichero a replicar. master_replica_files No se configura nada, es el historial o queue de la réplica de ficheros. master_replica_queue Los campos principales de la tabla son los siguientes: CAMPO TIPO OBLIGATORIO OBSERVACIONES ID INT (11) Sí (indice) Autonumérico ROWID VARCHAR (50) Si (indice) Identificador único del registro en toda la BD (En Oracle palabra reservada, usar CGSROWID) OPERID VARCHAR (65) Sí (indice) Identificador único de la operación sobre el registro anterior TIMESTAMP VARCHAR (25) Sí Fecha y Hora a la que se generó la operación en el cliente OPER INT (11) Sí Tipo de operación a replicar 1-Insert 2-Delete y 3-Update MID INT (11) Sí (indice) Identificador del Cliente que realiza la operación SQL TEXT Sí Sentencia SQL ejecutada (En MYSQL 5.0 palabra reservada, usar CGSSQL) DMID INT (11) Sí (indice) Operación generada por el servidor dirigida para un cliente concreto CONDITIONAL INT (11) Sí Para establecer condicionalidad simple TBL VARCHAR (50) Sólo para Select. Agrupada Se utiliza para la selectividad agrupada (MYSQL 4.0 NO, sólo DBMS que admitan Subconsultas) DISABLED INT (11) Sólo para Lotes Se pone a 1 si no queremos que se replique una instrucción determinada DMIDPR INT (11) Sólo para Lotes Debe existir, utilizado internamente. master_replica_slave En esta tabla hay un registro por cada cliente de réplica. Los campos principales de la tabla son los siguientes: CAMPO TIPO OBLIGATORIO OBSERVACIONES ID INT(11) Sí (indice) Autonumérico DIRIP VARCHAR(50) Si Identificador alfanumérico de la licencia. P.ej.: “PDA de Pedro Rodriguez”. PROTOCOLO VARCHAR(50) Si El carácter de este campo es meramente informativo, en los clientes antiguos solamente se tenía acceso vía HTTP, y en los nuevos solo se tiene acceso directo. Por tanto, este campo podrá tomar dos valores:“HTTP“ Indica que el acceso es vía proxy. “DIRECT” Indica que el acceso es directo. LASTID INT(11) Sí (indice) Ultima ID del master_replica_queue que ha ejecutado con éxito el cliente. LASTDMID INT(11) Sí (indice) Ultima ID del master_replica_queue directa para un cliente(DMID) que ha ejecutado con éxito. SINCRONISMO VARCHAR(20) Sí Se emplea para indicar la fecha y hora en que un cliente se ha sincronizado totalmente por última vez con el servidor. MID INT(11) Sí (indice) Identificador único del cliente actual. PENDIENTE INT(11) Sí (indice) Vale 0 o NULL cuando el cliente está en pleno poder para funcionar. Un cliente que tenga este campo a 1 no puede replicar. PRIORITY INT(11) Sí Este campo tiene el valor de la prioridad de este cliente a la hora de resolver un conflicto. Mientras más grande sea este número más prioritario es el cliente. ACTION VARCHAR(20) Sí Este campo se usa para indicarle al cliente que ejecute alguna acción enviada desde el servidor. ULDATE VARCHAR(20) Sí Este campo contiene la máscara de fecha para aquellas aplicaciones que acceden directamente a la base de datos. Es interesante crear un cliente con MID = -1 y poner aquí la máscara de fecha de las aplicaciones directas, de manera que no haya que configurar como clientes de réplica todas las máquinas que trabajan directamente con la base de datos del servidor. DLDATE VARCHAR(20) Sí Este campo contiene la máscara de fecha con la cual se deben enviar las operaciones vía réplica a este cliente. P.ej: dym para PDA con MSSQL SERVER CE RPDATE VARCHAR(20) Sí Este campo es el contrario del anterior, es decir, indica en qué formato vienen las fechas enviadas por éste cliente vía réplica. SERIAL VARCHAR(128) Sí Este campo tiene que contener el número completo de licencia de este cliente. Si está vacío el cliente está inhabilitado y no puede replicar. CONDITIONAL INT(11) Sí (indice) Este campo es un bitmap que contiene banderas del estado selectivo de un cliente. En general un valor nulo o cero en este campo indica que el cliente es normal. En el caso de que el último bit sea un 1 el cliente tendrá réplica selectiva. LASTCID INT(11) Sí Este campo solamente se usa en aquellas bases de datos que tienen al menos un cliente con réplica condicional o selectiva. FILEPATH VARCHAR(128) Sólo réplica de ficheros Tendrá el valor de la ruta en que el cliente almacena los ficheros en el servidor. (La carpeta debe tener permisos) BATCHSIZE INT(11) Lote de Operaciones Si se quiere habilitar el envío de operaciones en bloques hacia el cliente. Si el valor de este campo es NULL ó cero, el servidor usará como tamaño de lote del cliente el valor por defecto(100), leído del archivo de configuración replicator.ini, en la clave DefaultBatchRecords. El tamaño dependerá del tipo de conexión y dispositivo que se trate siendo algunos valores normalmente establecidos los siguientes: PDA ≅ 20, Blackberry ≅ 40-60, ADSL ≅ 100, en algunos casos en que el GPRS era muy malo hubo que bajar el tamaño del lote a 5 en algunas PDA PUSH VARCHAR(35) (Opcional) Solo para PUSH Si el dispositivo no soporta PUSH, estará vacío. Si el dispositivo soporta PUSH, indicará el tipo de conector usado. rl Como ya se ha comentado anteriormente esta tabla es el corazón de la réplica, contiene las relaciones entre tablas de forma que al replicar operaciones hacia los clientes, se haga con los valores . Los campos principales de la tabla son los siguientes: CAMPO TIPO OBLIGATORIO OBSERVACIONES ID INT(11) Sí (indice) Autonumérico T1 VARCHAR(50) Si Nombre de la tabla origen de la relación. F1 VARCHAR(50) Si Campo ID para relacionar con la tabla destino. T2 VARCHAR(50) Si Nombre de la tabla destino de la relación. F2 VARCHAR(50) Si Campo ID de la tabla destino. T VARCHAR(50) Si Campo de Sistema CND VARCHAR(50) Si Campo de Sistema Problemas Frecuentes Si se produce algún cambio en cualquiera de las tablas master_replica_xxxxx, en la tabla rl ó en el replicator.ini, hay que reiniciar el servicio de réplica.