Komisches verhalten - MariaDB

  • Hallo Netcupler,


    Heute benötige ich mal wieder eure Hilfe um ein kleines Problem in den Griff zu bekommen. Ich habe ein Webhosting (4000er) und ein VPS (500er) da beim Webhosting das Wordpress immer langsamer wurde und die Datenbank Queries immer länger gebraucht haben, dachte ich mir setz doch mal schnell auf dem leeren VPS500 eine MariaDB Docker auf und guck wie schnell die Seite dann ist. Hat auch gut funktioniert und die Seite ist um EINIGES schneller geworden. Jetzt kommen wir aber zum Problem:


    Auf der Wordpress Seite verwende ich Beaver Builder, um einen Beitrag / Seite zu duplizieren hat Beaver Builder dafür eine Funktion, wenn ich diese ausführe wird die Seite auch erstellt aber leider werden in der Datenbank einige KB's von wichtigen Daten geschluckt oder kommen da eben nicht an. Ich hab mir die Funktion dann mal angeschaut.


    Was passiert:

    Original Beitrag (ID 3838) fl_builder_data:

    pasted-from-clipboard.png


    Duplizierter Beitrag (ID 3935) (auch beim zweiten duplizieren, wieder 36270 Zeichen)

    pasted-from-clipboard.png


    Also habe ich es mit einem anderen Beitrag erneut versucht (Ausgang ca. 100.000 Zeichen, nach dem duplizieren dann 36.807 Zeichen). Also verschluckt er irgendwo beim Senden oder Empfangen die Zeichen.


    Die Funktion:


    Also eigentlich was ganz einfaches, erstelle einen neuen Beitrag und lese die "postmeta" Daten aus und füge sie dem neuen Beitrag hinzu.


    So, dann hab ich mir eine Testseite erstellt, um zu gucken ob er die vollständige postmeta ausließt:

    PHP
    $post_meta = $wpdb->get_results( $wpdb->prepare( "SELECT meta_key, meta_value FROM {$wpdb->postmeta} WHERE post_id = %d", $post_id ) );

    Zieht alle postmeta Daten richtig aus der Datenbank, die Zeichen passen (116.430)


    Also schauen wir mal ob die Daten gesendet werden (in der foreach hab ich folgendes eingebaut:)

    PHP
    echo('postID: '.$new_post_id.'<br> meta_key: '.$meta_key.'<br> metavalue_len: '.strlen($meta_value).'<br>');

    Siehe da, auch hier werden die Daten komplett angezeigt und die Länge passt überein.


    Also dachte ich mir, eventuell irgendwo Probleme, dass der mariadb Server nicht mehr wie 32kb an Daten annimmt (LONGTEXT ist richtig gesetzt -> bis 4GB), hab dann eine Datenbank angelegt und die 116.430 Zeichen an die Datenbank geschickt. Hier kommen die Daten ohne Probleme in voller Länge an.


    Frage:

    Fällt euch noch was ein, wo die Daten verloren gehen können ? Oder hab ich gerade einen groben Denkfehler.

  • Eventuell ein Unicode Problem der Verbindung? (Stichwort utf8mb4)


    Oder befindet sich an der abgeschnittenen Stelle vielleicht zufällig irgendein Sonder-/Steuerzeichen?

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Steht auf 16MB sollte also für die paar Zeichen reichen :D
    max_allowed_packet = 16777216


    General log mitlaufen lassen

    INSERT INTO wn_postmeta (post_id, meta_key, meta_value)

    UNION ALL SELECT 3964, '_fl_builder_data', '---> ALLE DATEN <---'


    Also kommen die Daten richtig an werden aber nicht komplett gespeichert.


    Eventuell ein Unicode Problem der Verbindung? (Stichwort utf8mb4)

    SET NAMES utf8mb4
    SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'


    Wird beim verbinden von Wordpress zur DB also richtig gesetzt.


    Oder befindet sich an der abgeschnittenen Stelle vielleicht zufällig irgendein Sonder-/Steuerzeichen?

    Ok meine nächste Aufgabe, ich danke schonmal für die Denkanstöße, ich guck mir mal die vielen Zeichen an. :D

  • Schönes Rätsel, halt uns auf dem laufenden :)


    Code
    /* Neu angelegte Werte in Datenbank */
    s:13:"margin_bottom";s:1:"0";s:20:"margin_bottom_medium";s:0:"";s:24:"margin_bottom <- ENDE
    
    /* Werte die kopiert werden sollten */
    s:13:"margin_bottom";s:1:"0";s:20:"margin_bottom_medium";s:0:"";s:24:"margin_bottom_responsive";s:0:"";s:11:"margin_left"; -> MEHR
    
    /* Werte aus dem Query Log */
    s:13:\"margin_bottom\";s:1:\"0\";s:20:\"margin_bottom_medium\";s:0:\"\";s:24:\"margin_bottom_responsive\";s:0:\"\";s:11 -> MEHR
    // Bemerkung addslashes ( ) //


    Hier auch kein Super Sonderzeichen zu sehen, welches die Speicherung in die Tabelle unterbrechen sollte.

  • Dieses Verhalten hab ich auch mal gehabt. Da lag es allerdings (wie bereits vorgeschlagen) an einem utf8-mb4 zeichen, in einer nicht-mb4 Datenbank.

    Dann schneidet er das einfach so ab.. aber das hattest du ja bereits ausgeschlossen?

    (Nicht die Collation der connection, sondern der der Tabelle)

    Meine (Netcup) Produkte: S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

  • Hier auch kein Super Sonderzeichen zu sehen, welches die Speicherung in die Tabelle unterbrechen sollte.

    Womit schaust Du Dir das an? Ich denke da nämlich an unsichtbare (Unicode) Steuerzeichen. Die zeigt nicht jeder Editor an. Manche auch nur, wenn man sie explizit so konfiguriert. Zur Sicherheit den ganzen String mal unverändert 1:1 mit PHP in einer Datei abspeichern, dann mit einem Hex-Editor öffnen und zur Problemstelle scrollen.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • So ThomasChr hat es mal bei einer neuen MariaDB Installation probiert, alles ein wenig Komisch.


    | post_id | meta_key | length(meta_value) |


    Original:

    | 3838 | _fl_builder_draft | 116523 |


    ThomasChr Ergebnis:

    | 3964 | _fl_builder_data | 50987 |


    Mein Ergebnis:

    | 3964 | _fl_builder_data | 51016 |

  • Hab das ganze gerade nochmal mit Server version: 8.0.20 MySQL Community Server - GPL probiert und siehe da... der Mag das komplette Query.


    mysqld 8.0.20:

    | 3964 | _fl_builder_data | 116311 |


    Edit: Ohh doch nicht 100% die gleiche Länge, dies kann aber eventuell an einem anderen Insert liegen, welches ich noch offen hatte. Aber er bricht nicht bei 50k ab.

  • Der einzelne Select klappt.

    Kann ich bestätigen auf der MariaDB


    PHP
    $sql_select[] = "SELECT {$new_post_id}, '{$meta_key}', '{$meta_value}'";}
    
    $sql .= implode( ' UNION ALL ', $sql_select );
    // @codingStandardsIgnoreStart
    $wpdb->query($sql);
    // @codingStandardsIgnoreEnd


    Das ganze wird ja hier so aufgebaut, wahrscheinlich damit nur eine Datenbank-Verbindung aufgebaut werden muss und nicht "x"-Verbindungen für jede postmeta. Könnte die Funktion mal umschreiben, das er jedes Select einzeln schickt.

  • Werde später noch ein wenig rumspielen und mal gucken ob es mit "Lorem ipsum" Text zu den selben Problemen kommt. Nur aktuell leider keine Zeit.


    Geplannte Versuche:

    • 'fl_builder_data' als erstes SELECT ausführen, und danach die anderen "kurzen" Daten.
    • 'fl_builder_data' mit "Lorem ipsum" Text ersetzen und erneut versuchen.
    • PHP Script umbauen, das er jedes Query einzeln an die DB schickt <- Workaround. (Nach Update des Pagebuilder immer wieder dran denken <X)
  • PHP Script umbauen, das er jedes Query einzeln an die DB schickt <- Workaround. (Nach Update des Pagebuilder immer wieder dran denken )

    Oder ein Ticket beim Hersteller / Post im Forum eröffnen und den Workaround in die generelle Codebase bekommen. Vielleicht bist du nicht der einzige mit dem Problem.