XF2.2 1&1/Ionos sperrt einfach meine Datenbank

[Kirby]

Ich finde diese Daten über phpMyAdmin einfach nicht.

Die Neverending Story mit deinem Schrotthoster ;-)

FTS_* Dateien sind InnoDB-Volltext-Indexe (vmtl. für xf_search_index), die kannst Du weder mit PMA sehen noch löschen, denn diese werden benötigt.

(Wenn xf_search_index InnoDB ist was es aber ohnehin nicht sein sollte).

Die beiden anderen .idb-Dateien sind die Datenfiles der entsprechenden Tabellen und werden ebenso benötigt.

 

[Silmarillion]

Ich kann die gar nicht löschen?

Sternsackzement! Langsam schwillt mir echt der Hals. Hatten wir das nicht hier irgendwo schon einmal, dass ich die löschen kann!? Ohhh maan...

Das würde ja bedeuten, dass ich den benötigten Speicherplatz gar nicht weiter reduzieren kann. Das wäre der Genickbruch und das Aus bei Ionos.

 

[Kirby]

Ich kann die gar nicht löschen?

Können schon ... lösche einfach die Tabelle xf_search_index, dann sind due FTS weg.
Hat halt den unschönen Haken dass dein XenForo dann nicht mehr funktionieren wird.

Alternativ könntest Du auch den Typ der Tabelle auf Blackhole ändern, dann sind die auch weg und lediglich die Suche funktioniert dann nicht mehr.

Zu guter letzt könntest Du den Typ auf MyISAM ändern (also so wie es eh sein sollte), dann sind die FTS ebenfalls weg, Suche funktioniert weiterhin und Du dürftest einige GB einsparen.

 

[Silmarillion]

Können schon ... lösche einfach die Tabelle xf_search_index, dann sind sie weg.
Hat halt den unschönen Haken dass dein XenForo dann nicht mehr funktionieren wird.
Alternativ könntest Du auch den Typ der Tabelle auf Blackhole ändern, dann sind die auch weg und lediglich die Suche funktioniert dann nicht mehr.

Zu guter letzt könntest Du den Typ auf MyISAM ändern (also so wie es eh sein sollte), dann sind die FTS ebenfalls weg, Suche funktioniert weiterhin und Du dürftest einige GB einsparen.

Also doch ein Hoffnungsschimmer am Horizont?

Hätte ich denn dadurch irgendwelche Nachteile? Falls nein, warum zur Hölle wird das dann nicht direkt von Haus aus von meinem Hoster vorgenommen? Selbst ändern ist wohl nicht. Aber ich würde das dann natürlich direkt so weiterleiten. Ohne Garantie auf tatsächliche Änderung.

 

[Kirby]

Hätte ich denn dadurch irgendwelche Nachteile?

Bei welcher Variante?

Bei Variante "Tabelle löschen" wäre der Nachteil dass XenForo nicht mehr funktioniert.
Bei Variante "Blackhole" wäre der Nachteil dass die Suche nicht mehr funktioniert.
Bei Variante "MyISAM" wäre der Vorteil dass dies entgegen InnoDB seitens XenForo unterstützt wird - es ist die Default-Konfiguration und die einzige die offiziell unterstützt wird.

Falls nein, warum zur Hölle wird das dann nicht direkt von Haus aus von meinem Hoster vorgenommen?

Weil dein Hoster (zumindest im Bezug auf XenForo) unfähig ist.
Ich würde einmal vermuten dass ein automatischer Prozess von Ionos die Tabelle irgendwann auf InnoDB umgestellt hat - per Default ist das nicht der Fall.

Selbst ändern ist wohl nicht.

Doch, geht in PMA.
Aber bei entsprechender Größe der Tabelle dauert das eine Weile, also nicht wundern wenn es da evtl. einen Timeout gibt.
Alternative 1: Leeren, Typ ändern, Suchindex neu erstellen
Alternative 2 (falls möglich): Per SSH in der MySQL Konsole.

 

[Silmarillion]

Bei welcher Variante?


Bei Variante "MyISAM" wäre der Vorteil dass dies entgegen InnoDB seitens XenForo unterstützt wird - es ist die Default-Konfiguration und die einzige die offiziell unterstützt wird.

Genau die meine ich, ja.

Weil dein Hoster (zumindest im Bezug auf XenForo) unfähig ist.
Ich würde einmal vermuten dass ein automatischer Prozess von Ionos die Tabelle irgendwann auf InnoDB umgestellt hat - per Default ist das nicht der Fall.

