MET/TEAM-Sync: mehrere Instanzen, ein Bestand, nichts geht verloren¶
24. Juli 2026
Fluke MET/TEAM ist in vielen Laboren gesetzt, und selten steht nur eine Datenbank davon im Haus. Zwei Standorte, eine getrennte Instanz für einen Großkunden, dazu ein Prüffeld im Keller: gewachsen ist das schnell, gepflegt werden will es trotzdem einmal. calServer V2 synchronisiert deshalb nicht mehr gegen eine MET/TEAM-Datenbank, sondern gegen beliebig viele, gleichberechtigt.
calServer als Quelle der Wahrheit¶
Das Prinzip ist bewusst einfach gehalten: Ein Gerät, das für MET/TEAM markiert ist, wird mit allen aktiven Instanzen abgeglichen. calServer ist der Hub, MET/TEAM 1 bis x halten denselben Bestand: Geräte, Kalibrierungen, Ergebniszeilen, Kunden, Standorte. Niemand muss entscheiden, welche Instanz ein Gerät „besitzt", und niemand pflegt dieselbe Änderung zweimal.
Technisch trägt das eine Verknüpfungstabelle, die je Instanz und Datensatz die dort gültige MET/TEAM-UID hält. Dass Instanz A ein Gerät unter einer anderen UID führt als Instanz B, ist damit ein gelöstes Problem und keine Fehlerquelle mehr.
Der Rückweg bleibt bidirektional: Was in einer MET/TEAM-Instanz passiert, importiert calServer und verteilt es an die übrigen Instanzen weiter, nur nicht zurück an die Quelle. Dieser quellinstanzsichere Echo-Schutz verhindert genau die Endlosschleifen, an denen Replikationen sonst scheitern. Löschungen laufen denselben Weg und bleiben nicht auf halber Strecke liegen.
Erfasst wird auch, wenn die Leitung fehlt¶
Der Prüfstand steht im Keller, das Netz ist dort schon immer eine Glaubensfrage, und die MET/TEAM-Datenbank ist gerade nicht erreichbar. Früher war das der Moment, in dem Messwerte auf Papier landeten und später jemand nachtippen musste.
calServer arbeitet mit einer transaktionalen Ausgangswarteschlange: Jede Änderung wird beim Speichern als eigener Eintrag festgeschrieben, mit Reihenfolge, Zielinstanz und Zustand (offen, in Arbeit, erledigt, fehlgeschlagen, samt Zählung der Versuche). Die Aufnahme läuft also weiter, auch wenn die Gegenstelle schweigt. Sobald die Verbindung wieder steht, arbeitet der Worker die Warteschlange in der aufgezeichneten Reihenfolge ab.
Fällt eine einzelne Instanz aus, pausiert ein Schutzschalter genau diese Instanz und lässt die anderen weiterlaufen. Was liegengeblieben ist, ist in der Admin-UI sichtbar und lässt sich gezielt erneut anstoßen. Verlorene Messwerte, weil „der Server im Keller weg war", gibt es in dieser Kette nicht mehr.
Auf der MET/TEAM-Seite ändert sich nichts¶
Die Schnittstelle zu MET/TEAM bleibt exakt die, die calServer V1 seit Jahren benutzt: dieselben Stored Procedures, dieselbe Änderungsprotokoll-Tabelle, dieselbe Provisionierung. Das ist Absicht. Eine Umstellung von V1 auf V2 ist damit ein Umschalten auf calServer-Seite und kein Eingriff im Kundensystem.
Für den Wechsel gibt es ein Runbook mit der wichtigsten Regel im Titel: genau ein Sync-Master. Eine gemeinsame Einstellung entscheidet, ob V1 oder V2 die Änderungen konsumiert, und die jeweils andere Seite hält still.
Was Administratoren sehen¶
Die Verwaltung sitzt in einer Oberfläche: Instanzen anlegen und umschalten, Verbindung testen, Status je Instanz mit offenen und fehlgeschlagenen Einträgen, Provisionierung der MET/TEAM-Infrastruktur, Vollabgleich anstoßen, Synchronisationsprotokoll und Export-Warteschlange einsehen. Die Primär-Instanz bleibt dabei geschützt: nicht löschbar, nicht deaktivierbar, damit ein Klick nicht die Produktion abhängt.
Weiterführend: Fluke MET/TEAM und das Cutover-Runbook V1 → V2.