Kategorien
Allgemein

Owncloud zu Nextcloud Migrationsproblem mit Mysql DB Verbindung

Nachdem sich Nextcloud von Owncloud abgesplittet hat und die Entwicklung dort Fahrt aufgenommen hat, wollte ich heute eine Owncloud 9 Version nach Nextcloud 11 migrieren.

Der Direkte Pfad wird nicht empfohlen – hier die Empfehlung von Nextcloud:

  • ownCloud 8.0.x -> ownCloud 8.1.x -> ownCloud 8.2.x -> Nextcloud 9.0.x -> Nextcloud 10.0.x
  • ownCloud 8.2.x -> Nextcloud 9.0.x -> Nextcloud 10.0.x
  • ownCloud 9.0.x -> Nextcloud 9.0.x -> Nextcloud 10.0.x
  • ownCloud 9.1.x -> Nextcloud 10.0.x -> Nextcloud 11.0.x

In meinem Fall habe ich erst Owncloud auf die Version 9.1.4 hoch gezogen und dann migriert.

Die Migration hat allerdings nicht auf Anhieb geklappt – nach dem Einspielen der Dateien und dem Anpassen der Konfiguration bekam ich folgende Fehlermeldung:

Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000] [2006] MySQL server has gone away in /var/www/nextcloud/lib/private/DB/Connection.php:59
Stack trace:
#0 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect()
#1 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
#2 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform()
#3 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(621): Doctrine\DBAL\Connection->getDatabasePlatform()
#4 /var/www/nextcloud/lib/private/DB/Connection.php(142): Doctrine\DBAL\Connection->setTransactionIsolation(2)
#5 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(172): OC\DB\Connection->__construct(Array, Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
#6 /var/www/nextcloud/lib/private/DB/ConnectionFactory.php(121): Doctrine\DBAL\DriverManager::getConnection(Array, Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
#7 /var/www/nextcloud/lib/private/Server.php(415): OC\DB\ConnectionFactory->getConnection(‚mysql‘, Array)
#8 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
#9 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(103): Pimple\Container->offsetGet(‚DatabaseConnect…‘)
#10 /var/www/nextcloud/lib/private/ServerContainer.php(89): OC\AppFramework\Utility\SimpleContainer->query(‚DatabaseConnect…‘)
#11 /var/www/nextcloud/lib/private/Server.php(1029): OC\ServerContainer->query(‚DatabaseConnect…‘)
#12 /var/www/nextcloud/lib/private/legacy/db.php(57): OC\Server->getDatabaseConnection()
#13 /var/www/nextcloud/lib/private/User/Database.php(232): OC_DB::prepare(‚SELECT `uid`, `…‘)
#14 /var/www/nextcloud/lib/private/User/Database.php(280): OC\User\Database->loadUser(“)
#15 /var/www/nextcloud/lib/private/User/Manager.php(140): OC\User\Database->userExists(“)
#16 /var/www/nextcloud/lib/private/User/Session.php(197): OC\User\Manager->get(“)
#17 /var/www/nextcloud/lib/private/Log.php(282): OC\User\Session->getUser()
#18 /var/www/nextcloud/lib/public/Util.php(159): OC\Log->log(3, ‚User backend OC…‘, Array)
#19 /var/www/nextcloud/lib/private/legacy/user.php(146): OCP\Util::writeLog(‚core‘, ‚User backend OC…‘, 3)
#20 /var/www/nextcloud/lib/base.php(742): OC_User::setupBackends()
#21 /var/www/nextcloud/lib/base.php(1074): OC::init()
#22 /var/www/nextcloud/console.php(56): require_once(‚/var/www/nextcl…‘)
#23 /var/www/nextcloud/occ(11): require_once(‚/var/www/nextcl…‘)
#24 {main}PHP Warning: call_user_func() expects parameter 1 to be a valid callback, class ‚OC\Log\File‘ not found in /var/www/nextcloud/lib/private/Log.php on line 299