Hatte diese Umstellung denn wenigstens irgendeinen nennenswerten Vorteil, oder nicht einmal das?

EDIT: gerade Folgendes dazu im Netz gefunden:

Stelle ich die db auf myISAM um, verschwindet der Fehler.
Das Problem ist nun, dass die großen Hoster hierzulande myISAM nicht mehr unterstützen bzw. erlauben. Bei Strato etwa vom Start weg nicht; bei IONOS kann man zwar die InnoDB-Tabellen auf myISAM umstellen, aber die lassen jede Nacht ein Script laufen, das sie wieder auf InnoDB zurücksetzt (hat mir einiges Kopfzerbrechen bereitet, das dieser Umstand zunächst auch dem IONOS-Support nicht bekannt war...).
Ich habe jetzt zwar mal versuchsweise für piwigo_tags manuell einen FULLTEXT Index angelegt, worauf dann nicht mehr piwigo_tags in der Fehlermeldung bei der quick Search bemängelt wurde, sondern das oben gepostete. Gibt es eine auch für Laien nachvollziehbare Lösung, um Piwigo so zu installieren, dass die Suche auch mit InnoDB funktioniert?
Vielen Dank & viele Grüße
Martin

Vorstellung Und Erste Frage Zu Myisam Vs. Innodb | Piwigo.org

Doch, geht in PMA.

Klingt gut. Wenn Du mir jetzt noch sagen würdest, was genau ich dafür beachten/machen muss...und ob ich mir da nichts "zerschießen" kann...dann würde ich es einfach mal selbst versuchen.

 

[Kirby]

Hatte diese Umstellung denn wenigstens irgendeinen nennenswerten Vorteil, oder nicht einmal das?

Allgemeine macht es schon Sinn alles als InnoDB zu haben.
Aber wie so oft: Ausnahmen bestätigen die Regel; bei xf_search_index macht es keinen Sin - es macht eher nur Ärger.

Klingt gut. Wenn Du mir jetzt noch sagen würdest, was genau ich dafür beachten/machen muss...und ob ich mir da nichts "zerschießen" kann...dann würde ich es einfach mal selbst versuchen.

Groß zerschießen kann man da eigentlich nichts; im Worst Case ist die Tabelle halt kaputt und muss neu erstellt werden.
Verloren gehen kann dabei nichts, ist nur der Suchindex - den kann man jederzeit neu erstellen.
Der Befehl zum ändern des Typ wäre

ALTER TABLE xf_search_index Engine=MyISAM

 

[Silmarillion]

Danke @Kirby.

