WICHTIG: Umzug funktioniert nicht

Hier können Probleme und alles andere in Deutscher Sprache gelöst werden.
Post Reply
HadleyB
Regular
Posts: 837
Joined: Sat Feb 11, 2006 11:47 pm

WICHTIG: Umzug funktioniert nicht

Post by HadleyB »

Ich bin so vorgegangen:

Auf neuem Webspace Serendipity installiert mit neuer Datenbank. Dann komplett das "alte" Serendipity vom "alten" Account geholt und über den neuen drübergeschrieben.

Nun die "alte" Datenbank exportiert ohne bei den Einstellungen irgendwas angeklickt zu haben und den Dump versucht in die neue Datenbank zu schreiben.

Code: Select all

SQL-Befehl:

-- phpMyAdmin SQL Dump
-- version 2.6.4-pl3
-- http://www.phpmyadmin.net
-- 
-- Host: db95.puretec.de
-- Erstellungszeit: 18. September 2006 um 16:48
-- Server Version: 4.0.27
-- PHP-Version: 4.3.10-200.schlund.1
-- 
-- Datenbank: `db167991491`
-- 
CREATE DATABASE `db167991491` ;

MySQL meldet: Dokumentation
#1044 - Access denied for user '20060616005-2'@'213.160.81.6' to database 'db167991491'
Will heißen, er nimmt die Daten nicht an. Was mache ich denn falsch? Wenn ich das Blog nicht sichern kann, das ist doch irgendwie doof.

mfg
Hadley
stm999999999
Regular
Posts: 1531
Joined: Tue Mar 07, 2006 11:25 pm
Location: Berlin, Germany
Contact:

Post by stm999999999 »

Code: Select all

CREATE DATABASE `db167991491` ; 

MySQL meldet: Dokumentation 
#1044 - Access denied for user '20060616005-2'@'213.160.81.6' to database 'db167991491'
Bist Du Dir sicher, daß Du auf dem neuen Space selber Datenbanken anlegen darfst? Und zwar insbesondere direkt per sql?
Ciao, Stephan
HadleyB
Regular
Posts: 837
Joined: Sat Feb 11, 2006 11:47 pm

Post by HadleyB »

stm999999999 wrote:

Code: Select all

CREATE DATABASE `db167991491` ; 

MySQL meldet: Dokumentation 
#1044 - Access denied for user '20060616005-2'@'213.160.81.6' to database 'db167991491'
Bist Du Dir sicher, daß Du auf dem neuen Space selber Datenbanken anlegen darfst? Und zwar insbesondere direkt per sql?
Ähem, ich habe keine Ahnung. Ich habe jetzt mal versucht, die einzelnen Tabellen der Datenbank separat rüberzukopieren aber bei der Tabelle Permalinks steigt er aus weiler sagt, die Länge würde überschritten.

Es funktioniert einfach nicht, sollte es aber. Hat denn keiner eine Anleitung auf Deutsch, wie man seinen BLOG sichert? Wenn's die Datenbank zersemmelt, dann ist die ganze Arbeit umsonst.
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Post by garvinhicking »

Hi!

Was genau sagt er bei "Länge überschritten"? Evtl. musst du deinen SQL-Dump in kleinere Teile und mit "extended inserts" exportieren?

Grßüe,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
HadleyB
Regular
Posts: 837
Joined: Sat Feb 11, 2006 11:47 pm

Post by HadleyB »

garvinhicking wrote:Hi!

Was genau sagt er bei "Länge überschritten"? Evtl. musst du deinen SQL-Dump in kleinere Teile und mit "extended inserts" exportieren?

Grßüe,
Garvin
Er bricht immer bei den Permalinks ab:
SQL-Befehl:

-- --------------------------------------------------------
--
-- Tabellenstruktur f�r Tabelle `serendipity_permalinks` --
CREATE TABLE `sere ndipity_permalinks ` ( `perm alink ` var char( 255 ) NOT NULL default '', `entr y_id ` int ( 10 ) unsigned NOT NULL default '0', `type ` var char( 200 ) NOT NULL default '', `data ` tex t,
KEY `pl_i dx ` (`p ermalink `), KEY `ple_ idx ` (`e ntry_id `), KEY `plt_ idx ` (`t ype `), KEY `plco mb_idx ` (`p ermalink `,`ty pe `) ) TYPE = MYISAM ;

MySQL meldet: Dokumentation
#1071 - Specified key was too long; max key length is 1000 bytes
Selbst wenn ich die Tabelle der Permalinks leermache, kommt diese Fehlermeldung. Doch auch das ist noch nicht alles, er mag auch die Tabelle PLUGINCATEGORIES nicht:

Code: Select all

Fehler
Möglicherweise haben Sie einen Bug im SQL-Parser entdeckt. Bitte überprüfen Sie Ihre Abfrage genaustens, insbesondere auf falsch gesetzte oder nicht geschlossene Anführungszeichen. Eine weitere Ursache könnte darin liegen, dass Sie versuchen eine Datei mit binären Daten, welche nicht von Anführungszeichen eingeschlossen sind, hochzuladen. Sie können alternativ versuchen Ihre Abfrage über das MySQL-Kommandozeileninterface zu senden. Die MySQL-Fehlerausgabe, falls vorhanden, kann Ihnen auch bei der Fehleranalyse helfen. Falls Sie weiterhin Probleme haben sollten oder der Parser dort versagt, wo die Kommandozeile erfolgreich ist, so reduzieren Sie bitte Ihre Abfrage auf den Befehl, welcher die Probleme verursacht, und senden Sie uns einen Bugreport mit den Datenausschnitt, den Sie weiter unten auf dieser Seite finden.:
----AUSSCHNITTSANFANG----
eNqdkEFPwkAQhe/7K97BgyRtbYsIrvFQcaPELWBbMXihBRZoXNvabg397x5cwKgnTZxkTvPefG+G
BcEooOg76LvgbEjhtHu6z9Hu2iSM9Oy9RJTMCelPQoqjwZKiepVFUlaitGQ6t4pNYbzBtU67cG37
7MR2TpwunC61Xdq2sWjmuZqpF7BtgSPiN+E9pzi1HMt1TJmvyUMYYBQa8G7YMDIwYZr5mGbwR08D
zj10LJuMfY9qRM9yyfh2vNMYI52mo7ecmYV0zbXIVJ6Dp1m9Jdwb3lAshVmrldkjeyAhpoldXydK
ZFgdrhJSCsT6EpEt0yJVzazY5Cqf61zx3rC3mf+sL+YnKatUWT+ruvwFL+t1mi10xnVepqL6TNEP
mBcxRN4VZ38YcEyAeCGTqpplyYuI8ZaUi01SHrsdu6W/skpqqTB84NzYKw/W5g/dHZsi/oLN0uVW
k35ijO9NLdJCNB2zS78ZhJ5/8QGLFrPn
----AUSSCHNITTSENDE----
----BEGINN DER AUSGABE----

ERROR: C1 C2 LEN: 138 139 370
STR: �r Tab

CVS: $Id: sqlparser.lib.php,v 2.47 2006/01/17 17:02:30 cybot_tm Exp $
MySQL: 4.1.21-log
USR OS, AGENT, VER: Win MOZILLA 5.0
PMA: 2.8.2
PHP VER,OS: 5.1.6-pl2-gentoo Linux
LANG: de-utf-8
SQL: 

-- 
-- Daten f�r Tabelle `serendipity_photoblog`
-- 


-- --------------------------------------------------------

-- 
-- Tabellenstruktur f�r Tabelle `serendipity_plugincategories`
-- 

CREATE TABLE `serendipity_plugincategories` (
  `class_name` varchar(250) default NULL,
  `category` varchar(250) default NULL,
  KEY `plugincat_idx` (`class_name`,`category`)
) TYPE=MyISAM;

----ENDE DER AUSGABE----

SQL-Befehl:

-- -- Daten f�r Tabelle `serendipity_photoblog` -- -- -------------------------------------------------------- -- -- Tabellenstruktur f�r Tabelle `serendipity_plugincategories` -- CREATE TABLE `serendipity_plugincategories` ( `class_name` varchar(250) default NULL, `category` varchar(250) default NULL, KEY `plugincat_idx` (`class_name`,`category`) ) TYPE=MyISAM;

MySQL meldet: Dokumentation
#1071 - Specified key was too long; max key length is 1000 bytes 
mfg
Hadley[/code]
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Post by garvinhicking »

Hi!

Argh, der MySQL key length fehler.

Anscheinend wird dein MySQL mit UTF-16 betrieben, was die Länge der Keys vervierfacht. Du müsstest es irgendwie hinkriegen, die MySQL-Tabellen nur mit UTF-8 zu betreiben. Alternativ müsste man die Indize/Keys aller Tabellen so umändern, dass bei jedem Key eine Zeichenbeschränkung eingetragen wird die zusammen addiert maximal 250 Zeichen (250 * 4 = 1000) betragen dürfen.

Grüße,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
HadleyB
Regular
Posts: 837
Joined: Sat Feb 11, 2006 11:47 pm