Irgend ein Problem mit der Verbindung zur Datenbank – nachdem Owncloud zuvor mit der gleichen Config funktioniert hat und ich die Zugangsdaten mehrfach geprüft habe, kam ich zu dem Entschluß dass ich es mal mit einer frischen Datenbank versuchen könnte.

Also einfach die config/config.php verschmissen und neue Daten eingetragen. Wenige Sekunden später lief dann eine leere Instanz von Owncloud (keine User) mit den vorhandenen Files.

Als nächstes  habe ich einen Dump der alten Datenbank erstellt und diesen über die neue Datenbank gespielt. Eigentlich würde ich erwarten dass jetzt gleich wie vorher nicht mehr funktioniert. Falsch geraten – das Upgrade auf Nextcloud 10 ließ sich ohne Schwierigkeiten installieren.

Anschließend noch die Kür mit dem Upgrade auf Nextcloud 11 und beendet ist die kleine Upgrade-Orgie.

Warum das Ganze? Weil ich Kalender und Kontakte synchronisieren will… 🙂

PS: Im Zuge der Umstellung habe ich dann auch gleich von mysql zu mariadb gewechselt.

Kategorien
Linux

Error ‚You cannot ‚ALTER‘ a log table if logging is enabled‘ on query. Default database: ‚mysql‘. Query: ‚ALTER TABLE slow_log

Gelegentlich kommt es vor dass bei einem Master/Slave MySQL System folgende Fehlermeldung im „SHOW SLAVE STATUS“ angezeigt wird:

Error ‚You cannot ‚ALTER‘ a log table if logging is enabled‘ on query. Default database: ‚mysql‘. Query: ‚ALTER TABLE slow_log

Man kann also die slow_log Table nicht verändern während das Logging aktiviert ist…

Somit muss es ausgeschaltet werden damit die Veränderung an der Tabelle greift und anschließend kann es wieder aktiviert werden.

Das klappt wie folgt – im MySQL am Slave anmelden und anschließend den Slave stoppen.

STOP SLAVE;

In unserem fall müssen wir den slow_query_log deaktivieren:

SET GLOBAL slow_query_log = ‚OFF‘;

Jetzt kann man den Slave wieder starten:

START SLAVE;

Die Fehlermeldung sollte verschwunden sein und der Log wird wie gewohnt abgearbeitet:

SHOW SLAVE STATUS\G

Und jetzt können wir noch das Logging reaktivieren:

SET GLOBAL slow_query_log = ‚ON‘;

Leider tritt das Problem immer wieder mal nach einem MySQL Update auf…

Kategorien
Linux

MySQL 5.5 Server ohne InnoDB betreiben

Auf die Datei ibdata1 und ib_logfile0 im /var/lib/mysql Ordner wollte ich verzichten, also das Naheliegende gemacht und in der /etc/mysql/my.cnf Datei die Zeile:

skip-innodb

eingefügt – mit dem Effekt dass anschließend beim Starten von mysql folgende Fehlermeldung kommt:

140114  9:28:40 [Note] Plugin ‚InnoDB‘ is disabled.
140114  9:28:40 [Note] Plugin ‚FEDERATED‘ is disabled.
140114  9:28:40 [ERROR] Unknown/unsupported storage engine: InnoDB
140114  9:28:40 [ERROR] Aborting

Irgendwie nett dass nach dem Abschalten von InnoDB die Meldung kommt dass InnoDB nicht unterstützt wird! 🙂

Grund dafür ist ganz einfach dass MySQL als default Storage Engine InnoDB verwendet und man das auf MyISAM umschalten muss:

default-storage-engine=MyISAM

Sobald diese Zeile in der my.cnf drinnen ist startet auch der MySQL Server wieder ohne Probleme und dieses Mal auch ohne die besagten Dateien in /var/lib/mysql anzulegen.