.NET Change Feed Processor SDK: Download und Versionshinweise (frühere)

GILT FÜR: NoSQL

Links
SDK-Download NuGet
API-Dokumentation Referenzdokumentation zum Ändern der Feedprozessorbibliotheks-API
Erste Schritte Erste Schritte mit dem .NET Change Feed Processor-SDK
Aktuelles unterstütztes Framework Microsoft .NET Framework 4.5
Microsoft .NET Core

Hinweis

Wenn Sie den Änderungsfeedprozessor verwenden, sehen Sie sich die neueste 3.x-Version des .NET SDKs an, da der Änderungsfeedprozessor bei dieser Version in die SDK integriert ist.

Versionshinweise

V2-Builds

2.5.0

  • Neuer Konstruktor für die Microsoft.Azure.Documents.ChangeFeedProcessor.Logging.TraceLogProvider-Klasse hinzugefügt, die eine Instanz von System.Diagnostics.TraceSource als Argument übernimmt. Dadurch kann der TraceLogProvider, der für die .NET-Ablaufverfolgung verwendet wird, programmgesteuert in einer benutzerdefinierten TraceSource-Instanz erstellt werden, die im Quellcode initialisiert wurde. Vor dieser Änderung war es nur möglich, die .NET-Ablaufverfolgung mithilfe der App.config-Datei zu konfigurieren.

2.4.0

  • Unterstützung für Leasesammlungen, die mit einem als /partitionKey definierten Partitionsschlüssel partitioniert werden können, wurde hinzugefügt. Vor dieser Änderung musste der Partitionsschlüssel der Leasesammlung als /id definiert werden.
  • Dieses Release ermöglicht die Verwendung von Leasesammlungen mit der API für Gremlin, da der Partitionsschlüssel für Gremlin-Sammlungen nicht als /id definiert werden kann.

2.3.2

  • Leasespeicherkompatibilität mit dem [V3 SDK] wurde hinzugefügt, um Pfade für die Livemigration zu ermöglichen. Eine Anwendung kann zu V3 SDK migriert und zur Änderungsfeed-Prozessorbibliothek zurück migriert werden, ohne dass ein Zustand verloren geht.

2.3.1

  • Ein Szenario wurde korrigiert, bei dem der Schließungsgrund FeedProcessing.ChangeFeedObserverCloseReason.Unknown an FeedProcessing.IChangeFeedObserver.CloseAsync gesendet wurde, wenn die Partition nicht gefunden wurde oder wenn das Zielreplikat nicht auf dem neuesten Stand der Lesesitzung ist. In diesen Fällen werden nun die Schließungsgründe FeedProcessing.ChangeFeedObserverCloseReason.ResourceGone und FeedProcessing.ChangeFeedObserverCloseReason.ReadSessionNotAvailable verwendet.
  • Der neue Schließungsgrund FeedProcessing.ChangeFeedObserverCloseReason.ReadSessionNotAvailable wurde hinzugefügt, der zum Schließen des Änderungsfeeds „Beobachter“ gesendet wird, wenn das Zielreplikat nicht auf dem neuesten Stand der Lesesitzung ist.

2.3.0

  • Die neue ChangeFeedProcessorBuilder.WithCheckpointPartitionProcessorFactory-Methode und die zugehörige öffentliche Schnittstelle ICheckpointPartitionProcessorFactory wurden hinzugefügt. Dies ermöglicht einer Implementierung der Schnittstelle IPartitionProcessor, den integrierten Prüfpunktmechanismus zu verwenden. Die neue Factory ähnelt der vorhandenen IPartitionProcessorFactory, mit dem Unterschied, dass die Create-Methode auch den Parameter ILeaseCheckpointer akzeptiert.
  • Nur eine der beiden Methoden (entweder ChangeFeedProcessorBuilder.WithPartitionProcessorFactory oder ChangeFeedProcessorBuilder.WithCheckpointPartitionProcessorFactory) kann für dieselbe ChangeFeedProcessorBuilder-Instanz verwendet werden.

