SQLSTATE [HY000]: Erreur générale: 1835 Paquet de communication mal formé sur LARAVEL

J'ai trouvé la solution. Je ne sais pas si c'est permanent ou temporaire:

'mysql' => [
            'driver' => 'mysql',
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            'collation' => 'utf8mb4_unicode_ci',
            'prefix' => '',
            'strict' => false,
            'engine' => null,
            **'options'   => [PDO::ATTR_EMULATE_PREPARES => true]**
        ],

sois sûr que

'options' => [PDO :: ATTR_EMULATE_PREPARES => true]

existent sur la connexion mysql.

Également rencontré ce problème après la mise à jour de mariadb pendant la nuit. Le déclassement de mariadb a résolu le problème pour moi.

https://support.cpanel.net/hc/en-us/articles/360056772334

Toutes mes applications Laravel exécutant PHP 7.2 avaient cette erreur, mais celles fonctionnant sous PHP 7.3 n'en avaient pas. J'ai donc changé la version PHP en 7.3 et le problème a été résolu. (Exécution de Laravel 7)

Après de nombreuses solutions de contournement, j'ai essayé aujourd'hui les solutions que j'ai obtenues

1- mise à niveau vers php 7.3 ou 7.4
(de nombreux sites Web seront indisponibles après les mises à niveau de php)

2- Rétrograder vers la version mineure (mariadb 10.4.16 vers 10.4.15)

yum downgrade MariaDB-server MariaDB-common MariaDB-shared MariaDB-client MariaDB-compat MariaDB-devel    

de toute façon, ce problème est ouvert en tant que bogue pour la mise à jour de Mariadb la nuit dernière et ils n'ont poussé aucune correction pour le moment, la solution ci-dessus n'est que les 2 façons de résoudre le problème, cela fonctionne avec moi sur le déclassement de mariadb de 10.4.16 à 10.4.15 ( déclassement mineur)

Ce problème a commencé à se produire pour beaucoup de gens après la récente mise à jour de MariaDB hier après la mise à jour de MariaDB vers la v10.3.26 (et 10.2.35). Ce problème est déjà traité ici: https://jira.mariadb.org/browse/MDEV-24121

Pour l'instant, ce sont les seules solutions connues:

1. Mettez à jour votre PHP vers la version 7.3: Il semble que ces erreurs apparaissent sur les sites utilisant php <7.3. Donc, la mise à niveau de PHP de votre site vers la version 7.3 ou 7.4 devrait résoudre le problème.

INCONVÉNIENTS: Peu d'applications peuvent être facilement mises à niveau vers php 7.3 comme ça. Parfois, vous devrez peut-être mettre à jour votre plate-forme, réécrire certains codes ou vérifier toutes les dépendances et voir si elles fonctionnent toutes sur 7.3. Ce n'est peut-être pas une solution miracle pour de nombreuses applications mûres.

2. Rétrograder MariaDB: Il s'agit d'une correction temporaire car la rétrogradation de MariaDB le remettra à son état précédent.

CONTRE: La rétrogradation de MariaDB n'est pas une chose facile à faire avec un clic sur un bouton de cpanel. Vous aurez peut-être besoin de l'aide d'un ingénieur réseau pour effectuer la rétrogradation à votre place. Après cela, vous devrez peut-être également verrouiller les paquets MariaDB afin d'éviter qu'ils ne soient mis à jour jusqu'à ce qu'ils soient corrigés.

3. Ajoutez 'options' => [PDO::ATTR_EMULATE_PREPARES => true] à la configuration de la base de données: cela a été suggéré dans certaines réponses qui pourraient résoudre 1 problème mais ouvrir de nombreux autres problèmes.

INCONVÉNIENTS: L'ajout de ce qui précède au fichier de configuration de la base de données a résolu 1 problème pour moi, mais cela a également ouvert beaucoup d'autres requêtes qui échouaient, les insertions de base de données échouaient, etc. Je ne recommanderais donc pas du tout ce correctif.

4. Attendez la mise à jour de MariaDB: la prochaine mise à jour devrait résoudre ce problème.

CONTRE: Nous ne savons pas combien de temps il faudra pour obtenir une mise à jour qui résout ce problème pour les anciennes versions de PHP. Cela peut prendre même des jours et certaines applications ne peuvent pas attendre aussi longtemps.

Donc, dans l'ensemble, ce sont les seules options que je peux voir pour le moment. J'espère juste qu'il y aura bientôt un correctif.

Correction à court terme: Surtout, la rétrogradation de MariaDB semble être la seule solution temporaire facile (en quelque sorte) pour moi, étant donné que mon application a besoin de beaucoup de travail pour être prête pour php 7.3. J'ai rétrogradé MariaDB à 10.2.34 et l'ai verrouillé et l'erreur n'apparaît plus.

