[Réglé] SQL ERROR quand je tente de supprimer un membre

[Mornagest]

Bonjour,

J'ai constaté un bug gênant lorsque je souhaite supprimer un membre via le panel admin. Voici l'erreur que j'obtiens :

Code : Tout sélectionner

SQL ERROR [ mysqli ]

Record has changed since last read in table 'phpbb_topics' [1020]

SQL

UPDATE phpbb_topics SET topic_poster = 1, topic_first_poster_name = 'XXXXXXX', topic_first_poster_colour = '' WHERE topic_poster = YYYYYY

BACKTRACE

FILE: (not given by php)
LINE: (not given by php)
CALL: msg_handler()

FILE: [ROOT]/phpbb/db/driver/driver.php
LINE: 1031
CALL: trigger_error()

FILE: [ROOT]/phpbb/db/driver/mysqli.php
LINE: 216
CALL: phpbb\db\driver\driver->sql_error()

FILE: [ROOT]/phpbb/db/driver/factory.php
LINE: 353
CALL: phpbb\db\driver\mysqli->sql_query()

FILE: [ROOT]/includes/functions_user.php
LINE: 620
CALL: phpbb\db\driver\factory->sql_query()

FILE: [ROOT]/includes/acp/acp_users.php
LINE: 232
CALL: user_delete()

FILE: [ROOT]/includes/functions_module.php
LINE: 684
CALL: acp_users->main()

FILE: [ROOT]/adm/index.php
LINE: 81
CALL: p_master->load_active()

Je sais qu'il y a eu une bêtise faite. On a voulu supprimer une bonne centaine de membres (qui étaient en fait des bots qu'on avait bannis) via une requête SQL directement sur le serveur. C'était le 30 juillet... donc difficile de se dire maintenant qu'on devrait restaurer la base de données

Je me demandais s'il y a un moyen de « réparer » la table des membres ? Ou du moins, permettre au panel admin de finaliser la suppression des membres proprement pour que cette table soit correctement mise à jour ?

J'imagine qu'il manque des détails, donc n'hésitez pas à m'en demander. Je suis néophyte sur la gestion de serveur / base de données.

Merci d'avance !

[cabot]

Hello,

Alors comme j'ai des connaissances plus que limitées en tripatouillage de bases de données, je me suis permis de me faire aider pour t'aider.

L'erreur que tu obtiens concerne cette requête qui fait partie de la méthode user_delete()
Lorsqu'un utilisateur est supprimé en conservant ses messages, elle remplace son identifiant par celui du compte ANONYMOUS (user_id = 1) dans les sujets dont il était l'auteur, change le nom du premier auteur affiché par le nom d'utilisateur anonyme, et réinitialise la couleur du pseudo.

Le fait que l'erreur 1020 - Record has changed since last read apparaisse à différents endroits (phpbb_users dans un cas, phpbb_topics dans l'autre) ne permet donc pas encore de conclure qu'une table est corrompue.

Avant toute tentative de réparation ou de nouvelle suppression SQL, pourrais-tu donner le résultat de ces trois requêtes ?

Code : Tout sélectionner

SELECT VERSION();

Code : Tout sélectionner

SHOW TABLE STATUS
WHERE Name IN ('phpbb_users', 'phpbb_topics');

Code : Tout sélectionner

CHECK TABLE phpbb_users, phpbb_topics;

Une fois les résultats de ces trois commandes disponibles, on pourra poursuivre avec l'étape suivante et déterminer où chercher.

Je me permets de te suggérer de ne plus supprimer directement de membres avec des requêtes DELETE. La suppression d'un utilisateur par phpBB ne consiste pas uniquement à supprimer sa ligne dans phpbb_users : user_delete() effectue des tas de mises à jour dans les sujets, messages, forums, notifications, trucs et machins, etc. ^^

[Mornagest]

Salut Cabot,

Merci pour ta réponse (même assistée) ; pas évident de trouver de la doc compréhensible pour un humain normalement constitué, et comme toi je n'y connais quasiment rien...

Voici le résultat des requêtes :

Code : Tout sélectionner

MariaDB [(none)]> select version();
+--------------------------------------+
| version()                            |
+--------------------------------------+
| 11.8.6-MariaDB-0+deb13u1 from Debian |
+--------------------------------------+
1 row in set (0,000 sec)

Code : Tout sélectionner