Allerdings gibt es wohl ein kleines Problem, welches Du selbst schon vermutet hast. (siehe mein "EDIT" in #106)

Falls Du noch Zeit und Lust hast...

Server Fehlerprotokoll

Deine Meinung würde mich einfach interessieren.

Gruß,
Chris

 

[Kirby]

Hoster wechseln

XenForo unterstützt für xf_search_index nur MyISAM; mit InnoDB läuft es zwar so halbwegs aber nicht sauber.
Das liegt aber nicht an XenForo sondern ist prinzipbedingt bei InnoDB Volltext so.

Ergo: Wenn ElasticSearch nicht geht "muss" es MyISAM sein.

Xenforo database suddenly grows very quickly

 

[Silmarillion]

Ist echt ein Unding. Ich habe ja einen persönlichen Ansprechpartner bei Ionos, den ich morgen direkt kontaktieren werde. Dann sehen wir weiter. Zur Not muss ich den Laden echt nach 13 (!) Jahren verlassen.

Besteht eventuell sogar die Möglichkeit, dass die Serverprobleme (anderer Thread) gar nicht primär mit dem vermuteten "Datenbank-Shared-Server" zusammenhängen, sondern mit der InnoDB-Suche? Das wäre ja ein Ding.

 

[Kirby]

Besteht eventuell sogar die Möglichkeit, dass die Serverprobleme (anderer Thread) gar nicht primär mit dem vermuteten "Datenbank-Shared-Server" zusammenhängen, sondern mit der InnoDB-Suche? Das wäre ja ein Ding.

Möglich, aber IMHO eher unwahrscheinlich - ein kompetenter Hoster sollte dir das beantworten können.
Oh, wait, da war ja was von wegen Kompetenz
Warum man bei einem dedizierten Server einen (shared?) MySQL-Server hat erschließt sich mir auch nicht.
Im 08/15-Normalfall betreibt man bei einen dedizierten Server alles dort.

 

[mph]

Kann man ja auch auf dem dedizierten Server betreiben, allerdings nur wenn man MySQL 5.5 nutzt. Wenn man 5.7 auswählt oder seit kurzem MariaDB 10, dann landet man auf einen DB-Server, den man sich mit anderen teilt. Das Unding ist nur, dass man neuere Versionen auf dem dedizierten Server seit etwa einem Jahr immer wieder verschiebt.

 

[Silmarillion]

Danke, Männers! Thematik wäre damit wohl geklärt! Halten wir also fest: Ionos, die sich ja angeblich so um ihre Managed-Server (und deren Nutzer) kümmern...können mir nicht wirklich weiterhelfen. Ich selbst werde also aktiv und frage andernorts um Hilfe/Lösungen.

1. Zu hohe MySQL-DB-Belegung: Gelöst (siehe Statement von Chris D, welches ich gar nicht mehr auf dem Schirm hatte)

2. Immer wieder lahmender Server: Gelöst (Ionos soll in die Gänge kommen und meine DB "localhost" installieren)

100% Sicherheit habe ich damit noch nicht. Aber die Wahrscheinlichkeit, dass damit die Probleme tatsächlich erst einmal ad acta gelegt werden könn(t)en, ist zumindest hoch. Ich halte Euch auf dem Laufenden. Und natürlich bin ich gespannt, wie Ionos darauf reagiert und ob sie mit sich reden lassen und einsichtig sind.

 

[Hoffi]

Viel Erfolg!

 

[otto]

Das Unding ist nur, dass man neuere Versionen auf dem dedizierten Server seit etwa einem Jahr immer wieder verschiebt.

Genug Zeit, den Hoster zu wechseln... Ich weiß, ich sollte mit Strato mein "Maul" nicht zu weit aufreißen, aber zumindest kann ich zur Ehrenrettung meines Hosters sagen, das dessen Supporter (am besten über Facebook) definitiv kompetent sind heutzutage. War früher mal Vollkatastrophe (Telefon-Support).

N kleiner (echter) dedizierter root Server mit Ubuntu LTS + Plesk wäre auch für einen Anfänger gut zu händeln, ganz ohne Fremdmanagement.
Ab 60 Euro ist da brauchbares für den Anfang zu bekommen und man ist frei in vielen Entscheidungen...

 

[Masetrix]

Danke, Männers! Thematik wäre damit wohl geklärt! Halten wir also fest: Ionos, die sich ja angeblich so um ihre Managed-Server (und deren Nutzer) kümmern...können mir nicht wirklich weiterhelfen. Ich selbst werde also aktiv und frage andernorts um Hilfe/Lösungen.

1. Zu hohe MySQL-DB-Belegung: Gelöst (siehe Statement von Chris D, welches ich gar nicht mehr auf dem Schirm hatte)

2. Immer wieder lahmender Server: Gelöst (Ionos soll in die Gänge kommen und meine DB "localhost" installieren)

100% Sicherheit habe ich damit noch nicht. Aber die Wahrscheinlichkeit, dass damit die Probleme tatsächlich erst einmal ad acta gelegt werden könn(t)en, ist zumindest hoch. Ich halte Euch auf dem Laufenden. Und natürlich bin ich gespannt, wie Ionos darauf reagiert und ob sie mit sich reden lassen und einsichtig sind.

Stimmt, in deinem Szenario ist MyISAM für den Search_index wirklich die bessere Wahl.
Liegt die DB allerdings lokal vor mache ich mit MariaDB 10.5.13 die Erfahrung, genügend Ram vorausgesetzt, dass InnoDB die bessere Wahl ist, weil damit der komplette index im Speicher gehalten wird und was kann besser sein, als oft gebrauchtes im Ram vorzuhalten und nur Änderungen daran auf der Disk/SSD zu speichern. Stopwords sind auch bei InnoDB inzwischen kein Problem mehr.

Der "Nachteil", so eine 2GB search_index Tabelle kann mit InnoDB nach ein paar Tagen Laufzeit auch mal 20GB ArbeitsSpeicher verbrauchen.

 

[Silmarillion]

Da sich bei mir wieder eine Sperre (aktuell 10,7 von 11 GB belegt) abzeichnet, werde ich nun aktiv etwas ändern müssen.

Ich beziehe mich mit meiner Frage auf den Kommentar von ChrisD (Xenforo.com):

This is not supported by us and not the default. It means the table storage for the xf_search_index table has been changed from what we set it to which is MyISAM, to be InnoDB.

Is this something you intended to happen? If not, I'd recommend reverting it back to its default.

The process for that would be:

1. Disable the search functionality on your forum or close your forum
2. Drop the xf_search_index table.
3. Recreate the xf_search index table as follows:

SQL:
CREATE TABLE `xf_search_index` (
`content_type` varchar(25) COLLATE utf8mb4_general_ci NOT NULL,
`content_id` int unsigned NOT NULL,
`title` varchar(250) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '',
`message` mediumtext COLLATE utf8mb4_general_ci NOT NULL,
`metadata` mediumtext COLLATE utf8mb4_general_ci NOT NULL,
`user_id` int unsigned NOT NULL DEFAULT '0',
`item_date` int unsigned NOT NULL,
`discussion_id` int unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`content_type`,`content_id`),
KEY `user_id_item_date` (`user_id`,`item_date`),
FULLTEXT KEY `title_message_metadata` (`title`,`message`,`metadata`),
FULLTEXT KEY `title_metadata` (`title`,`metadata`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

4. Rebuild your search index from Admin > Tools > Rebuild search index

The hope is that after step 2, these files will no longer be present:

Code:
141M FTS_00000000006b9591_000000000086fcd6_INDEX_6.ibd
217M FTS_00000000006b9591_000000000086fccf_INDEX_1.ibd
525M FTS_00000000006b9591_000000000086fccf_INDEX_4.ibd
557M FTS_00000000006b9591_000000000086fccf_INDEX_3.ibd
573M FTS_00000000006b9591_000000000086fccf_INDEX_6.ibd
637M FTS_00000000006b9591_000000000086fccf_INDEX_5.ibd
801M FTS_00000000006b9591_000000000086fccf_INDEX_2.ibd
2.2G xf_search_index.ibd

This would free up about 5.5GB evidently.

Meine Fragen:

1. Was passiert, wenn Ionos von InnoDB auf MyISAM umstellt? Funktioniert dann eventuell erst einmal irgendetwas nicht mehr?

2. Wo genau muss ich den von ChrisD angegebenen SQL-Code einfügen und ausführen? (habe derlei bis dato noch nie gemacht, noch nie machen müssen)

Danke im Voraus.

 

[otto]

1. Backup

alles weitere dann danach mit einem Test-System testen ehe man im richtigen Forum los legt. Testen könnte man auch daheim > LAAMP.

 

[mph]

1. Backup

Dem kann ich mich nur anschließen.

1. Was passiert, wenn Ionos von InnoDB auf MyISAM umstellt? Funktioniert dann eventuell erst einmal irgendetwas nicht mehr?

Mit dem was ChrisD beschrieben hat, löscht du selbst zuerst manuell die Datenbanktabelle, die für den Suchindex benutzt wird. Mit dem SQL-Code erzeugst du die Tabelle neu, anstatt mit InnoDB nun mit MyISAM. Der Rest der DB wird nicht angefasst. Wenn etwas schief geht, fehlt der Suchindex und die Suche geht im Forum nicht mehr. Das Forum sollte während der Aktion besser im Wartungsmodus sein. Wenn jemand die Suche ausführt, geht die Aktion möglicherweise schief.

2. Wo genau muss ich den von ChrisD angegebenen SQL-Code einfügen und ausführen? (habe derlei bis dato noch nie gemacht, noch nie machen müssen)

Da nur die Tabelle manuell gelöscht und dann per SQL neu erzeugt wird, dürfte das auch im phpMyAdmin geben. Den müsstest du aus dem Control Center von Ionos aufrufen können. Auf der linken Seite die oberste Ebene (mit dem DB-Namen, im Screenshot geschwärzt) klicken und oben rechts im Menü auf SQL. Da kann man den SQL-Befehl reinkopieren und ausführen.



Nach der Aktion musst du den Suchindex neu erstellen lassen. Der alte Suchindex ist ja weg und der neue noch leer. Erst wenn das durchgelaufen ist sollte das Forum wieder aktiviert werden.

PS: Bei mir steht die Tabelle für den Suchindex auf myISAM. Die macht rund 18% der gesamten DB-Größe aus.

 

[Kirby]

Da sich bei mir wieder eine Sperre (aktuell 10,7 von 11 GB belegt) abzeichnet, werde ich nun aktiv etwas ändern müssen.

Hast Du die Datenbank mittlerweile auf deinem "Managed" Server oder ist das immer noch ein shared MySQL?

Falls letzteres (wovon ich ausgehe) kannst Du dir das ganze sparen - Ionos wird die Tabelle automatisch wieder auf InnoDB umstellen.