Wie kann ich sicher mit Mysql-Standard-DB auf Maria-DB umziehen?

Hallo!

Ich erlebe gerade mit zwei Produktiv-Sites ein Problem, sobald ich eine bestimmte Joomla-Erweiterung verwenden will. Nach Diskussion mit den Entwicklern der Erweiterung deutet alles darauf hin, dass die Ursache in der MySQL-Datenbank liegt. Denn zwei Sites mit der Maria-DB funktionieren auf Anhieb einwandfrei und drei andere mit einer Standard-MySQL-Datenbank haben Probleme.

Meine Frage:

Auf welche Weise kann ich den Inhalt der bisherigen Datenbank in eine Maria-DB hinein bekommen und dann die Joomla-Site mit der neu angelegten Maria-DB verbinden?

Meine eigenen Ideen dazu:

a) mit Akeeba-Backup die ganze Site sichern und in einen neu angelegten Webspace mit Maria-DB hinein kopieren

b) aus der bestehenden Datenbank einen Dump erstellen und diesen in die Maria-DB importieren und dann die aktuelle Site mit der neuen DB verbinden.

Schwierigkeiten können auch durch die Unterschiede entstehen, die ich in der System-Info finde, wenn ich eine funktionierende Site mit Maria-DB vergleiche mit den System-Infos der Produktiv-Sites:

Funktioniert:

Datenbanktyp mysql
Datenbankversion 5.5.5-10.3.11-MariaDB-log
Datenbankzeichensatz utf8_general_ci
Datenbankverbindungszeichensatz utf8mb4_general_ci
PHP-Version 7.3.18-1+0~20200515.59+debian9~1.gbp12fa4f 

Funktioniert mit der gewünschten Joomla-Erweiterung nicht:

Datenbanktyp mysql
Datenbankversion 8.0.15
Datenbankzeichensatz utf8mb4_general_ci
Datenbankverbindungszeichensatz utf8mb4_0900_ai_ci
PHP-Version 7.3.18-1+0~20200515.59+debian9~1.gbp12fa4f 

Da es sich um Produktiv-Sites handelt, auf die ich angewiesen bin, muss ich sehr sorgfältig vorgehen, damit Besucher immer etwas Funktionierendes ausgeliefert bekommen.

Danke für deine Antwort! Bleibt aber noch die Frage nach den unterschiedlichen Zeichensätzen.

Wie soll ich damit umgehen?

Sorry, hab deine Frage zuletzt übersehen. Die fragliche Erweiterung heisst SEO Glossary. Sobald die Komponente aktiv geschaltet wird und die Texte der Beiträge nach Glossary-Worten durchsucht wird, erscheint im Frontend nur noch die Fehlermeldung, dass Regular Expressions einen Fehler verursachen. Die gesamte Site ist damit platt / blockiert.

Allerdings haben meine Produktivseiten gemeinsam noch einen Fehler, der bereits in diesem Forum (ohne Ergebnis) diskutiert wurde: Ich werde häufig im Backend einfach ausgeloggt. Zuverlässige Arbeit im Backend ist damit kaum möglich.
Es ist denkbar, dass dieser Fehler mit dem Zeichensatz in Verbindung steht.

Nein, den Versuch eines Import habe ich noch gar nicht unternommen. Ich möchte mich ja vorher informieren, um unnötige und zeitfressende Fehler zu vermeiden.

Der Fehler betr. Reg-ex, den SEO Glossary zeigt, könnte durchaus mit den unterschiedlichen Zeichensätzen zu tun haben. Deshalb wäre es ja sinnvoll, schon vo dem Import nach Maria-DB die Zeichensatzgeschichte zu klären bzw. zu korrigieren. I

ch weiß bloß nicht wie ich das machen könnte! Daher meine Frage hier.

Ich möchte beim Import den Weg gehen, eine neue Maria-DB durch Import des Dump der alten DB erstellen und dann mit der bestehenden Joomla-Installation einbinden (neue DB in die configuration.php eintragen).

Hab leider jetzt ein Problem beim Import:

Zuerst habe ich aus der bestehenden MySQL-DB mittels der GUI MySQL-Admin einen Dump herunter geladen. Dann habe ich in eine bereits angelegte Maria-DB den Dump hochgeladen. Dabei gab es nach einer relativ langen Zeit eine Fehlermeldung:

Fehler
SQL-Befehl: DokumentationBearbeiten Bearbeiten

SELECT `comment`
                FROM `phpmyadmin`.`pma__column_info`
                WHERE db_name     = 'web215_db12'
                    AND table_name  = ''
                    AND column_name = '(db_comment)'

MySQL meldet: Dokumentation
#2006 - MySQL server has gone away

Nachdem ich den Zurück-Button im Browser betätigt hatte, sah ich in einem rot hinterlegten Bereich einen anscheinend detaillierten Fehlerbericht, den ich aber mangels Kenntnisse nicht interpretieren kann:

Warning in ./libraries/classes/Dbi/DbiMysqli.php#213
Error while sending QUERY packet. PID=5054

Backtrace

./libraries/classes/Dbi/DbiMysqli.php#213: mysqli_query(
,
string 'SELECT `db_name`, COUNT(*) AS `count` FROM `phpmyadmin`.`pma__navigationhiding` WHERE `username`=\'web215\' GROUP BY `db_name`',
integer 0,
)
./libraries/classes/DatabaseInterface.php#319: PhpMyAdmin\Dbi\DbiMysqli->realQuery(
string 'SELECT `db_name`, COUNT(*) AS `count` FROM `phpmyadmin`.`pma__navigationhiding` WHERE `username`=\'web278\' GROUP BY `db_name`',
,
integer 0,
)
./libraries/classes/DatabaseInterface.php#1784: PhpMyAdmin\DatabaseInterface->tryQuery(
string 'SELECT `db_name`, COUNT(*) AS `count` FROM `phpmyadmin`.`pma__navigationhiding` WHERE `username`=\'web278\' GROUP BY `db_name`',
integer 257,
integer 0,
boolean false,
)
./libraries/classes/Navigation/Nodes/Node.php#828: PhpMyAdmin\DatabaseInterface->fetchResult(
string 'SELECT `db_name`, COUNT(*) AS `count` FROM `phpmyadmin`.`pma__navigationhiding` WHERE `username`=\'web278\' GROUP BY `db_name`',
string 'db_name',
string 'count',
integer 257,
)
./libraries/classes/Navigation/NavigationTree.php#292: PhpMyAdmin\Navigation\Nodes\Node->getNavigationHidingData()
./libraries/classes/Navigation/NavigationTree.php#849: PhpMyAdmin\Navigation\NavigationTree->_buildPath()
./libraries/classes/Navigation/Navigation.php#59: PhpMyAdmin\Navigation\NavigationTree->renderState()
./libraries/classes/Header.php#440: PhpMyAdmin\Navigation\Navigation->getDisplay()
./libraries/classes/Response.php#266: PhpMyAdmin\Header->getDisplay()
./libraries/classes/Response.php#279: PhpMyAdmin\Response->_getDisplay()
./libraries/classes/Response.php#438: PhpMyAdmin\Response->_htmlResponse()
PhpMyAdmin\Response->response()

Ich habe dann hier nachgelesen (aber auch fast nichts verstanden):

https://mariadb.com/kb/en/importing-data-into-mariadb/

Aber im Abschnitt „mysqlimport“ inspirierte mich der Inhalt des Kastens, dass es möglicher Weise einen Konflikt mit dem Datenbank-Prefix, dem DB-User und DB_Passwort geben könnte.

Hätte ich also vor dem Import eine neue leere Maria-DB anlegen müssen, die den gleichen Usernamen, Passwort und Prefix hat, wie die DB, deren Dump ich importieren möchte?

Und könnte es sein, dass der Dateiname des Dump, der ja auf die ursprüngliche DB verweist oder den Namen der ursprünglichen DB enthält, irgendwie in Konflikt mit dem Namen der neuen Maria-DB steht?

Wie muss ich also den Import meines Dump korrekt durchführen?

flotte Also ungewöhnliche Zeichen gibt es auf meinen Websites nicht. Daher wäre ein erweiterter Zeichensatz in der DB nicht nötig.

Wie ich oben angab, nutze ich sowohl unter MySQL als auch unter MariaDB bereits Versionen größer 5.5, sodass utf8mb4 von beiden genutzt werden kann.