2.2.8

  • Stabilitäts- und Diagnoseverbesserungen:
    • Die Erkennung lang andauernder Lesevorgänge des Änderungsfeeds wird nun unterstützt. Wenn der von der ChangeFeedProcessorOptions.ChangeFeedTimeout Eigenschaft angegebene Wert länger dauert, werden die folgenden Schritte ausgeführt:
      • Der Vorgang zum Lesen des Änderungsfeeds auf der problematischen Partition wird abgebrochen.
      • Die Änderungsfeedprozessor-Instanz verwirft den Besitz der problematischen Lease. Die verworfene Lease wird während des nächsten Schritts zum Leaseabruf durch denselben oder einen anderen Änderungsfeedprozessor-Instanz ausgewählt. Auf diese Weise wird der Lesevorgang des Änderungsfeeds neu gestartet.
      • Ein Problem wird an den Integritätsmonitor gemeldet. Der standardmäßige Integritätsmonitor sendet alle gemeldeten Probleme an das Ablaufverfolgungsprotokoll.
    • Es wurde eine neue öffentliche Eigenschaft hinzugefügt: ChangeFeedProcessorOptions.ChangeFeedTimeout. Der Standardwert dieser Eigenschaft ist 10 Minuten.
    • Es wurde ein neuer öffentlicher Enumerationswert hinzugefügt: Monitoring.MonitoredOperation.ReadChangeFeed. Wenn der Wert von HealthMonitoringRecord.Operation auf Monitoring.MonitoredOperation.ReadChangeFeed festgelegt ist, wird angegeben, dass sich das Integritätsproblem auf das Lesen des Änderungsfeeds bezieht.

2.2.7

  • Verbesserte Lastenausgleichsstrategie für Szenarios, wenn das Abrufen aller Leases länger dauert als das Ablaufintervall der Lease, z. B. aufgrund von Netzwerkproblemen:
    • In diesem Szenario wird ein Lastenausgleichsalgorithmus verwendet, um Leases fälschlicherweise als abgelaufen zu betrachten. Das führt dazu, dass aktiven Besitzern Leases gestohlen werden. Dies könnte einen unnötigen erneuten Ausgleich zahlreicher Leases auslösen.
    • Dieses Problem wurde in der vorliegenden Version folgendermaßen behoben: Bei einem Konflikt wird eine Wiederholung vermieden, wobei die abgelaufene Lease, die der Besitzer nicht geändert hat, abgerufen und dieser Abruf auf die nächste Iteration des Lastenausgleichs verschoben wird.

2.2.6

  • Verbesserte Behandlung von Beobachterausnahmen.
  • Umfassendere Informationen zu Beobachterfehlern:
    • Wenn ein Beobachter aufgrund einer Ausnahme geschlossen wird, die von „ProcessChangesAsync“ des Beobachters ausgelöst wird, erhält „CloseAsync“ nun den reason-Parameter „ChangeFeedObserverCloseReason.ObserverError“.
    • Hinzugefügte Ablaufverfolgungen zum Bestimmen von Fehlern im Benutzercode bei einem Beobachter.

2.2.5

  • Unterstützung für die Verarbeitung von Aufteilungen von Sammlungen, die gemeinsam genutzten Datenbankdurchsatz verwenden, wurde hinzugefügt.
    • Diese Version behebt ein Problem, das u. U. bei einer Aufteilung von Sammlungen mit gemeinsam genutztem Datenbankdurchsatz entsteht, wenn die Aufteilung zu einem Partitionsausgleich führt, bei dem nur ein untergeordneter Partitionsschlüsselbereich (statt zwei) erstellt wird. In diesem Fall kann der Change Feed Processor beim Löschen der Lease für den alten Partitionsschlüsselbereich hängen bleiben und erstellt keine neuen Leases mehr. Dieses Problem wurde in diesem Release behoben.

2.2.4

  • Die Eigenschaft ChangeFeedProcessorOptions.StartContinuation wurde hinzugefügt, um das Starten des Änderungsfeeds über das Fortsetzungstoken für die Anforderung zu unterstützen. Dies wird nur verwendet, wenn die Leasesammlung leer ist oder für eine Lease kein ContinuationToken festgelegt wurde. Bei Leases in einer Leasesammlung, für die ein ContinuationToken festgelegt wurde, wird dieses verwendet und ChangeFeedProcessorOptions.StartContinuation ignoriert.

2.2.3

  • Unterstützung für die Verwendung von benutzerdefinierten Speichern für das Beibehalten von Fortsetzungstoken pro Partition wurde hinzugefügt.
    • Ein benutzerdefinierter Leasespeicher kann z.B. eine Azure Cosmos DB-Leasesammlung sein, die auf eine beliebige benutzerdefinierte Weise partitioniert wurde.
    • Benutzerdefinierte Leasespeicher können den neuen Erweiterbarkeitspunkt ChangeFeedProcessorBuilder.WithLeaseStoreManager(ILeaseStoreManager) und die öffentliche ILeaseStoreManager-Schnittstelle verwenden.
    • Die ILeaseManager-Schnittstelle wurde in mehrere Rollenschnittstellen umgestaltet.
  • Kleiner Breaking Change: Der Erweiterbarkeitspunkt ChangeFeedProcessorBuilder.WithLeaseManager(ILeaseManager) wurde entfernt. Verwenden Sie stattdessen ChangeFeedProcessorBuilder.WithLeaseStoreManager(ILeaseStoreManager).