MariaDB [mabase]> SHOW TABLE STATUS WHERE Name IN ('phpbb_users', 'phpbb_topics');
+--------------+--------+---------+------------+-------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-------------+----------+----------------+---------+------------------+-----------+
| Name         | Engine | Version | Row_format | Rows  | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time         | Check_time | Collation   | Checksum | Create_options | Comment | Max_index_length | Temporary |
+--------------+--------+---------+------------+-------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-------------+----------+----------------+---------+------------------+-----------+
| phpbb_topics | InnoDB |      10 | Dynamic    | 20151 |            287 |     5783552 |               0 |      6062080 |   4194304 |          35446 | 2026-09-01 21:29:18 | 2026-09-23 22:15:47 | NULL       | utf8mb3_bin |     NULL |                |         |                0 | N         |
| phpbb_users  | InnoDB |      10 | Dynamic    |  5449 |           1181 |     6438912 |               0 |       655360 |   4194304 |          17322 | 2026-09-01 15:28:32 | 2026-09-23 22:15:48 | NULL       | utf8mb3_bin |     NULL |                |         |                0 | N         |
+--------------+--------+---------+------------+-------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-------------+----------+----------------+---------+------------------+-----------+

Code : Tout sélectionner

MariaDB [mabase]> CHECK TABLE phpbb_users, phpbb_topics;
+--------------------------------+-------+----------+----------+
| Table                          | Op    | Msg_type | Msg_text |
+--------------------------------+-------+----------+----------+
| mabase.phpbb_users  | check | status   | OK       |
| mabase.phpbb_topics | check | status   | OK       |
+--------------------------------+-------+----------+----------+

Oui, tout à fait d'accord concernant le fait de ne plus utiliser de requête MySQL pour supprimer des utilisateurs ; j'ai bien compris que ça me fichait dans une misère pas possible...

Merci pour ton aide !

[cabot]

Apparemment pas de corruption de table visible, du coup on va verifier si le compteur user_posts correspond au nombre de messages présents dans phpbb_posts en faisant directement les requêtes (on ne modifie toujours rien ^^).

Code : Tout sélectionner

SELECT user_id, username, user_posts FROM phpbb_users WHERE user_id = SUSHI;

Code : Tout sélectionner

SELECT COUNT(*) AS posts FROM phpbb_posts WHERE poster_id = SUSHI;

Où SUSHI correspond à l'ID de l'utilisateur.

Si par exemple user_posts = 0 et posts > 0, les DELETE pourraient avoir laissé le compteur user_posts désynchro du nombre réel de message.

PS : les copaings violets et verts qui maîtrisent tout ce bouzin SQL, disez-moi si je me goure.

[Mornagest]

Merci pour ta réponse

Je suis confronté à une erreur toute simple mais qui m'inquiète un peu :

Code : Tout sélectionner

MariaDB [mabase]> SELECT user_id, username, user_posts FROM phpbb_users WHERE user_id = Mornagest;
ERROR 1054 (42S22): Unknown column 'Mornagest' in 'WHERE'

Code : Tout sélectionner

MariaDB [mabase]> SELECT COUNT(*) AS posts FROM phpbb_posts WHERE poster_id = Mornagest;
ERROR 1054 (42S22): Unknown column 'Mornagest' in 'WHERE'

Je suis évidemment censé y apparaître ^^

edit : ok. En fait, l'ID n'est pas le pseudo mais le n° du membre... désolé

Code : Tout sélectionner

MariaDB [mabase]> SELECT user_id, username, user_posts FROM phpbb_users WHERE user_id = 17321;
+---------+-------------+------------+
| user_id | username    | user_posts |
+---------+-------------+------------+
|   17321 | ParkerBlair |          0 |
+---------+-------------+------------+

Code : Tout sélectionner

MariaDB [mabase]> SELECT COUNT(*) AS posts FROM phpbb_posts WHERE poster_id = 17321;
+-------+
| posts |
+-------+
|     0 |
+-------+

Ce résultat est cohérent : c'est un « membre » dont le compte n'a pas encore été activé. Je souhaitais l'effacer directement puisque je suis certain que c'est un spammeur.

[cabot]

Pour le coup c'est pas vraiment concluant sur un compte non activé, il faudrait que tu fasses les requêtes sur un compte qui provoque l'erreur 1020. :/

[sylver35]

Bonjour,

En fait, tout cela est de la tentative de tripatouillage de bdd suite à une grosse suppression d'utilisateurs à la hussarde directement dans la bdd

Donc, stop !
La cause de l'erreur en cours, c'est que ces utilisateurs supprimés ont créé des messages et des sujets qui eux, n'ont pas été supprimés

Solutions :
il y a deux chemins possibles.

- En un, c'est la reprise de la dernière sauvegarde avant le chaos, tout ce qui a été fait depuis disparaitra.

