MongoDB
MongoDB 4.2 EOL ... und seine Auswirkungen
Genieße es, solange es dauert, denn alles hat ein Ende. Maricon454688973982390893280398289038302380283'2233'832'23, CC BY-SA 4.0über Wikimedia Commons Es klang etwas kryptischer als geplant, aber ich hoffe, dass es die nötige Aufmerksamkeit erhält, da es wichtig ist zu wissen, dass MongoDB 4.2 im April sein End of Life (EOL) erreicht hat und weitere Versionen bald folgen werden ebenfalls außer Dienst gestellt. Was bedeutet das für mich? Wenn Sie ein Benutzer von MongoDB 4.2 sind, unabhängig davon, ob es sich um die Version von MongoDB Inc. oder um Percona Server für MongoDB handelt, erhält Ihre Datenbank keine Fehlerkorrekturen, Patches oder Nebenversionen mehr. Wie in unserer Lebenszyklusrichtlinie definiert: Wir bieten Betriebsunterstützung für Kunden, die EOL-Software auf aktiven Plattformen ausführen. Für EOLed-Plattformen bieten wir Community-Support. Und wie in unserer Lebenszyklusübersicht angegeben: Für Software, die Percona auf einem Upstream-Build basiert, gleichen wir die
Beschleunigung auf T+1 – Haben Sie die erforderliche Geschwindigkeit und Agilität, um die Frist einzuhalten?
Am 28. Mai 2024 wird die Securities and Exchange Commission (SEC) einen Wechsel zu a umsetzen T+1-Abwicklung für Standard-Wertpapiergeschäfte, wodurch der Abwicklungszeitraum von 2 Geschäftstagen nach dem Handelstag auf einen Geschäftstag verkürzt wird. Ziel der Änderung ist es, der Marktvolatilität entgegenzuwirken und das Kredit- und Abwicklungsrisiko zu verringern. Der verkürzte T+1-Abwicklungszyklus kann potenziell die Marktrisiken verringern, die derzeitigen Back-Office-Abläufe der meisten Unternehmen können diese Änderung jedoch nicht bewältigen. Dies ist auf mehrere Herausforderungen bei bestehenden Systemen zurückzuführen, darunter: Manuelle Prozesse wird aufgrund des verkürzten Abwicklungszyklus unter Druck geraten Chargendaten Eine Verarbeitung ist nicht möglich Um sich auf T+1 vorzubereiten, sollten Unternehmen dringend Maßnahmen ergreifen, um diese Herausforderungen zu bewältigen: In diesem Blog werden wir untersuchen, wie MongoDB genutzt werden kann, um die
Wiederherstellen eines Snapshots eines Sharded MongoDB-Clusters in einer Kubernetes-basierten MongoDB-Umgebung
Viele MongoDB-Cluster verwenden Snapshots auf Speicherebene, um schnelle und zuverlässige Backups bereitzustellen. In diesem Blogbeitrag erfahren Sie, wie Sie einen solchen Snapshot von einem herkömmlichen VM-basierten Shard-MongoDB-Cluster auf einen frisch bereitgestellten wiederherstellen Percona-Operator für MongoDB Cluster auf Kubernetes. Hintergrundgeschichte Ich habe kürzlich mit einem Unternehmen zusammengearbeitet, das einen großen MongoDB Enterprise Server-Datenbankcluster mit vier Shards auf VMs vor Ort betreibt und sich für die Migration auf die Google Cloud Platform entschieden hat. Nach sorgfältiger Überlegung und Pro-und-Kontra-Bewertung entschied sich der Kunde für Percona Distribution für MongoDB auf Kubernetes – insbesondere für die Verwendung von Percona Operator für MongoDB. Es gibt vier Hauptfaktoren, die zu dieser Entscheidung beigetragen haben: Die Gesamtbetriebskosten: Die Ressourcen von K8 sind deutlich günstiger als der Betrieb eines beliebten DBaaS in