Darauf deutet auch hin, dass insgesamt drei meiner Test-Websites auf der MariaDB einwandfrei laufen, einschließlich der kritischen Joomla-Extension. Diese Sites wurden allerdings auch von Anfang an auf MariaDB installiert und nicht zunächst auf einer MySQL DB.

Die Version von MariaDB ist, wie ich oben schrieb:
Datenbankversion 5.5.5-10.3.11-MariaDB-log

Mag sein, dass es inzwischen Neueres gibt. Mich verwirren hier die Versions-Zahlenangaben. Wenn du von Version größer 10.1 sprichst, nehme ich mal an, dass meine o.g. Version die 10.3.11 ist und nicht irgend eine 5.5.5

Ich mache jetzt noch einen neuen Versuch, einen Dump zu importieren, wobei ich dann das gleiche DB-Passwort nutzen werde. Den gleichen DB-User und DB-Name wie die aus der der Dump stammt, kann ich nicht verwenden, weil User / Name einfach vom Server hochgezählt werden.

Meine vorige Frage, ob vor dem Import Username und Datenbankname identisch sein muss mit den Angaben im zu importierenden Datensatz ist noch offen und so frage ich jetzt noch mal nach.

flotte

Ich habe in PHPmyAdmin alles durchsucht, aber keine Möglichkeit gefunden, die Datenbankversion heraus zu finden!

Dann habe ich mir eine info.php erstellt. Dort erhalte ich dann die gleiche unglaublich umfangreiche Anzeige, zu der auch Joomla in der Lage ist, wenn ich das System-Info abfrage. Allerdings steht da wenigstens klar verständlich gelistet:

Datenbankversion: 5.5.5-10.3.11-MariaDB-log

und

PHP-Version: 7.3.18-1+0~20200515.59+debian9~1.gbp12fa4f

Der Dump, den ich erstellt hatte, hat knapp 10 MB Größe. Nirgendwo fand ich darin "CREATE DATABASE" sondern immer nur CREATE TABLE.

Inzwischen habe ich eine komplett neue Joomla-Installation erstellt. Mit der läuft SEO-Glossary ebenfalls auf Anhieb einwandfrei.

Lui_brempt

Ich hatte gedacht, dass der Weg über den Dump einfacher sein könnte. Dann blieben die Verzeichnisse der alten Joomla-Instalation auf dem Server gleich.

Mit Akeeba müsste ich einen neuen Installationsordner anlegen und auch zum Ausprobieren im Server die URL auf den neuen Ordner legen.

Ich versuch morgen noch mal den Dump in die Maria-DB zu bekommen. Wenn's dann nicht geht, kann ich immer noch die Akeeba-Lösung nutzen.

Nun habe ich mittels Akeeba Backup die alte Site in einem neuen Serververzeichnis installiert und als Datenbank eine Maria-DB angegeben. Akeeba lief einwandfrei durch und ich fand auch weder im Joomla-Verzeichnis noch in der DB Auffälligkeiten. Immerhin ist damit ja wohl die DB korrekt erstellt worden.

Die htaccess im Joomla-Verzeichnis hab ich natürlich angepasst, da ich nun eine andere URL nutzten muss, statt der Produktiv-URL. Die neue URL ist genau so per LetsEncrypt gesichert erreichbar wie die alte Produktiv-Site.

Ferner habe ich die configuration.php im Joomla-Verzeichnis geprüft, aber alle Pfadangaben darin waren OK.

Eine andere URL zu verwenden als die URL der Produktiv-Site war eine gute Idee, denn prompt funktioniert die über Akeeba erstellte Site nicht. Sowohl auf der Homepage als auch auf der Admin-Site erhalte ich "404 The requested URL was not found on this server."

Die URL muss aber gültig sein, denn immerhin funktionierte sie ja während der Akeeba-Wiederherstellung.

Im Web fand ich bisher keine Lösungs-Anregungen.

Was tun?

Hab übrigens gemäß Akeeba-Ratgeber in der configuration.php geprüft, dass

public $cookie_domain = '';
public $cookie_path = '';

public $cache_handler = 'file';
public $caching = '0';
public $session_handler = 'database';

eingetragen sind. caching stand vorher auf '2' und session_handler stand auf 'none'

Mehr Hinweise fand ich auch bei Akeeba nicht.

Hab den Fehler gefunden!