- En deux, c'est de traquer tous les sujets et messages postés par ces fantômes et de les supprimer.
Mais attention, pas dans la bdd mais uniquement dans phpBB, sinon le problème sera empiré !

[Mornagest]

Pour le coup c'est pas vraiment concluant sur un compte non activé, il faudrait que tu fasses les requêtes sur un compte qui provoque l'erreur 1020. :/

J'ai essayé de supprimer plusieurs comptes via le panel admin et tous provoquent l'erreur 1020, dont celui-ci

Je tente avec un autre :

Code : Tout sélectionner

MariaDB [mabase]> SELECT user_id, username, user_posts FROM phpbb_users WHERE user_id = 16795;
+---------+-----------+------------+
| user_id | username  | user_posts |
+---------+-----------+------------+
|   16795 | Mornatest |          0 |
+---------+-----------+------------+
1 row in set (0,007 sec)

MariaDB [mabase]> SELECT COUNT(*) AS posts FROM phpbb_posts WHERE poster_id = 16795;
+-------+
| posts |
+-------+
|     0 |
+-------+

Et c'est un compte de test que je n'arrive pas à supprimer pour autant j'ai pourtant supprimé certains de ses messages de test en passant normalement par la fonction Supprimer dans les sujets.

@sylver35 : oui, tout à fait. Je plaide non coupable, c'est un autre admin qui a effectué la tâche sans penser que ça pourrait avoir de telles répercussions...

Une restauration de la base ne me paraît pas trop possible : ça date de toute fin juillet, ça ferait deux mois perdus :/

Je peux tenter de traquer les fantômes, avec le journal d'administration, je vais essayer de retrouver les comptes supprimés et voir s'ils avaient des sujets ou messages liés.

Merci en tout cas pour votre aide !  
 
Ajouté 15 minutes 15 secondes après :
 
 Bon, je pense que ça va être plus compliqué que ça. Je me permets de recopier le message que l'admin avait posté pour cette requête SQL, ça vous donnera des billes pour comprendre ce qui provoque ces soucis.

Trouver l’identifiant du groupe des bannis :

Code : Tout sélectionner

SELECT group_id FROM phpbb_groups WHERE group_name = 'Les Bannis';

(réponse : 130)

Lister les identifiants des utilisateurs bannis :

Code : Tout sélectionner

SELECT user_id FROM phpbb_user_group WHERE group_id = 130;

Comme je ne sais pas construire des commandes SQL complexes, je récupère ici cette liste directement dans le shell interactif bash (donc pas depuis le shell SQL) :

Code : Tout sélectionner

mariadb --batch --execute='SELECT user_id FROM phpbb_user_group WHERE group_id = 130;' mabase | tail --lines=+2

Le tail --lines=+2 sert à virer la première ligne indiquant le nom de la colonne ("user_id") dans les résultats.


Bon, arrivé ici je sens qu’on va enchaîner les mariadb --batch --execute, alors autant simplifier ça. Je viens donc d’écrire un court script /usr/local/sbin/run-sql-command avec le contenu suivant :

Code : Tout sélectionner

#!/bin/sh
set -o errexit

DB_NAME=mabase
SQL_COMMAND=$1

mariadb --batch --execute="$SQL_COMMAND" "$DB_NAME" | tail --lines=+2

exit 0

À l’utilisation ça donne, pour remplacer la commande plus haut :

Code : Tout sélectionner

run-sql-command "SELECT user_id FROM phpbb_user_group WHERE group_id = 130"

Reprenons, avec ce nouveau script pour simplifier un peu. On peut l’utiliser pour récupérer la liste des utilisateurs bannis, puis boucler dessus pour ne conserver que ceux qui n’ont aucun message :

Code : Tout sélectionner

for user_id in $(run-sql-command "SELECT user_id FROM phpbb_user_group WHERE group_id = 130"); do
test -z "$(run-sql-command "SELECT post_id FROM phpbb_posts WHERE poster_id = $user_id;")" && echo $user_id
done

Partant d’une liste de 348 comptes bannis, ce filtrage nous fait descendre à 283 comptes bannis sans aucun message posté.

Ne reste plus qu’à remplacer la commande d’affichage par une suppression du compte :

Code : Tout sélectionner

for user_id in $(run-sql-command "SELECT user_id FROM phpbb_user_group WHERE group_id = 130"); do
test -z "$(run-sql-command "SELECT post_id FROM phpbb_posts WHERE poster_id = $user_id;")" &&
run-sql-command "DELETE from phpbb_user_group WHERE user_id = $user_id;" &&
run-sql-command "DELETE from phpbb_users WHERE user_id = $user_id;"
done

