RadiatorDB collection force destroy completed
Emission
Log level: WARN
Per-request tracing: No
Logged when an operator force destroys a RadiatorDB collection. The destroy skipped every configured node that did not answer a connection attempt within health_check_timeout, and replication between the reachable nodes caught up before the collection storage was dropped. The collection field names the destroyed collection, destroyed_nodes lists the nodes where it was destroyed, kept_nodes lists the nodes that keep a storage conflict collection with the configured storage, and skipped_nodes lists the unreachable nodes that still store it.
When a skipped node is reachable again, check the collection list in the RadiatorDB maintenance view of Radiator UI and destroy the collection again to remove it from that node. If the collection is configured again before then, setup refuses to create it while the skipped node stores documents in it, and the collection stays unavailable until it is destroyed again, as described in Remove a Collection. If the skipped node held writes to the collection that it had not replicated, replication from that node to the nodes where the collection was destroyed stops at those writes. Remove and reprovision that node to restore replication, as described in Force destroy a collection.