Hi,
ich habe heute Piwik auf unseren root-Server installiert, der mit PHP-Version:5.2.9 und SQL-Version: 5.0.45 läuft. Die Installation lief ohne Probleme, die Datenbank Tabellen wurden erstellt und ich kann Piwik auch aufrufen.
Jetzt zum Problem, in den Widgets und den Ansichten für die Statistiken erscheint der Fehler: "SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server during query"
zusätzlich noch:
“Die Piwik-Konfigurationsdatei konnte nicht gefunden werden und es wird versucht, eine Piwik-Seite aufzurufen.
» Sie können Piwik jetzt installieren
Wenn Sie Piwik zuvor schon installiert haben und noch Tabellen in der Datenbank vorhanden sind: Keine Angst, Sie können diese Tabellen und die enthaltenen Daten weiterhin verwenden!”
Die Rechte (755) hab ich per ssh console auf die Ordner(config,tmp) und ihre Inhalte gesetzt.
Nun finde ich keine passende Beschreibung die mir helfen könnte den Fehler bei Piwik wegzubekommen.
Wenn ich das tue, lande ich wieder auf der Startseite. Hab auch schon die Config gelöscht und nochmal neuinstalliert, gleiches Resultat.
Liegt das eventuell am SQL Server, dass dort Einstellungen der Innodb zuniedrig sind? Hatte schon gesehen das einige Werte dort rot markiert sind. Gibt es ne Empfehlung für die Werte die eventuell limitieren könnten?
Die Daten werden ja schon in der Datenbank gesammelt, anscheinend liegt es nur an der Ausgabe, dass Piwik dort probleme macht. Wie oben schon gefragt, liegt das an Abfrage-Parameter(wie oft Piwik abfragen darf, Sessions oder cache) vom SQL Server?
Gruß
Wurde die Config-Datei bei der Installation richtig geschrieben und ist dem richtigen Benutzer (z.B. www-data) zugeordnet?
Wie sieht der Host vom Datenbankserver aus? Evtl. 127.0.0.1 statt “localhost” eingetragen, oder vielleicht (schon oft gesehen…) den phpMyAdmin-Link da eingetragen?
Was sagt das Mysql-Log?
Config scheint Ordnung zu sein, DB-Login funktioniert und es wird ja auch in die DB geschrieben.
Hab mal den SQL Log(mysqld.log) durchforstet:
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
100809 15:13:52 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 3652948746.
InnoDB: Doing recovery: scanned up to log sequence number 0 3652948746
100809 15:13:52 InnoDB: Started; log sequence number 0 3652948746
100809 15:13:52 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 SUSE MySQL RPM
100809 15:13:53 - mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=16777216
read_buffer_size=258048
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 92783 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x21ce740
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x40e9dfe0, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x21ce740 failed sanity check, terminating stack trace!
Please read <a href="dev.mysql.com/doc/mysql/en/using-stack-trace.html" target="_blank">dev.mysql.com/doc/mysql/en/using-stack-trace.html</a> and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x2214ab0 = SELECT idarchive, value, name, date1 as startDate
FROM piwik_archive_numeric_2010_08
WHERE idsite = '1'
AND date1 = '2010-08-08'
AND date2 = '2010-08-08'
AND period = '1'
AND ( (name = 'done' AND value = 1)
OR (name = 'done' AND value = 3)
OR name = 'nb_visits')
AND ts_archived >= '2010-08-08 22:00:00'
ORDER BY ts_archived DESC
thd->thread_id=2
The manual page at <a href="www.mysql.com/doc/en/Crashing.html" target="_blank">www.mysql.com/doc/en/Crashing.html</a> contains
information that should help you find out what is causing the crash.
Number of processes running now: 0
100809 15:13:53 mysqld restarted
100809 15:13:53 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
Wenn ich die SQL-Anweisung direkt bei Phpmyadmin eingebe, stürzt die DB ab:
SELECT idarchive, value, name, date1 as startDate
FROM piwik_archive_numeric_2010_08
WHERE idsite = '1'
AND date1 = '2010-08-08'
AND date2 = '2010-08-08'
AND period = '1'
AND ( (name = 'done' AND value = 1)
OR (name = 'done' AND value = 3)
OR name = 'nb_visits')
AND ts_archived >= '2010-08-08 22:00:00'
ORDER BY ts_archived DESC
ERROR: PleskFatalException
Unable to connect to database: mysql_connect() [<a href='function.mysql-connect'>function.mysql-connect</a>]: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
0: common_func.php3:146
psaerror(string 'Unable to connect to database: mysql_connect() [<a href='function.mysql-connect'>function.mysql-connect</a>]: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)')
1: auth.php3:93
Bei der Installation scheint alles in Ordnung zu sein, es sei denn einer von euch könnte das mal ausprobieren. Wobei ich nicht glaube das das Problem so einfach Reproduzierbar ist und es eher mit dem Root-Server zusammenhängt.
style_emoticons/<#EMO_DIR#>/angry.gif
"… Diese Version hat einen Bug der sich bei select - mit order by - desc - Abfragen bemerkbar macht und die DB abstürzen läßt. Ach so ist die 64 bit Version. Bei der 32 Bit kommt der Fehler wohl nicht. …"
aus dem Thread: www .rootforum.org/forum/viewtopic.php?f=104&t=50045&start=25