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.
-
Connect to the Plesk server via SSH.
-
Switch to the directory with daily dumps:
# cd /var/lib/psa/dumps
-
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.
- where
-
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
-
-
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
-
Connect to the Plesk server via RDP.
-
Switch to the directory with daily dumps:
C:\> cd %plesk_dir%Mysql\Backup
-
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 -
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
-
Access Plesk.
Comments
4 comments
Hi,
I got:
ERROR 1265 (01000) at line 3504: Data truncated for column 'event_type' at row 8
What should I do?
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.
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?
I have the same error from a plesk upgrade. Actively looking to switch panels, this is just nuts.
Please sign in to leave a comment.