SQLSTATE[HY000]: General error: 1835 Malformed communication packet on LARAVEL

后端 未结 14 1594
温柔的废话
温柔的废话 2020-11-29 09:45

Suddenly got

SQLSTATE[HY000]: General error: 1835 Malformed communication packet (SQL: select * from tb_users where (username =

相关标签:
14条回答
  • 2020-11-29 10:20

    This issue started happening for a lot of people after the recent MariaDB update yesterday after Updating MariaDB to v10.3.26 (and 10.2.35). This issue is already addressed here: https://jira.mariadb.org/browse/MDEV-24121

    As of now, these are the only known solutions:

    1. Upgrade your PHP to 7.3: It appears these errors are shown on sites using php < 7.3. So upgrading your site's PHP to version 7.3 or 7.4 should resolve the issue.

    CONS: Not a lot of applications can be easily upgraded to php 7.3 just like that. Sometimes you might need to update your platform, rewrite some codes or check all dependancies and see if they all work on 7.3. This may not be a quick fix for a lot of matured applications.

    2. Downgrade MariaDB: This is a temporary fix since downgrading MariaDB will set it back to the previous state.

    CONS: Downgrading MariaDB is not an easy thing to do with a click of a button from cpanel. You might need help from a network engineer to do the downgrade for you. After that you also might need to do yum-locking the MariaDB packages in order to avoid it from being updated until they're patched.

    3. Add 'options' => [PDO::ATTR_EMULATE_PREPARES => true] to Database Config: This has been suggested in some answers which might solve 1 issue but open up a lot of other issues.

    CONS: Adding the above to the database config file solved 1 problem for me, but it also opened a whole lot of other queries that were failing, database inserts where failing, etc. So I would not recommend this fix at all.

    4. Wait for MariaDB Update: The next update should address this issue.

    CONS: We don't know how long it will take to get an update that fixes this issue for older versions of PHP. It could be even days and some applications might not be able to wait that long.

    So all in all, these are the only options I can see as of now. Just hoping there is a fix for it soon.

    Short Term Fix: Out of all, downgrading MariaDB seems to be the only easy (sorta) temporary fix for me considering my application needs a lot of work to be ready for php 7.3. I downgraded MariaDB to 10.2.34 and locked it and the error no longer appears.

    Long Term Fix: It is better to eventually get your application ready for php 7.3 and upgrade to that so MariaDB newer version also will not complain.

    0 讨论(0)
  • 2020-11-29 10:21

    Mariadb has a update for php 7.2 that fix this issue, just update the server:

    sudo apt update
    sudo apt upgrade
    
    0 讨论(0)
  • 2020-11-29 10:21

    Upgrade php 7.2 to php7.4 best way for me.

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

    sudo apt update

    sudo apt install php7.4-fpm php7.4-common 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 reload apache2

    sudo systemctl status php7.4-fpm `

    Fixed

    0 讨论(0)
  • 2020-11-29 10:23

    All my Laravel apps running PHP 7.2 had this error but those running on PHP 7.3 did not. So I changed the PHP version to 7.3 and the problem was fixed. (Running Laravel 7)

    0 讨论(0)
  • 2020-11-29 10:23

    MariaDB just released an upgrade that fixes the issue for those who cannot run their application on PHP >= 7.3, source: https://mariadb.org/mariadb-10-5-8-10-4-17-10-3-27-and-10-2-36-now-available/

    0 讨论(0)
  • 2020-11-29 10:24

    I'm on Ubuntu 20 (focal), note my repo you'll need to change it depending on if your on 16 (xenial), 18 (bionic) or whatever

    I don't like the options fix in Laravel with the risk it could corrupt data, and I can't upgrade PHP to 7.2+ without a lot of work so for me I downgraded a version.

    Going from 10.3.26 -> 10.3.25 without restoring all the data from a dump is not recommended but I had no choice, and it appears nothing bad happened.

    # 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
    
    0 讨论(0)
提交回复
热议问题