Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit TeamsRecent ChangesSend via e-MailPrintPermalink × Table of Contents Replica Server Processes Processes and solution of replicator problems REPLICA ENTRY QUEUE (IQUEUE) SELECTIVITY Solution of Replica Problems Master_replica_errorlog Master_replica_iqueue Replicator.ini Date fields Replica Server Processes Processes and solution of replicator problems The Replica Service could be devided into 3 “independent” sub-processes. REPLICA Replica is the data transmission process between the different devices involved at the project and the replica server. Among this process tasks we have: Management of the connections, both the transmissions with the device as the ones of the database. Errors control. Encryption of the transmission. Management of operations batches (When the operations are transmitted in “batches” or packs, e.g.: 50 to 50) Compression/Decompression of the information. … ENTRY QUEUE (IQUEUE) The entry queue is a table of the replica server named master_replica_iqueue. This table is filled with the operations that the different devices are replicating, as they are in those ones, with the date format, ids… that this ones have. This table advantages are importants: ADVANTAGES TABLE master_replica_iqueue The operations are more quickly transmitted. There is no need to wait for the replication server to meet us to transmit the operations we have in the devices, they are stored in this table and when the server can process them, the device simply transmits the operations and forgets. The possible problems that may occur are solved in the server, in this way, we avoid that an erroneous operation in a device leaves without transmitting the rest of operations of this device, with the inconvenience of connecting to the remote device. SELECTIVITY Selectivity is a process that allows a SELECTIVE replica of the operations received in the server, that is, it does not replicate everything that is coming to all the devices. The operations have to pass a series of “Conditions”, that are the ones that indicate if an operation will be sent ot a device or not. E.g.: The clients from Sevilla only are going to receive the devices of that province.\\ Solution of Replica Problems When we have a replica problem, the first we make is identify if this one is at the Server or at Client. The first time we run a replica server we will put the log to 6 to show us all the possible errors of connection/configuration we may have. At the time to locate a fail in the replica, this one will be the order of the things to verify: master_replica_errorlog master_replica_iqueue log files event viewer Master_replica_errorlog In this table we will have logs with the error occurred in the replica. If in the DESCRIPTION field there is a value starting by “[FROM XXX]” it means that the error was OCCURRED AN THE REPLICA CLIENT DEVICE (it was NOT occurred at the sever). Master_replica_iqueue In this table we will have the logs the clients have been replicating as they were on these ones, that is, with the date, ids format… When the server has time for dealing with these operations it will be transforming in the ids and the date format appropriate. One of the SQL reviewed in order to see the replica status is for checking if there are operations “stuck” at the iqueue. SELECT count(*),mid FROM master_replica_iqueue GROUP BY mid This query may return us some logs that the server must process and we have to refresh the query result. In the case in which the operations of a particular mid are not processed, we have to verify which problem this particular mid has and for this we will execute: SELECT min(id) from master_replica_iqueue where mid=XXX, since this operations problably will be the one failing and prevents the rest of operations of that mid are processed. If at any time we were trully interested in watching the sql at the master_replica_iqueue and not to process the selectivity nor monitoring the DB, we have to make a couple of changes at the replicator.ini: We have to remove the DB license of the key [Monitor-dbs] At [db-1] or at the key which corresponds we have to put Automonitor=false Restarting the replica service in order the changes have effect. Replicator.ini It is the configuration file of the replica server, it is necessary to remember not to put any space at the time to assign values and restart the service if any change in that file was made. The log level by default when the replica server is installed is 0, as for the server as for each database monitored by this one, such value should be changed by 1 (loglevel=1) in order to be registered at the log the most relevant fails which may arise without having very big log files. We must change loglevel=1 as in the key [server] and it the [db-1] or which corresponds. In the other hand we can change the folder where the log files are saved using the key logdir=c:\windows…. The path where by default the log files are stored in, is the following one: C:\Windows\System32\Logfiles\CGSoftRpl Date fields At the master_replica_slave table we have to configure the date format which each one of the devices involved in a project deals. For this, we have 3 fields: ULDATE It indicates the date format of the operations written directly at the queue, such as the interfaces. RPDATE It indicates the date format of the operations uploaded by the clients via replica. DLDATE It indicates the date format expected by clients in the operations that arrive via replica. At first this seems clear, but there are confusions as always, let's expand by setting an example: The database is MySQL, so at the [dbms-x] section, DateMask=ymd is configured. All the operations that are in queue and have arrive via replica will be with the date in this format. Now we have an interface client to which we call 9999 and that writes at the queue directly, since the interface operations do not arrive via replica. The interface does replicate either, so the RPDATE and DLDATE fields do not worth anything. Its ULDATE field will have “ymd” value since the operations that it inserts at the queue will be in the database format. We have aPDA COM (SQL CE) client which sends and receives the operations via replica in “mdy” format. For this client, the ULDATE field makes no sense because it has no direct access to the queue. Its RPDATE and DLDATE fields wil have to worth “mdy”. We have an Android client(Sqlite) which sends and receives the operations with date format “ymd”. For this client, the ULDATE field makes no sense either, and its DLDATE and RPDATE fields will worth “ymd”. If we have PCs working directly with the database of the server and are using its date format “ymd”, we configure the client with MID -1 with value ULDATE “ymd”. The RPDATE and DLDATE fields makes no sense for these terminals, since they really do not replicate.