2.2.2

  • Dieses Release behebt ein Problem, das während der Verarbeitung einer Teilung in einer überwachten Sammlung und bei Verwendung einer partitionierten Leasesammlung auftritt. Wenn Sie eine Lease für eine Teilungspartition verarbeiten, wird die Lease für diese Partition möglicherweise nicht gelöscht. Dieses Problem wurde in diesem Release behoben.

2.2.1

  • Die Berechnung der Schätzung für Konten mit mehreren Schreibregionen wurde korrigiert und ein neues Sitzungstokenformat eingeführt.

2.2.0

  • Unterstützung für partitionierte Leasesammlungen wurde hinzugefügt. Der Partitionsschlüssel muss als „/id“ definiert werden.
  • Geringfügige Änderung: die Methoden der IChangeFeedDocumentClient-Schnittstelle und der ChangeFeedDocumentClient-Klasse wurden geändert, um die Parameter RequestOptions und CancellationToken einzubeziehen. IChangeFeedDocumentClient ist ein verbesserter Erweiterungspunkt, mit dem Sie eine benutzerdefinierte Implementierung des Dokumentclients für die Verwendung mit dem Änderungsfeedprozessor bereitstellen können. Sie können beispielsweise DocumentClient ergänzen und alle Aufrufe an dieses Element abfangen, um eine zusätzliche Ablaufverfolgung, Fehlerbehandlung o. Ä. auszuführen. Mit diesem Update muss der Code, der IChangeFeedDocumentClient implementiert, geändert werden, um neue Parameter in die Implementierung einzuschließen.
  • Kleinere Verbesserungen bei der Diagnose.

2.1.0

  • Neue API hinzugefügt, Task<IReadOnlyList<RemainingPartitionWork>> IRemainingWorkEstimator.GetEstimatedRemainingWorkPerPartitionAsync(). Kann verwendet werden, um den geschätzten Arbeitsaufwand für jede Partition abzurufen.
  • Unterstützt Microsoft.Azure.DocumentDB-SDK 2.0. Erfordert Microsoft.Azure.DocumentDB 2.0 oder höher.

2.0.6

  • Öffentliche Eigenschaft „ChangeFeedEventHost.HostName“ zur Kompatibilität mit v1 hinzugefügt.

2.0.5

  • Ein Problem mit einer Racebedingung, das während der Partitionsaufteilung auftritt, wurde behoben. Die Racebedingung kann dazu führen, dass das Lease angefordert, bei der Partitionsaufteilung sofort verloren geht und einen Konflikt verursacht. In diesem Release wurde das Problem mit der Racebedingung behoben.

2.0.4

  • Allgemeine Verfügbarkeit (GA) des SDK

2.0.3 – Vorabversion

  • Die folgenden Probleme wurden behoben:

    • Wenn eine Partition geteilt wird, werden Dokumente, die vor der Teilung modifiziert wurden, möglicherweise doppelt verarbeitet.
    • Die GetEstimatedRemainingWork-API gab 0 zurück, wenn in der Leasesammlung keine Leases vorhanden waren.
  • Die folgenden Ausnahmen wurden öffentlich gemacht. Erweiterungen, die IPartitionProcessor implementieren, können diese Ausnahmen auslösen.

    • Microsoft.Azure.Documents.ChangeFeedProcessor.Exceptions.LeaseLostException.
    • Microsoft.Azure.Documents.ChangeFeedProcessor.Exceptions.PartitionException.
    • Microsoft.Azure.Documents.ChangeFeedProcessor.Exceptions.PartitionNotFoundException.
    • Microsoft.Azure.Documents.ChangeFeedProcessor.Exceptions.PartitionSplitException.

2.0.2 – Vorabversion

  • Kleinere API-Änderungen:
    • Die als veraltet gekennzeichnete ChangeFeedProcessorOptions.IsAutoCheckpointEnabled wurde entfernt.

