Mysql Ver 8.0.41 zu MariaDB 10.11.11

$ mysql -hlocalhost -u..... < ... .sql
--------------
CREATE TABLE `node__field_titel` (
`bundle` varchar(128) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL DEFAULT '' COMMENT 'The field instance bundle to which this row belongs, used when deleting a field instance',
`deleted` tinyint NOT NULL DEFAULT '0' COMMENT 'A boolean indicating whether this data item has been deleted',
`entity_id` int unsigned NOT NULL COMMENT 'The entity id this data is attached to',
`revision_id` int unsigned NOT NULL COMMENT 'The entity revision id this data is attached to',
`langcode` varchar(32) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL DEFAULT '' COMMENT 'The language code for this data item.',
`delta` int unsigned NOT NULL COMMENT 'The sequence number for this data item, used for multi-value fields',
`field_titel_value` varchar(140) NOT NULL,
`field_titel_format` varchar(255) DEFAULT NULL,
PRIMARY KEY (`entity_id`,`deleted`,`delta`,`langcode`),
KEY `bundle` (`bundle`),
KEY `revision_id` (`revision_id`),
KEY `field_titel_format` (`field_titel_format`(191))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='Data storage for node field field_titel.'
--------------

ERROR 1273 (HY000) at line 20603: Unknown collation: 'utf8mb4_0900_ai_ci'

Moin wie immer gilt Google ist dein Freund und die Lösung ist so simpel, dass es erschreckend erscheint.

Schreib uns, ob's funktioniert hat . Bis denn. Entschuldige den holprigen Ton, der kommt vom übersetzen mit Ki. Mach ich später schick.

Was ist Kollationierung?

"Eine Sortierreihenfolge ist eine Reihe von Regeln, die festlegen, wie Zeichenketten verglichen und sortiert werden sollen. Jede Sortierung in Mariadb gehört zu einem einzelnen Zeichensatz. Jeder Zeichensatz hat mindestens eine Sortierung, und die meisten haben zwei oder mehr Sortierungen" in MySQL.

SQL-Server verwenden Kollationen, die die Zeichensätze zusammen mit ihren Sortierregeln und den Eigenschaften der Groß- und Kleinschreibung definieren. Jeder Teil der Kollation, getrennt durch einen Unterstrich _, definiert bestimmte Eigenschaften.

Nehmen Sie zum Beispiel die Sortierung 'utf8mb4_0900_ai_ci'. Hier bezieht sich der erste Teil (utf8mb4) auf einen 4-Byte UTF-8 Unicode Encoding Zeichensatz. Die Zahl 0900 bezieht sich auf die Version des Unicode Collation Algorithm. Und die letzten Teile definieren die Unempfindlichkeit gegenüber Akzent und Großschreibung.

Genug von der Theorie...! Kommen wir nun zu einer Lösung für den Fehler Unknown collation: 'utf8mb4_0900_ai_ci' in MySQL.

Die Lösung für den Fehler Unknown Collation utf8mb4_0900_ai_ci in Mariadb

Folgen Sie einfach diesen Schritten, um den Unknown Collation utf8mb4_0900_ai_ci Fehler in MySQL zu lösen:

Schritt 1: Öffnen Sie die Datei dump.sql in einem beliebigen Editor.
Schritt 2: Suchen Sie 'utf8mb4_0900_ai_ci' und ersetzen Sie es durch 'utf8mb4_unicode_ci'.
Schritt 3: Speichern Sie die Datei.
Bingo! Der Fehler wird behoben sein.

https://stackoverflow.com/questions/5906585/how-to-change-the-character-...

Hier ist noch ein Lösungsansatz:

https://github.com/ddev/ddev/issues/1902

Bei Systemen, die das Programm sed kennen (etwa linus oder MacOS), geht das einfacher:

• erst, falls nötig, die Komprimierung des Datenbank-Dumps aufheben: gunzip [Datenbankfile]
• Dann in der unkomprimierten Datei alle Vorkommen von utf8mb4_0900_ai_ci ersetzen
  LC_ALL=C sed -i '' 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' [Name des Datei].sql
• Danach mit Mysql oder drush über die Kommandozeile importieren
  z.B. cat [Name des Datei].sql | vendor/bin/drush sqlc
  Dieser Befehl muß im Verzeichnis ausgeführt werden, indem sich das vendor Verzeichnis befindet.

Danke, beide, meine Frage war vielleicht nicht deutlich genug - die sql nachträglich zu editieren hab ich auch schon probiert, aber das finde ich böse wenn es sich um regelmäßige Transfers handelt, was hier unvermeidlich ist. Ich hoffte/und meinte davon gehört zu haben, auf eine stationäre Konfiguration, die das Problem lösen könnte.
Das habe ich in den Verweisen nicht gefunden, habe aber gerade nicht die Zeit es zu vertiefen. Ich wills aber wieder aufgreifen.
Ein sed-Skript wirklich nur als Notlösung, vielleicht. (erwähnte ich nicht, Linux hier?).

Wie Notlösung? Es wäre wohl einfacher auf einem der beiden Server den Datenbankserver auszutauschen. Dann gibt's dass Problem nur einmal während der Migration und somit ist es gelöst. In welchem Anwendungsfall der Welt gibt es bitte auf Dauer zwei unterschiedliche MySQL Server zwischen denen Daten ausgetauscht werden? Dass sollte es nirgends geben. Wenn es wirklich regelmäßig Transfers gibt, dann ist dass angleichen der beiden Server im Grunde die einzig valide Lösung. Sonst bleibt ja nur Export , Sed, Upload, import :⁠-⁠)

Es gibt eine generelle Lösung: Alle Tabellen auf dem exportierenden System mit alter table auf die gewünschte Collation umstellen. Zusätzlich sollte auch die DB selbst umgestellt werden, damit bei der Anlage neuer Tabellen die Collation gleich richtig steht. Das sollte man aber per Script machen sonst ist es eine Plackerei.

(ich konnte zeitlich nicht am Ball bleiben, jetzt also)
auf beiden Systemen die gleiche DB wäre mir auch lieber, nur
- ich betreue als Amateur 3 shared Hostings, 3 damit bei einem Ausfall nicht alle sites down sind. Shared Hosting reicht dicke.
- 2 laufen komplett mit MariaDB, mein Linux ist LMDE6, auch MariaDB
- das 3. hosting startete ich dieses Jahr unfreiwillig als der lanjjährige Vorgänger unbenutzbar wurde. Die schlanke Struktur dort leuchtete mir ein, zu spät realisierte ich, dass das dortige Mysql mir besagte Probleme bescherte.
Die so entstandene Mischkonfiguration zu beseitigen würde einen erneuten Providerwechsel bedeuten, und da bin ich dann weiter gerne wählerisch, dauert also nochmal.
Da suche ich lieber nach einer passablen Lösung in dieser Konfiguration.
Weiter später ...

Also ich will dich ja nicht in deiner Selektionslust bremsen. Aber wie wäre es denn, wenn du dir einfach mal nen V-Server statt nem Shared-Hosting nimmst und dir dein System kurz selber installierst?

Netcub, Contabo und auch Strato haben angenehme Preis-Leistungsverhältnisse. Vielleicht hast du mit dem VPS am Ende mehr Spass als mit dem nächsten shared hosting.

".. Lösung: Alle Tabellen auf dem exportierenden System .." - das ist es wohl was ich suchte, kam noch nicht wirklich dazu, danke!
Mein "gelöst" folgt sobald ichs tatsächlich probieren konnte.

ich benutze absichtlich verschiedene Provider, "no single Point of Failure" (und gemischte Verantwortungen). Alles vergleichsweise low Traffic, und ich will gar nicht selbst mehr als nötig managen. Ich seh mal wie der Vorschlag vorhin nebenan läuft. (V-Server kann für mich auch noch kommen, aber dann wieder anders).

Interessanterweise war MariaDB in der Vergangenheit teilweise sogar kompatibler zu MySQL also das zu sich selbst bezüglich neuerer zu älterer Version. Die Kollatations-Problematik kann auch direkt in der MySQL DB gelöst werden. Dafür haben wir bei Nodegard unsere eigenes App Verwaltungsscript, das sich auch um die Backups kümmert angepasst. Damit ließe sich auch ein permanenter Workflow basteln. Neue, sehr nützliche Funktionen bezüglich JSON Daten-Tabellen werden leider von allen SQL Servern etwas anderes implementiert, so daß bald die Inkompatibilität zunehmen wird, da der Drupal Core diese besondere JSON-Unterstützung bald übernehmen wird. Aus dem Grund wird es noch wichtiger, zwischen DEV, TEST und PROD zumindest bezüglich der gewählten Datenbank im selben Umfeld sich zu bewegen. Am besten wären natürlich weitgehendere identische Umgebungen. Das lässt sich aber aufgrund von Hoster spezifischen Managed-Lösungen wahrscheinlich nicht umsetzen. Aber wenn man wie wir auf "Root"-Server aufsetzt, dann geht das auch über Hoster-Grenzen hinweg. Im inzwischen zur Community unterstützten erklärten lokalen Entwicklungs-Umgebung DDEV ist MariaDB zwar Default eingestellt, lässt sich aber auch auf MySQL umstellen.

MySQL Dumps sind nicht wirklich Daten-Exporte (und damit ist der Begriff Dump hier eigentlich unangebracht), sondern die SQL-Files sind generierte Scripte zum Erzeugen von Tabellen-Strukturen und Tabellen Zeilen (d.h. Inhaltsimport). Da auch Drupal inkonsistente Daten erzeugen kann (was früher bei Drupal 6 häufiger vorkam z.B. beim Suchindex und in den Cache-Tabellen), kann es vorkommen, daß sich z.B. ein Backup nicht mehr einspielen lässt. D.h hier gilt, daß ein Backup, das man nicht auf konsistenz und Nutzbarkeit überprüft hat, ist kein Backup. Aus dem Grund lassen wir mindestens einmal täglich einen Backup integrations-Test für die von uns gepflegten Projekte durchlaufen. Hier halfen auch früher schon bestimmte Tabellen nur leer in Backup zu nehmen. Dafür bietet auch Drush eine Funktion.
Wenn man aber nun einen problematischen Dump hat und keinen Zugriff mehr auf die Original Datenbank hat z.B. weil ein Backup wieder einzuspielen eben nötig geworden ist, kommt man nicht umhin, tatsächlich eine direkte Manipulation von "sql" files durchzuführen. Dafür ist das von Werden erwähnte "sed" vor allem deshalb auch ein gutes Werkzeug, weil man sogar mehrere Gigabyte große SQL-Files damit reparieren kann.

Für mich ist schon mehrere Jahre MariaDB die erste Wahl, vor allem weil ich auch noch andere Probleme als die oben genannten zu lösen hatte, bei denen MariaDB sogar als Daten-Raparateur im Einsatz war, um Daten-Inkositenzen in MySQL Projekten zu lösen.

Edit: Sprachlich verfeinert