In der Verwaltung der Websites auf meinem Webspace muss ich eine URL einem (Joomla-)Verzeichnis zuweisen, damit bei Aufruf der URL der Inhalt des Verzeichnisses verfügbar wird. Nun ist die URL zu meiner jetzigen Installation zwei mal aufgeführt, nämlich einmal ohne und einmal mit www. davor.

Normaler Weise hätte ich darauf geachtet. Am Bildschirm wurde in Tabellenform aber nur die www. URL dargestellt und erst bei Weiterblättern auf die nächste Tabellenseite wurde die non-www. URL aufgeführt.

Ich hatte den Fehler gemacht, nur eine der URLs auf das jetzige Joomla-Verzeichnis zeigen zu lassen und nicht auch die andere URL. Folglich zeigte die eine URL korrekt auf das gewünschte Joomla-Verzeichnis, wurde aber wegen Einstellungen in meiner htaccess nicht benutzt und die andere URL zeigte in ein leeres Verzeichnis meines Webspace.

Nachdem ich auch die andere URL auf das richtige Verzeichnis gelegt hatte, funktionierte nun alles, wie gewünscht.

AddOn zu deinen Anregungen:

Bei der oben beschrieben Fehlkonfiguration kann auch der Aufruf der robots.txt nicht funktionieren. Ist aber eine gute Idee, um unkompliziert und schnell zu testen, ob überhaupt was geht.

Gestern hatte ich auch die htaccess im Joomla-Wurzelverzeichnis kurzzeitig deaktiviert, brachte aber (logischer Weise) keine Änderung. Die dort vorliegenden Rewrite-Bedingungen sowie URL-Umleitungen hatte ich aber schon sehr sorgfältig geprüft.

Die neue Site habe ich in ein ganz frisches Verzeichnis installiert und auch die Maria-DB war blank. Ich verwende keine Subdomain, sondern immer https://meine-domain.de

Ich danke dir herzlich für deine Anregungen zur Fehlersuche und hoffe, dass diese Anregungen anderen weiter helfen werden!

Bei mir hatte bisher immer funktioniert, beide URLs auf das Joomla-Verzeichnis zu legen. Die Umleitung auf https mache ich in der htaccess mit:

RewriteCond %{HTTP_HOST} =www.meine-site.de [NC]
RewriteRule ^(.*)$ https://meine-site.de/$1 [R=301,L]

Oder in zwei Schritten:

RewriteCond %{HTTP_HOST} =www.meine-site.de [NC]
RewriteRule ^(.*)$ http://meine-site.de/$1 [R=301,L]

RewriteCond %{HTTPS} !=On [NC]
RewriteRule ^(.*)$ https://meine-site.de.de/$1 [R=301,L]

Ich gebe allerdings zu, dass mir jemand dies gestrickt hat und ich selbst gar nicht so genau weiß, wie die Codes zustande kommen. Jedenfalls hat es bisher funktioniert.

Ansonsten habe ich noch Keep alive aktiviert:

<ifModule mod_headers.c> 
 Header set Connection keep-alive 
</ifModule>

Betreffend apache2handler und cgi-fcgi kann ich nur folgendes sagen:

Ich war bis ca. 2018 bei DomainFactory / GoDaddy und bin wegen der untragbaren Zustände umgezogen nach WebGo. – Das unerwünschte Ausloggen begann noch während der GoDaddy-Zeit und der Server lief auf CGI.

Bei WebGo bin ich bisher gar nicht auf die Idee gekommen, dass es hier anders laufen könnte mit apache2handler. Zudem funktionieren ja alle neu angelegten Websites einwandfrei, sofern ich die Maria-DB nutze und nicht MySQL. Nur die beiden von DF umgezogenen Joomla-Sites (meine beiden Produktiv-Seiten) haben auch bei WebGo das Problem mit dem unerwünschten Ausloggen.

Um CrossPosting zu vermeiden, poste ich diesen Beitrag jetzt in den anderen, neuen Thread, den ich extra wegen des Ausloggen gestartet habe. Denn in diesem Thread ging es nur um die Schwierigkeit, den Dump einer MySQL-DB in die Maria-DB hinein zu bekommen. Und das ist ja mittels Akeeba-Backup endlich auch erfolgreich gelungen, das Thjema also gelöst.