MET/TEAM sync: several instances, one inventory, nothing lost

24 July 2026

Fluke MET/TEAM is a fixture in many laboratories, and rarely is there only one database of it in the building. Two sites, a separate instance for a major customer, plus a test bench in the basement: that grows quickly, yet it still wants to be maintained once. calServer V2 therefore no longer synchronises against one MET/TEAM database, but against any number of them, treated as equals.

calServer as the source of truth

The principle is deliberately simple: a device flagged for MET/TEAM is synchronised with all active instances. calServer is the hub, MET/TEAM 1 to x hold the same inventory: devices, calibrations, result rows, customers, locations. Nobody has to decide which instance "owns" a device, and nobody maintains the same change twice.

Technically this rests on a link table that holds the valid MET/TEAM UID per instance and record. The fact that instance A keeps a device under a different UID than instance B is a solved problem, not a source of errors.

The return path stays bidirectional: whatever happens in one MET/TEAM instance is imported by calServer and forwarded to the other instances, just not back to the source. This source-instance-safe echo protection prevents exactly the endless loops that replication setups otherwise fail on. Deletions travel the same route and do not get stuck halfway.

Capture continues when the line is down

The test bench sits in the basement, network coverage down there has always been a matter of faith, and the MET/TEAM database is currently unreachable. That used to be the moment when readings ended up on paper and somebody retyped them later.

calServer works with a transactional outbox: every change is committed as its own entry when saved, with ordering, target instance and state (pending, in progress, done, failed, including an attempt count). Capture therefore continues even when the far side stays silent. As soon as the connection is back, the worker processes the queue in the recorded order.

If a single instance goes down, a circuit breaker pauses that instance only and lets the others carry on. Whatever is left over is visible in the admin UI and can be retried deliberately. Readings lost because "the server in the basement was gone" no longer happen in this chain.

Nothing changes on the MET/TEAM side

The interface to MET/TEAM stays exactly the one calServer V1 has been using for years: the same stored procedures, the same change log table, the same provisioning. That is intentional. Moving from V1 to V2 is a switch on the calServer side, not an intervention in the customer system.

For the switch there is a runbook with the most important rule in its title: exactly one sync master. A shared setting decides whether V1 or V2 consumes the changes, and the other side holds still.

What administrators see

Administration lives in one interface: create and switch instances, test the connection, per-instance status with open and failed entries, provisioning of the MET/TEAM infrastructure, triggering a full comparison, inspecting the synchronisation log and the export queue. The primary instance stays protected: it cannot be deleted or deactivated, so a single click cannot disconnect production.

Further reading: Fluke MET/TEAM and the cutover runbook V1 to V2.