Post by HadleyB »

garvinhicking wrote:Hi!

Argh, der MySQL key length fehler.

Anscheinend wird dein MySQL mit UTF-16 betrieben, was die Länge der Keys vervierfacht. Du müsstest es irgendwie hinkriegen, die MySQL-Tabellen nur mit UTF-8 zu betreiben. Alternativ müsste man die Indize/Keys aller Tabellen so umändern, dass bei jedem Key eine Zeichenbeschränkung eingetragen wird die zusammen addiert maximal 250 Zeichen (250 * 4 = 1000) betragen dürfen.

Grüße,
Garvin
Ganz ehrlich? Das ist mir viel zu hoch. Ich habe nicht ein einziges Wort verstanden. Wenn ich die Codierung der Tabellen ändere, dann zerhaut es doch mit Sicherheit das gesammte Blog.

mfg
Hadley
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Post by garvinhicking »

Hi!

Ich würde dir helfen, muss jetzt aber offline und endlich in Urlaub - evtl. kann dir jemand anders mit SQL Kenntnissen da helfen.

Änderungen von UTF-16 auf UTF-8 sollten eigentlich kein Problem machen.

Viele Grüße,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
HadleyB
Regular
Posts: 837
Joined: Sat Feb 11, 2006 11:47 pm

Post by HadleyB »

garvinhicking wrote:Hi!

Ich würde dir helfen, muss jetzt aber offline und endlich in Urlaub - evtl. kann dir jemand anders mit SQL Kenntnissen da helfen.

Änderungen von UTF-16 auf UTF-8 sollten eigentlich kein Problem machen.

Viele Grüße,
Garvin
Dann ab in den Urlaub. Du hast Dir den wirklich verdient!

mfg
Hadley
Boris

Post by Boris »

Bin gerade auf das gleiche Problem gestossen.
garvinhicking wrote:maximal 250 Zeichen (250 * 4 = 1000)
Lustigerweise sind es genau 333 erlaubte Zeichen bei mir.

Ich hab mir damit beholfen, dass ich nur die ersten 78 Zeichen von type als Schluessel betrachte. Momemtan ist die maximale Länge nur 8, hoffe mal das ändert sich nicht signifikant. Ansonsten dürfen halt zwei verschiedene Typen nicht den gleichen Permalink haben ;-)

Code: Select all

KEY `plcomb_idx` (`permalink`,`type`(78))
Zugschlus
Regular
Posts: 139
Joined: Sun Feb 05, 2006 12:54 am
Location: St. Ilgen, Germany
Contact:

Re: WICHTIG: Umzug funktioniert nicht

Post by Zugschlus »

Ich habe dieses Problem jetzt auch beim Import eines Datenbankdumps. Ich habe Debian stretch mit MariaDB 10.1.

phpMyAdmin sagt "Server charset: UTF-8 Unicode (utf8)", die Datenbank steht auf "Collation: utf8_unicode_ci" und die Definition der Tabelle serendipity_permalinks sagt "CHARSET=utf8".

Laut https://dev.mysql.com/doc/refman/5.7/en ... -utf8.html wird ein UTF-8 Zeichen von MySQL wie drei Zeichen gewertet, und (200 + 255 ) * 3 ist > 1000. Meine Hypothese wird bestätigt, dass man (200 + 133) * 3 = 999 noch anlegen kann, (200 + 134 ) * 3 = 1002 lässt sich nicht mehr anlegen.

Diese Tabelle dürfte also nicht in UTF8 angelegt werden oder die Werte müssen kürzer. Warum ist "type" überhaupt 200 Bytes lang? Dasselbe Problem gibt es bei serendipity_plugincategories mit zweimal 250 bytes.

Grüße
Marc
--
Marc Haber, St. Ilgen, Germany
https://blog.zugschlus.de/ - nach langer Pause jetzt wieder online
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: WICHTIG: Umzug funktioniert nicht

Post by garvinhicking »

Hi!

Wir haben einen utf8-migration Github branch, wo ich versucht habe alle Keys für utf8mb4 kompatibel zu machen:

https://github.com/s9y/Serendipity/tree/feature_utf8mb4

Da am besten mal in die sql/db.sql reinschauen. Eigentlich müsste der Upgrader wenn man jene Version installiert die Datenbank mit anpassen bzw. die notwendigen SQL-Statements dazu auch ausgeben über einen Migration-Task. Das könntest du mit einer Kopie oder so mal gerne ausprobieren, denn ich habe quasi noch kein Feedback zu dem Feature dort bekommen und würde mich über welches freuen :)

LG,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
Post Reply