Articles in this section

See more

Unable to access Plesk: Table 'psa.<table_name>' doesn't exist

Avatar
Kuzma Ivanov
Updated
Follow
Plesk for Windows Plesk for Linux kb: technical ABT: Group A

Applicable to:

  • Plesk for Linux
  • Plesk for Windows

Symptoms

Plesk is not accessible with one of the following error messages in a web-browser:

PLESK_INFO: DB query failed: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'psa.<table_name>' doesn't exist, query was: DESCRIBE `sessions`

PLESK_INFO: ERROR: PleskMainDBException
MySQL query failed: Unknown column 'id' in 'field list'

PLESK_INFO: Call to a member function getSkinUrl() on null (SkinUrl.php:18)

PLESK_INFO: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'psa.sessioncontexts' doesn't exist

PLESK_INFO: ERROR: Plesk\Exception\Database: DB query failed: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'psa.sessions' doesn't exist, query was: DESCRIBE `sessions`

PLESK_INFO: DB query failed: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'psa.misc' doesn't exist, query was: replace into misc (param, val) values(:param, :val)

Cause

The Plesk 'psa' database is corrupted.

Resolution

Restore the Plesk 'psa' system database from the Plesk daily dump.

 

For Plesk on Linux

 

  1. Connect to the Plesk server via SSH.

  2. Switch to the directory with daily dumps:

    # cd /var/lib/psa/dumps

  3. List all available Plesk daily dumps:

    # ls -l mysql.daily*
    -rw------- 1 root root 236253 Feb 3 01:51 mysql.daily.dump.0.gz
    -rw------- 1 root root 229653 Feb 2 01:48 mysql.daily.dump.1.gz
    -rw------- 1 root root 222485 Feb 1 01:56 mysql.daily.dump.2.gz

    • where mysql.daily.dump.0.gz is the most recent daily dump.

  4. Restore the 'psa' database from the most recent daily dump. In this example, the 'psa' database is being restored from mysql.daily.dump.0.gz:

    # zcat mysql.daily.dump.0.gz | sed -n '/-- Current Database: `psa`/,/-- Current Database:*/p' | MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -uadmin --default-character-set=utf8

    Note: Remove tables from /var/lib/mysql/psa if the same set of tables is mentioned in the error all the time

    • If restoration of the psa database fails with the error below, check this KB article:

      ERROR 1265 (01000) at line 3375: Data truncated for column 'event_type' at row 2362

  5. Access Plesk.

    If Plesk is still not accessible, try to restore the 'psa' database from an earlier Plesk daily dump:

    # zcat mysql.daily.dump.1.gz | sed -n '/-- Current Database: `psa`/,/-- Current Database:*/p' | MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -uadmin --default-character-set=utf8

 

For Plesk on Windows Server

 

  1. Connect to the Plesk server via RDP.

  2. Switch to the directory with daily dumps:

    C:\> cd %plesk_dir%Mysql\Backup

  3. List all available Plesk daily dumps with the 'psa' database sorted by date (newest first):

    C:\> dir psa* /O:-D

    Directory of C:\Program Files (x86)\Plesk\MySQL\Backup

    03/29/2019 08:33 PM 502,879 psa-20190329203301.sql
    03/28/2019 08:33 PM 468,888 psa-20190328203301.sql
    03/27/2019 08:33 PM 468,888 psa-20190327203301.sql

  4. Restore the 'psa' database from the latest available daily dump. In this example, we are restoring the dump from 03/29/2019:

    C:\> plesk db < psa-20190329203301.sql

  5. Access Plesk.

 

 

 

Comments

3 comments

Sort by Date Votes
  • Avatar
    Ehud Ziegelman

    Hi,

    I got:
    ERROR 1265 (01000) at line 3504: Data truncated for column 'event_type' at row 8

    What should I do?

     

    1
    Comment actions Permalink
  • Avatar
    Sean Bremner

    I'm having the exact same issue as Ehud Zielgelman mentioned above.

    ERROR 1265 (01000) at line 7901: Data truncated for column 'event_type' at row 1

    This has occurred after I've updated our MariaDB from 10.7 to 10.11 & needed to reinstall the Plesk packages that were removed as dependencies of MariaDB.

    If you've managed to fix this yourself Ehud, or if anyone else knows the cause & a solution I'd truly appreciate it so that I can get our server back up & running again.

    0
    Comment actions Permalink
  • Avatar
    Ehud Ziegelman (Edited )

    Hi Sean Bremner,

    In our case, the issue arose, to the best of my understanding, from Plesk CHANGING the data structure of the Plesk Fire Wall, possibly from IPTABLES to IPSET. 

    IPSET is the data structure supporting blocking of countries recently introduced by Plesk.

    That broke our instance, coming to update an old Plesk fire wall installation, after a Plesk version upgrade.

    What I had to do was to restore an old instance from an AWS snap shot, REMOVE the Plesk Fire Wall (specific configuration and the service as well), update the Plesk version again, and install the NEW Plesk Fire Wall and configure it from scratch. 

    IMHO, Plesk was not doing well regarding this issue, nor preciously with in my opinion bad coding of the Plesk Fire Wall.

     

    As you can see, I did not get a Plesk response to my comment.

    Kuzma Ivanov, may I ask if you would like to comment?

    0
    Comment actions Permalink

Please sign in to leave a comment.

Have more questions? Submit a request

Related articles