Start · Sprachen · PHP · Referenz · MongoDB\Driver\Monitoring\TopologyChangedEvent

MongoDB\Driver\Monitoring\TopologyChangedEvent

Klasse

Repräsentiert ein Ereignis, das ausgelöst wird, wenn sich die Server-Topologie eines MongoDB-Clusters ändert.

seit PHP 1.3.0 Kategorie: db

Signatur

final class MongoDB\Driver\Monitoring\TopologyChangedEvent

Beschreibung

MongoDB\Driver\Monitoring\TopologyChangedEvent ist ein unveränderliches Ereignis-Objekt, das im Rahmen des Server Discovery and Monitoring (SDAM) ausgelöst wird, sobald sich die Topologie eines MongoDB-Clusters verändert. Das kann z. B. auftreten, wenn ein Replikat-Satz-Mitglied ausfällt, ein neuer Primary gewählt wird oder ein Sharding-Cluster umkonfiguriert wird.

Um dieses Ereignis zu empfangen, muss ein Subscriber registriert werden, der das Interface MongoDB\Driver\Monitoring\SDAMSubscriber implementiert und dessen Methode topologyChanged() implementiert. Der Subscriber wird über MongoDB\Driver\Monitoring\addSubscriber() global oder über den Konstruktor des MongoDB\Driver\Manager registriert.

Das Ereignis enthält sowohl die vorherige als auch die aktuelle Topologiebeschreibung als MongoDB\Driver\Monitoring\TopologyDescription-Objekte, was einen direkten Vergleich des Zustands vor und nach der Änderung ermöglicht. Dies ist nützlich für Monitoring-, Logging- und Diagnose-Szenarien.

Die Klasse kann nicht instanziiert werden (kein öffentlicher Konstruktor) und ist final, d. h. sie kann nicht erweitert werden. Instanzen werden ausschließlich vom MongoDB-Treiber erstellt und an den Subscriber übergeben.

Beispiele

Topologie-Änderungen überwachen mit einem SDAMSubscriber

<?php

use MongoDB\Driver\Monitoring\SDAMSubscriber;
use MongoDB\Driver\Monitoring\TopologyChangedEvent;
use MongoDB\Driver\Monitoring\TopologyDescription;
use MongoDB\Driver\Monitoring\ServerChangedEvent;
use MongoDB\Driver\Monitoring\ServerClosedEvent;
use MongoDB\Driver\Monitoring\ServerOpeningEvent;
use MongoDB\Driver\Monitoring\TopologyClosedEvent;
use MongoDB\Driver\Monitoring\TopologyOpeningEvent;
use MongoDB\Driver\Monitoring\ServerHeartbeatFailedEvent;
use MongoDB\Driver\Monitoring\ServerHeartbeatStartedEvent;
use MongoDB\Driver\Monitoring\ServerHeartbeatSucceededEvent;

class TopologyLogger implements SDAMSubscriber
{
    public function topologyChanged(TopologyChangedEvent $event): void
    {
        $prev = $event->getPreviousDescription();
        $curr = $event->getNewDescription();

        echo sprintf(
            "Topologie geändert [ID: %s]:\n  Vorher: %s\n  Nachher: %s\n",
            $event->getTopologyId(),
            $prev->getType(),
            $curr->getType()
        );
    }

    public function topologyOpening(TopologyOpeningEvent $event): void {}
    public function topologyClosed(TopologyClosedEvent $event): void {}
    public function serverChanged(ServerChangedEvent $event): void {}
    public function serverClosed(ServerClosedEvent $event): void {}
    public function serverOpening(ServerOpeningEvent $event): void {}
    public function serverHeartbeatFailed(ServerHeartbeatFailedEvent $event): void {}
    public function serverHeartbeatStarted(ServerHeartbeatStartedEvent $event): void {}
    public function serverHeartbeatSucceeded(ServerHeartbeatSucceededEvent $event): void {}
}

$subscriber = new TopologyLogger();
MongoDB\Driver\Monitoring\addSubscriber($subscriber);

$manager = new MongoDB\Driver\Manager('mongodb://localhost:27017');
// Beliebige Operationen ausführen; Topologie-Änderungen werden protokolliert
$manager->executeCommand('admin', new MongoDB\Driver\Command(['ping' => 1]));
Topologie geändert [ID: 6478a1bc...]: Vorher: Unknown Nachher: Single

Topologietyp vor und nach Änderung vergleichen

<?php

use MongoDB\Driver\Monitoring\SDAMSubscriber;
use MongoDB\Driver\Monitoring\TopologyChangedEvent;

class TopologyDiffLogger implements SDAMSubscriber
{
    public function topologyChanged(TopologyChangedEvent $event): void
    {
        $prev = $event->getPreviousDescription();
        $next = $event->getNewDescription();

        $prevServers = $prev->getServers();
        $nextServers = $next->getServers();

        echo sprintf(
            "Topologie-ID: %s\n" .
            "  Vorheriger Typ: %s, Anzahl Server: %d\n" .
            "  Neuer Typ:      %s, Anzahl Server: %d\n",
            $event->getTopologyId(),
            $prev->getType(),
            count($prevServers),
            $next->getType(),
            count($nextServers)
        );
    }

    // Alle weiteren SDAMSubscriber-Methoden leer implementieren ...
    public function topologyOpening(\MongoDB\Driver\Monitoring\TopologyOpeningEvent $e): void {}
    public function topologyClosed(\MongoDB\Driver\Monitoring\TopologyClosedEvent $e): void {}
    public function serverChanged(\MongoDB\Driver\Monitoring\ServerChangedEvent $e): void {}
    public function serverClosed(\MongoDB\Driver\Monitoring\ServerClosedEvent $e): void {}
    public function serverOpening(\MongoDB\Driver\Monitoring\ServerOpeningEvent $e): void {}
    public function serverHeartbeatFailed(\MongoDB\Driver\Monitoring\ServerHeartbeatFailedEvent $e): void {}
    public function serverHeartbeatStarted(\MongoDB\Driver\Monitoring\ServerHeartbeatStartedEvent $e): void {}
    public function serverHeartbeatSucceeded(\MongoDB\Driver\Monitoring\ServerHeartbeatSucceededEvent $e): void {}
}

$manager = new MongoDB\Driver\Manager(
    'mongodb://localhost:27017',
    [],
    ['allow_invalid_hostname' => false]
);
$manager->addSubscriber(new TopologyDiffLogger());

// Wichtig · Fallstricke

Keine direkte Instanziierung: TopologyChangedEvent besitzt keinen öffentlichen Konstruktor. Instanzen werden ausschließlich intern vom PHP-MongoDB-Treiber erstellt.

Verfügbare Methoden:

  • getTopologyId(): MongoDB\BSON\ObjectId – Gibt die eindeutige ID der Topologie zurück.
  • getPreviousDescription(): MongoDB\Driver\Monitoring\TopologyDescription – Gibt die Topologiebeschreibung vor der Änderung zurück.
  • getNewDescription(): MongoDB\Driver\Monitoring\TopologyDescription – Gibt die Topologiebeschreibung nach der Änderung zurück.

Performance: SDAM-Callbacks werden synchron im Treiber aufgerufen. Aufwändige Operationen in Subscriber-Methoden können die Verbindungsverarbeitung verlangsamen. Für umfangreiches Logging empfiehlt sich das Puffern der Ereignisse und asynchrone Weiterverarbeitung.