Mai 2

Owncloud Update 8.0.3: PDOException / BINLOG_FORMAT

Nach der Umstellung auf MariaDB gab es kürzlich ein Owncloud Update
auf Version 8.0.3-1. Mit dem bekannten Befehl

sudo -u www-data php /var/www/owncloud/occ upgrade
wollte ich die Datenbank auf den aktuellen Stand bringen, jedoch machte mir scheinbar
meine Umstellung auf MariaDB einen Strich durch die Rechnung.

In der Kommandozeile bekam ich folgenden Fehler:
An unhandled exception has been thrown:
exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 1665 Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.' in /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:91

… im Browser stand dazu ähnliches:
Aktualisiere ownCloud auf Version 8.0.3. Dies könnte eine Weile dauern.
An exception occurred while executing ' DELETE FROM `oc_lucene_status` WHERE `fileid` IN ( SELECT `fileid` FROM ( SELECT `fileid` FROM `oc_lucene_status` GROUP BY `fileid` HAVING count(`fileid`) > 1 ) AS `mysqlerr1093hack` )': SQLSTATE[HY000]: General error: 1665 Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.
The update was unsuccessful. Please report this issue to the ownCloud community.


Der Grund dafür liegt, wie die Meldung bereits nahelegt, in der Art des Formats
für den Bin(ary) Log von SQL. Dieser steht standardmäßig offenbar auf STATEMENT,
owncloud wünscht sich aber für seine READ (UN)COMMITTED Anweisungen ein row-logging.

Die Lösung für dieses Problem gestaltet sich glücklicherweise recht einfach:

In der Konfiguration von MySQL/MariaDB (i.d.R. /etc/mysql/my.cnf) setzt man
sinnvollerweise irgendwo in der nähe bereits existierender binlog Einstellungen,
also z.B. unter max_binlog_size (auf jedenfall jedoch innerhalb der [mysqld] Sektion –
danke Gladdle für den Hinweis!) den Parameter für das Format
binlog_format = ROW
und speichert die Konfiguration ab. Danach ein SQL Neustart und das owncloud Update
nochmal mit o.g. Befehl anwerfen. Danach läuft alles in gewohnter Weise ab.
Turned on maintenance mode
Checked database schema update
Checked database schema update for apps
Updated database
Disabled 3rd-party app: updater
Turned off maintenance mode
Update successful


Schlagwörter: , ,

Veröffentlicht2. Mai 2015 von gerger in Kategorie "Allgemein

8 COMMENTS :

  1. By Viktoria on

    Auf das gleiche Ergebnis kam ich auch. Irgendwie witzig, dass das kaum wo in Release Notes oder ‚Requirements‘ verewigt wurde…

    Antworten
    1. By gerger (Beitrag Autor) on

      Hat mich auch gewundert… ich habe es mittlerweile (aber auch nur, weil ich im Speziellen danach gesucht habe) zumindest in den Upgrade Notes gefunden: https://doc.owncloud.org/server/8.0/admin_manual/maintenance/upgrade.html#troubleshooting
      Wenn der Fehler jedoch bei den Dev’s bekannt ist, hätte man vielleicht aber auch so gütig sein können und eine ordentliche Fehlermeldung dafür generieren können…

      Allerdings wird dort als binlog Format mixed vorgeschlagen. Davon bin ich noch nicht so wirklich überzeugt.
      Zum Einen, weil die SQL-Meldung ja relativ deutlich ist, was das gewünschte Format angeht (“InnoDB is limited to row-logging”) .
      Zum Anderen liest man, dass “Statement” die schnellste Einstellung ist – aber nunmal nicht [mehr] von ownCloud unterstützt wird – und “Row” die sicherste, was Kompatibilität und Konsistenz der Logdaten angeht. Mixed sollte dann offenbar beide Vorteile kombinieren, was jedoch teilweise ebenfalls zu Kompatibilitätsproblem, dadurch schlechter Performance und im worst-case bis hin zu fehlerhaften Daten bei Replikationen führen kann.

      Da ich hier jedoch keine eigenen Erfahrungswerte habe, will ich mich da nicht zu weit aus dem Fenster lehnen. Mit der Row-Einstellung fahre ich derzeit auf jedenfall auch im Zusammenspiel mit allen anderen Diensten problemlos.

      Antworten
  2. By Gladdle on

    Danke für diese Information! Hier fehlt leider eine Angabe: „binlog_format“ muss unter dem Reiter „[mysqld]“ stehen, ansonsten funktioniert das ganze nicht. Bei Linux Gentoo mit MySQL 5.6 kommt dieser Punkt in der my.cnf circa ab Zeile 45. Da ich per Google auf diese Seite gekommen bin wollte ich diese Information noch posten, damit andere Suchende auch finden was Sie brauchen 😉

    Antworten
    1. By gerger (Beitrag Autor) on

      Danke für den Hinweis! Ich habe die Stelle im Artikel überarbeitet, damit das deutlicher wird!

      Antworten
  3. By Kay on

    Vielen Dank für den Hinweis.
    Bei mir hatte es zwar nichts mit dem Upgrade zu tun aber urplötzlich zeigte mir meine, erst ein paar Tage alte, Installation Fehlermeldungen auf der Loginseite und ‚Exceptions‘ im Log an.
    Nach einkommentieren der erwähnten Zeile in MariaSQL config alles wieder Bestens.

    Antworten
  4. By Raphael on

    Woah!

    Ich hantiere hier seit Stunden daran, dieses Problem zu beheben, weil es nach dem Serverumzug aufgetreten ist und seitdem auch MariaDB nutze.

    Das man nun das einfach auskommentieren muss… Ja.

    Danke jedenfalls!

    Antworten
  5. By Jörg on

    Danke für diesen Tipp. Hatte immer wieder Probleme, sobald ein update kam, dass ich nicht mehr in die Cloud kam. Jetzt läuft der spass wieder.

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.