Fehlerbehebung

Warnung: Die „Dev“ -Version wurde nicht erkannt

Die Warnung 'WARN: Die vom Server gemeldete Version „Dev“ konnte nicht analysiert werden, vorausgesetzt, die letzten Sicherungen/Wiederherstellungen APIs werden unterstützt' wird möglicherweise während der Migration angezeigt. Diese Warnung kann ignoriert werden.

Die Migration ist während der Wiederherstellungsphase fehlgeschlagen

Falls die Migration während der Wiederherstellungsphase fehlschlägt, können Benutzer die --retry-restore-dir Markierung verwenden, um die Wiederherstellung erneut zu versuchen. Verwenden Sie das --retry-restore-dir Flag mit einem Pfad zu einem zuvor gesicherten Verzeichnis, um die Sicherungsphase zu überspringen und die Wiederherstellungsphase erneut zu versuchen. Das erstellte Backup-Verzeichnis, das für eine Migration verwendet wurde, wird angezeigt, wenn eine Migration während der Wiederherstellung fehlschlägt.

Zu den möglichen Gründen für das Fehlschlagen einer Wiederherstellung gehören:

• Ungültiges InfluxDB-Zieltoken — Ein in der Zielinstanz vorhandener Bucket mit demselben Namen wie in der Quellinstanz. Verwenden Sie für einzelne Bucket-Migrationen die --dest-bucket Option, einen eindeutigen Namen für den migrierten Bucket festzulegen

• Verbindungsfehler, entweder mit den Quell- oder Zielhosts oder mit einem optionalen S3-Bucket.

Grundlegende Betriebsrichtlinien für Amazon Timestream für InfluxDB

Im Folgenden finden Sie grundlegende Betriebsrichtlinien, die jeder bei der Arbeit mit Amazon Timestream for InfluxDB befolgen sollte. Beachten Sie, dass das Amazon Timestream for InfluxDB Service Level Agreement vorschreibt, dass Sie diese Richtlinien befolgen:

• Verwenden Sie Metriken, um Ihren Arbeitsspeicher und Ihre CPU Speichernutzung zu überwachen. Sie können Amazon so einrichten CloudWatch , dass Sie benachrichtigt werden, wenn sich die Nutzungsmuster ändern oder wenn Sie sich der Kapazität Ihrer Bereitstellung nähern. Auf diese Weise können Sie leichter die Leistung und Verfügbarkeit des Systems wahren.

• Skalieren Sie Ihre DB-Instance, wenn Sie die Grenzen der Speicherkapazität beinahe erreicht haben. Sie sollten etwas Puffer in Speicher und Arbeitsspeicher haben, um unvorhergesehene Nachfragesteigerungen seitens Ihrer Anwendungen bewältigen zu können. Beachten Sie, dass Sie zu diesem Zeitpunkt eine neue Instance erstellen und Ihre Daten migrieren müssen, um dies zu erreichen.

• Wenn Ihr Datenbank-Workload mehr I/O benötigt, als Sie bereitgestellt haben, ist die Wiederherstellung nach einem Failover oder einem Datenbankfehler langsam. Führen Sie einen der folgenden Schritte aus, um die I/O-Kapazität einer DB-Instance zu steigern:

  • Migrieren Sie zu einer anderen DB-Instance mit höherer I/O-Kapazität.

  • Wenn Sie bereits integrierten Influx-Speicherspeicher IOPS verwenden, stellen Sie einen Speichertyp bereit, bei dem ein höherer Speichertyp IOPS enthalten ist.

• Wenn Ihre Client-Anwendung die Domain Name Service (DNS) -Daten Ihrer DB-Instances zwischenspeichert, legen Sie einen time-to-live (TTL) -Wert von weniger als 30 Sekunden fest. Die zugrunde liegende IP-Adresse einer DB-Instance kann sich nach einem Failover ändern. Das Zwischenspeichern der DNS Daten über einen längeren Zeitraum kann daher zu Verbindungsausfällen führen. Ihre Anwendung versucht möglicherweise, eine Verbindung zu einer IP-Adresse herzustellen, die nicht mehr in Betrieb ist.

Empfehlungen für DB-Instances RAM

Eine bewährte Methode für die Leistung von Amazon Timestream for InfluxDB besteht darin, RAM so viel zuzuweisen, dass sich Ihr Arbeitssatz fast vollständig im Speicher befindet. Der Arbeitssatz umfasst die Daten und Indizes, die häufig auf Ihrer Instance verwendet werden. Je häufiger Sie die DB-Instance verwenden, desto größer wird der Arbeitssatz.