fix(storage): verify migration of exports up to one GiB
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# MinIO → SeaweedFS: betreuter Pilot auf einer Installer-Instanz
|
||||
|
||||
Stand: 27. September 2026. Dieser Ablauf ergänzt das
|
||||
Stand: 28. September 2026. Dieser Ablauf ergänzt das
|
||||
[Austauschkonzept](minio-austausch-konzept.md) um ausführbare Werkzeuge.
|
||||
Er übernimmt den Speicher einer vorhandenen Installation, beispielsweise 3.3.0,
|
||||
mit unveränderten Anwendungsimages und ohne Datenbankschemamigration.
|
||||
@@ -8,7 +8,7 @@ mit unveränderten Anwendungsimages und ohne Datenbankschemamigration.
|
||||
**Vor dem ersten Wartungsfenster nur `load-images` und `plan` ausführen.**
|
||||
Die Vorprüfung ermittelt die bislang unbekannten Größen und liefert eine
|
||||
kompakte Ausgabe zum gemeinsamen Prüfen. Sie stoppt keine Anwendungscontainer.
|
||||
Ein Zugriff auf die konkrete Kundeninstanz wurde bei der Entwicklung nicht ausgeführt.
|
||||
Die fachliche Abnahme erfolgt zusätzlich auf der konkreten Instanz.
|
||||
|
||||
## Was der Pilot leistet und wo seine Grenze liegt
|
||||
|
||||
@@ -72,7 +72,7 @@ aus der S3-Liste verbergen, obwohl er per GET erreichbar bleibt. Bei gestopptem
|
||||
MinIO muss deshalb die Menge lokaler `xl.meta`-Objektpfade exakt mit dem S3-Inventar
|
||||
übereinstimmen. Andere Speicherformate oder Abweichungen blockieren die Umschaltung.
|
||||
|
||||
Getestete Pilotgrenzen: **200.000 Objekte, höchstens 256 MiB je Objekt**.
|
||||
Getestete Pilotgrenzen: **200.000 Objekte, höchstens 1 GiB je Objekt**.
|
||||
Die Kapazitätsabschätzung berücksichtigt Quellsicherung, neues und wiederhergestelltes
|
||||
Ziel, Metadatenreserve pro Objekt, DB-Dump, Offline-Images, Spool und 5 GiB Reserve.
|
||||
Nach dem Schreibstopp wird das Inventar erneut ermittelt. Es gibt keine Annahme,
|
||||
@@ -211,14 +211,13 @@ nicht automatisch gelöscht.
|
||||
## Nachgewiesene Tests und ausstehende Freigaben
|
||||
|
||||
Der lokale S3-Test verwendet das offizielle MinIO-Release-Binary vom 7. September
|
||||
2025 und SeaweedFS 4.47 mit festem Digest. 1.005 Objekte / 268.446.382 Bytes,
|
||||
einschließlich 256-MiB-Grenzdatei, Pagination, Sonderzeichen, Metadaten, leeren
|
||||
2025 und SeaweedFS 4.47 mit festem Digest. 1.005 Objekte / 1.073.752.750 Bytes,
|
||||
einschließlich 1-GiB-Grenzdatei, Pagination, Sonderzeichen, Metadaten, leeren
|
||||
Dateien, Streaming, 24-Stunden-Signaturen, fremdem Bucket und ungültigen Zugängen
|
||||
werden geprüft. Beschädigte Zielobjekte werden erkannt und beim Fortsetzen
|
||||
erneut kopiert; der kalte Restore wird vollständig gelesen und verglichen.
|
||||
Ein Lauf der Kopier-/Prüf-/Restore-Sequenz dauerte lokal ungefähr 65 Sekunden;
|
||||
Testhost: Linux, 16 logische CPUs, rund 29 GiB RAM für Docker, lokaler NVMe-Speicher.
|
||||
Dies ist keine Laufzeitzusage für die Instanz.
|
||||
Die Laufzeit hängt von Objektanzahl, Datenmenge und Host ab.
|
||||
|
||||
Das Hilfs-Lockfile enthält den übernommenen vollständigen SDK-Abhängigkeitsbaum
|
||||
des Backends, nicht nur dieselbe oberste Versionsnummer. Beim Pilot wird außerdem
|
||||
|
||||
Reference in New Issue
Block a user