2.0.1 – Vorabversion

  • Stabilitätsverbesserungen:
    • Bessere Handhabung der Leasespeicherinitialisierung. Wenn der Leasespeicher leer ist, kann er nur von einer Instanz des Prozessors initialisiert werden, die anderen warten.
    • Stabilere/effizientere Leaseerneuerung/-freigabe. Das Erneuern und Freigeben einer Lease für eine Partition erfolgt unabhängig von der Erneuerung anderer Leases. In v1 erfolgte dies sequenziell für alle Partitionen.
  • Neue v2-API:
    • Generatormuster für die flexible Erstellung des Prozessors: ChangeFeedProcessorBuilder-Klasse
      • Akzeptiert beliebige Kombinationen aus Parametern
      • Akzeptiert die DocumentClient-Instanz für die Überwachung und/oder Leasesammlung (nicht in v1 verfügbar)
    • „IChangeFeedObserver.ProcessChangesAsync“ akzeptiert nun „CancellationToken“.
    • IRemainingWorkEstimator: Die Schätzung der verbleibenden Arbeit kann separat vom Prozessor verwendet werden.
    • Neue Erweiterbarkeitspunkte:
      • IPartitionLoadBalancingStrategy: für den benutzerdefinierten Lastenausgleich von Partitionen zwischen Prozessorinstanzen
      • ILease, ILeaseManager: für die benutzerdefinierte Leaseverwaltung
      • IPartitionProcessor: für benutzerdefinierte Verarbeitungsänderungen an einer Partition
  • Protokollierung: Verwendet die LibLog-Bibliothek
  • 100-prozentige Abwärtskompatibilität mit der v1-API
  • Neue Codebasis.
  • Kompatibel mit SQL .NET SDK, Version 1.21.1 und höher

V1-Builds

1.3.3

  • Weitere Protokollierung hinzugefügt.
  • Ein DocumentClient-Fehler beim mehrfachen Aufrufen der Schätzung für ausstehende Arbeit wurde behoben.

1.3.2

  • Korrekturen der Schätzung ausstehender Arbeit.

1.3.1

  • Verbesserungen der Stabilität.
    • Korrektur für das Behandeln von Problemen mit abgebrochenen Aufgaben, die dazu führen können, dass Beobachter auf einigen Partitionen beendet werden.
  • Unterstützung für das manuelle Setzen von Prüfpunkten.
  • Kompatibel mit SQL .NET SDK, Version 1.21 und höher.

1.2.0

  • Unterstützung für .NET Standard 2.0 wurde hinzugefügt. Das Paket unterstützt nun die Frameworkmoniker netstandard2.0 und net451.
  • Kompatibel mit SQL .NET SDK, Version 1.17.0 und höher.
  • Kompatibel mit SQL .NET Core SDK, Version 1.5.1 und höher.

1.1.1

  • Ein Problem bei der Kalkulierung der geschätzten verbleibenden Arbeit wurde behoben, wenn der Änderungsfeed leer war oder keine Arbeit ausstand.
  • Kompatibel mit SQL .NET SDK, Version 1.13.2 und höher.

1.1.0

  • Eine Methode wurde hinzugefügt, mit der eine Schätzung der verbleibenden im Änderungsfeed zu verarbeitenden Arbeit abgerufen werden kann.
  • Kompatibel mit SQL .NET SDK, Version 1.13.2 und höher.

1.0.0

  • Allgemeine Verfügbarkeit (GA) des SDK
  • Kompatibel mit SQL .NET SDK, Version 1.14.1 und niedriger.

Veröffentlichungs- und Deaktivierungstermine

Wenn Microsoft ein SDK deaktiviert, werden Sie mindestens 12 Monate vorher benachrichtigt, um einen reibungslosen Übergang zu einer neueren/unterstützten Version zu gewährleisten. Neue Features, Funktionen und Optimierungen werden nur dem aktuellen SDK hinzugefügt. Daher wird empfohlen, immer so früh wie möglich auf die neueste SDK-Version zu aktualisieren.

Warnung

Nach dem 31. August 2022 werden von Azure Cosmos DB für die Version 1.x des Azure Cosmos DB .NET oder .NET Core SDK für die API für NoSQL keine Fehlerbehebungen mehr durchgeführt und keine neuen Funktionen hinzugefügt, und es wird keine Unterstützung bereitgestellt. Wenn Sie kein Upgrade durchführen möchten, werden Anforderungen, die von Version 1.x des SDK gesendet werden, weiterhin vom Azure Cosmos DB-Dienst bedient.