Correctif à long terme: Il est préférable de préparer éventuellement votre application pour php 7.3 et de la mettre à niveau pour que la nouvelle version de MariaDB ne se plaigne pas non plus.

Le correctif officiel est enfin disponible et vous pouvez trouver les détails sur le lien:
https://support.cpanel.net/hc/en-us/articles/360056772334/comments/360005577354

Pour le réparer rapidement, connectez-vous simplement via SSH et exécutez

yum versionlock clear
/scripts/upcp

Pour les utilisateurs qui ont appliqué la solution de contournement précédente impliquant la rétrogradation de MariaDB. Assurez-vous de déverrouiller MariaDB pour vous assurer qu'elle continue de recevoir les mises à jour appropriées:

sudo /scripts/autorepair fix_mariadb_show_grants_roles

Mettez à jour php 7.2 vers php7.4 le meilleur moyen pour moi.

`sudo add-apt-repository ppa: ondrej / php

mise à jour sudo apt

sudo apt installer php7.4-fpm php7.4-commun php7.4-mysql php7.4-xml php7.4-xmlrpc php7.4-curl php7.4-gd php7.4-imagick php7.4-cli php7. 4-dev php7.4-imap php7.4-mbstring php7.4-soap php7.4-zip php7.4-bcmath -y

sudo a2enmod proxy_fcgi setenvif

sudo a2enconf php7.4-fpm

sudo systemctl recharger apache2

sudo systemctl status php7.4-fpm `

Fixé

Je suis sur Ubuntu 20 (focal), notez mon repo, vous devrez le changer selon que vous soyez sur 16 (xenial), 18 (bionic) ou autre

Je n'aime pas la correction des options dans Laravel avec le risque de corrompre les données, et je ne peux pas mettre à niveau PHP vers 7.2+ sans beaucoup de travail, donc pour moi, j'ai rétrogradé une version.

Passer de 10.3.26 -> 10.3.25 sans restaurer toutes les données d'un vidage n'est pas recommandé mais je n'avais pas le choix, et il semble que rien de mal ne se soit produit.

# stop the database

service mariadb stop

# list packages installed

dpkg -l | grep mariadb 

# remove whatever you have or the install will complain about dependencies or broken packages, you need to remove all the mariadb packages

apt remove mariadb-server-core-10.3 
apt remove mariadb-server-10.3
apt remove mariadb-server-10.2
apt remove mariadb-server-10.1

# pin the repo to v10.3.25, remember to remove any conflicting sources you have in /etc/apt/sources.list

apt-get install software-properties-common
apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'
add-apt-repository 'deb [arch=amd64,arm64,ppc64el] http://archive.mariadb.org/mariadb-10.3.25/repo/ubuntu/ focal main'

# install the old version

apt install mariadb-server

# start it back up

service mariadb start

Mise à jour de la version php ** (7.2 à 7.3) ** à l'intérieur de cpanel pour mon sous-domaine.

Doit donner tout le privilège à l'utilisateur de la base de données sélectionné.

Cela a fonctionné pour moi.

Ce qui a fonctionné pour moi était de mettre à niveau la version PHP sur le sous-domaine de 7.2 à 7.3. Je n'ai rien changé dans la configuration de la base de données comme cela a été suggéré dans certaines réponses.

Ce message d'erreur soudain est causé par une mise à jour du client MariaDB, qui semble incompatible avec la version PHP 7.2 de php-mysqlnd ; la version 10.2.35 casse, mais la version 10.2.34 fonctionne toujours. Avec yum ou dnf on peut facilement revenir aux versions précédentes, par exemple. avec:

su
yum history
yum history undo 440

Le paramètre temporaire enabled=0 dans /etc/yum.repo.d/mariadb.repo peut également avoir un sens.
La mise à niveau vers PHP 7.3 pourrait encore être la meilleure option (tant qu'elle est disponible).

Une version d'urgence de MariaDB 10.5.8, 10.4.17, 10.3.27 et 10.2.36 est maintenant disponible et a été publiée pour résoudre spécifiquement cette incompatibilité de protocole dans les anciennes versions de PHP et PDO.

MariaDB vient de publier une mise à jour qui corrige le problème pour ceux qui ne peuvent pas exécuter leur application sur PHP> = 7.3, source: https://mariadb.org/mariadb-10-5-8-10-4-17-10-3- 27-et-10-2-36-maintenant-disponible /

Mariadb a une mise à jour pour php 7.2 qui corrige ce problème, il suffit de mettre à jour le serveur:

sudo apt update
sudo apt upgrade