Howto Production ML

Concept and Logic of ML

Technical Aspects of ML

Howto enter in production with ML

Perspective of ML

To enter in production, you have to follow the following steps.

1. Ensure you have a correct standard OpenLSD in function. See the Howto from OpenLSD standard.
2. You then create the new openlsd xml configuration file and its relative legacy xml configuration files for the new OpenLSD Server that will implement some Legacies as part of a ML mode. Most of them should be exactly the same than the previous ones except eventually the port and the base path.
3. Then you execute openlsd.multiple.admin.LSDInitDBMLFromConfigFiles giving a database configuration file, the previous openlsd configuration file and the hostname (DNS or IP) of the target server. It would create the entries in IpPort for the Services relatives to the Legacies defined in the openlsd configuration file.
4. Make sure the new OpenLSD Server is fully configured (same openlsd configuration files, checking access and shutdown, …).
5. You can now starts the Op Handler from openlsd.multiple.ophandler.LSDOpHandler giving the database configuration file, the number of threads during its actions, the stop file (when this file exists, the Op Handler stops once in stable status) and the time (in ms) between two scans of the database when the previous step is over. It should start immediately to synchronize the OpenLSD Servers. If nothing is in the Op table, try to import one file and see if everything seems ok.
6. If the first OpenLSD Server was up and includes some files before the second one (or more) comes into the ML support, you have to synchronize all copies either in concurrent mode (slower since each update is done with synchronization) or in no concurrency mode (no import or delete are done during the procedure is running). You can use either openlsd.multiple.admin.LSDInitOpFromDB or openlsd.multiple.admin.LSDInitOpFromDBForStorage. Two other version exist and use PL/SQL procedures to enable 2.5 faster updates using openlsd.multiple.admin.LSDInitOpFromDBPL or openlsd.multiple.admin.LSDInitOpFromDBPLForStorage. It will populate the Op table from the existing documents from the given source OpenLSD Server, so the Op Handler will take those to synchronize all OpenLSD Servers.
7. You can check the consistency using openlsd.multiple.admin.LSDCheckInDBThreadedML. It only checks LSD consistency with database, but can only correct LSD storage since another ML can have the missing files. So no action is taken into the database. However, it will say if anything goes wrong too from the database. A specific option (‘-opfix’) allows to use the OpHandler to correct the ML copies (import from a valid source when a document is missing, delete the file (if using MD5 checking)).
8. You can also check the consistency using openlsd.multiple.admin.LSDCheckInDBThreadedDualLimitML. It has the same effect than the previous one except that it will use two dates to limit the search (files tested will be those created between these two dates). This version enables to stop during a short time only all operations of import or delete (around 1 minute before and after the start of this process).

In production, it can be sometimes useful to stop the Op Handler. In this case, just create the “stop file” and it should stop (or either use the HTTP Administration interface as for the OpenLSD Server). It can be restart later on. Be careful that never more than one Op Handler is started or the behavior will be unknown.

When a break for whatever reason arrives on the production (disk crash, network link break, …), you can still reuse one of the functions from step 6 to resynchronized in whatever order and way the Legacy from this ML.

Most of the tools from OpenLSD standard mode could be used in the ML mode but sometimes they need to specify on which server you want to act, so the existence of some specific implementation that just reuse the same codes but specifying which server (address and port) to use.