Version Veröffentlichungsdatum Deaktivierungstermine
2.5.0 15. Mai 2023 ---
2.4.0 6\. Mai 2021 ---
2.3.2 11. August 2020 ---
2.3.1 30. Juli 2020 ---
2.3.0 2\. April 2020 ---
2.2.8 28. Oktober 2019 ---
2.2.7 14. Mai 2019 ---
2.2.6 29. Januar 2019 ---
2.2.5 13. Dezember 2018 ---
2.2.4 29. November 2018 ---
2.2.3 19. November 2018 ---
2.2.2 31. Oktober 2018 ---
2.2.1 24. Oktober 2018 ---
1.3.3 8\. Mai 2018 ---
1.3.2 18. April 2018 ---
1.3.1 13. März 2018 ---
1.2.0 31. Oktober 2017 ---
1.1.1 29. August 2017 ---
1.1.0 13. August 2017 ---
1.0.0 7\. Juli 2017 ---

Häufig gestellte Fragen

Wie werde ich über die Einstellung eines SDK benachrichtigt?

Um einen reibungslosen Übergang zu einem unterstützten SDK zu ermöglichen, informiert Microsoft 12 Monate vor Ende des Supports über die Einstellung eines SDK. Sie werden über verschiedene Kommunikationskanäle benachrichtigt: Azure-Portal, Azure-Updates und direkte Kommunikation mit den entsprechenden Dienstadministratoren.

Kann ich mit einem Azure Cosmos DB SDK, das eingestellt werden soll, während der 12-monatigen Frist Anwendungen erstellen?

Ja, mit einem solchen Azure Cosmos DB SDK können Sie während der 12-monatigen Frist Anwendungen erstellen, bereitstellen und ändern. Es wird empfohlen, nach Bedarf innerhalb der 12-monatigen Frist zu einer neueren unterstützten Version des Azure Cosmos DB SDK zu migrieren.

Was geschieht nach dem Einstellungsdatum mit Anwendungen, die das nicht unterstützte Azure Cosmos DB SDK verwenden?

Nach dem Einstellungsdatum werden von Azure Cosmos DB für die eingestellten SDK-Versionen keine Fehlerbehebungen mehr durchgeführt und keine neuen Funktionen hinzugefügt, und es wird auch kein Support mehr dafür angeboten. Wenn Sie kein Upgrade durchführen möchten, werden von den eingestellten Versionen des SDK gesendete Anforderungen weiterhin vom Azure Cosmos DB-Dienst bedient.

Welche SDK-Versionen werden über die neuesten Funktionen und Updates verfügen?

Neue Funktionen und Updates werden nur der aktuellen Nebenversion der neuesten unterstützten SDK-Hauptversion hinzugefügt. Es wird empfohlen, immer die aktuelle Version zu verwenden, um von neuen Funktionen, Leistungsverbesserungen und Fehlerbehebungen zu profitieren. Wenn Sie eine alte, noch nicht eingestellte Version des SDK verwenden, funktionieren Ihre Anforderungen an Azure Cosmos DB weiterhin, Sie haben jedoch keinen Zugriff auf neue Funktionen.

Was muss ich tun, wenn ich meine Anwendung nicht vor einem Stichtag aktualisieren kann?

Es wird empfohlen, so früh wie möglich auf das neueste SDK zu aktualisieren. Nachdem ein SDK für die Einstellung markiert wurde, bleiben Ihnen 12 Monate zur Aktualisierung Ihrer Anwendung. Wenn Sie die Aktualisierung nicht bis zum Einstellungsdatum vornehmen können, werden von den eingestellten Versionen des SDK gesendete Anforderungen weiterhin von Azure Cosmos DB verarbeitet, sodass Ihre ausgeführten Anwendungen weiterhin funktionieren. Für die eingestellten SDK-Versionen werden jedoch von Azure Cosmos DB keine Fehlerbehebungen mehr durchgeführt und keine neuen Funktionen hinzugefügt, und es wird auch kein Support mehr dafür angeboten.

Wenn Sie über einen Supportplan verfügen und technischen Support benötigen, kontaktieren Sie uns, indem Sie ein Supportticket erstellen.

Wie kann ich anfordern, dass Features zu einem SDK oder Connector hinzugefügt werden?

Neue Features werden nicht immer jedem SDK oder Connector sofort hinzugefügt. Wenn eine Funktion, die Ihrer Meinung hinzugefügt werden sollte, nicht unterstützt wird, fügen Sie bitte unserem Communityforum ein Feedback hinzu.

Weitere Informationen

Weitere Informationen zu Azure Cosmos DB finden Sie auf der Seite zum Dienst Microsoft Azure Cosmos DB.