Ça laisse probablement des traces de l’utilisateur dans certaines tables de la base de donnée, mais ça devrait suffire pour le faire disparaître de toutes les interfaces du forum.

[cabot]

Il semblerait que Crizzo t'avait correctement orienté dans cette réponse
https://www.percona.com/blog/mariadbs-s ... -it-fixes/

Peux-tu donner le résultat de cette requête ?

Code : Tout sélectionner

SELECT @@innodb_snapshot_isolation;

[Mornagest]

C'est très possible mais pour être honnête, je n'ai pas compris le contenu du lien

Code : Tout sélectionner

MariaDB [(none)]> SELECT @@innodb_snapshot_isolation;
+-----------------------------+
| @@innodb_snapshot_isolation |
+-----------------------------+
|                           1 |
+-----------------------------+

 
 
Ajouté 23 minutes 1 seconde après :
 
 https://mariadb.com/docs/server/server- ... -variables

innodb_snapshot_isolation

Description: Whether or not to use snapshot isolation (write/write conflict detection within InnoDB).
If enabled (set to ON), an error DB_RECORD_CHANGED (HA_ERR_RECORD_CHANGED, ER_CHECKREAD) is raised if an attempt is made to acquire a lock on a record that does not exist in the current read view. This error is treated in the same way as a deadlock, and the transaction is rolled back. This affects the default isolation level, REPEATABLE READ.
In MariaDB 11.8 and later, changes to snapshot handling may affect how conflicts are detected in transactions that use the Repeatable Read isolation level. Specifically, DELETE and UPDATE statements can cause a rollback of the transaction, and return with ERROR 1020. This occurs when a transaction tries to modify rows using a snapshot that is inconsistent with the database's current state as a result of simultaneous modifications. In other words, this variable is designed to prevent non-repeatable reads and anomalies (like lost updates) by rejecting UPDATE or DELETE operations on rows that were modified by a concurrent transaction after the current transaction's snapshot was taken.

Command line: --innodb-snapshot-isolation={0|1}

Scope: Global, Session

Dynamic: Yes

Data Type: boolean

Default Value: ON (>= MariaDB 11.6.2), OFF (<= MariaDB 11.6.1)

Introduced: MariaDB 10.6.18, MariaDB 10.11.8, MariaDB 11.0.6, MariaDB 11.1.5, MariaDB 11.2.4, MariaDB 11.4.2



Donc effectivement, c'est normal que j'aie cette erreur puisqu'une modification a été effectuée depuis une autre source qu'une requête SQL.

Désactiver ce module (je ne sais pas si ça s'appelle comme ça) va sans doute me permettre de supprimer les utilisateurs quand j'en aurai besoin, mais quid des erreurs actuellement présentes ? Elles vont probablement rester et je ne sais pas s'il est possible de les retrouver pour (on peut rêver) les corriger.


edit : ok, ça a marché en désactivant ce module, j'ai pu supprimer un membre (compte de test, celui que je n'arrivais pas à supprimer il y a quelques jours).

Reste à savoir ce que je peux faire pour réparer la table et si je peux garder le module inactif ?


edit bis : eh ben non, j'ai de nouveau la même erreur en supprimant un spammeur qui a quelques messages au compteur, et dont je souhaite supprimer également les messages en même temps. Mince... :'(

[Mornagest]

Je remonte juste le sujet car j'ai édité mon précédent message et je ne sais pas si ce n'est pas passé inaperçu

[cabot]

Erf, je t'avouerai que je n'ai pas plus d'idées que ça. Sans compter qu'avec la validation des styles chez .com suite aux mises à jour, j'ai pas eu vraiment le temps de m'éparpiller.
Je vais essayer de continuer à fouiner.

[Mornagest]

D'acc, merci pour ton aide, déjà

[Mornagest]

Il semblerait que le paramètre innodb_snapshot_isolation activé soit bien responsable de mes soucis. Le problème que j'avais était de pouvoir désactiver ce paramètre de manière permanente et pas uniquement pour la session en cours, sinon, par défaut, il se rétablit...

Donc j'ai créé un fichier /etc/mysql/mariadb.conf.d/99-innodb_snapshot_isolation.cnf qui contient :

Code : Tout sélectionner

[mysqld]
innodb_snapshot_isolation = 'OFF'

Après redémarrage de MySQL :

Code : Tout sélectionner

systemctl restart mysql.service

Le paramètre est bien désactivé et je peux désormais supprimer un membre et ses messages sans avoir ce retour d'erreur de MySQL.

Merci pour votre aide !