Wordpress - changed table prefix - You Do Not Have Sufficient Permissions To Access This Page

If you can't login to Wordpress admin, or rather, you are logged in, but can't do anything, like you've lost all permissions, you have probably changed the table prefix in your wordpress config.

To remedy this, you also need to change a few rows in MySQL:

In the table usermeta

UPDATE  `wordpress`.`NEWPREFIX_usermeta` SET  `meta_key` =  'NEWPREFIX_capabilities' WHERE  `NEWPREFIX_usermeta`.`meta_key` = 'OLDPREFIX_capabilities';
UPDATE  `wordpress`.`NEWPREFIX_usermeta` SET  `meta_key` =  'NEWPREFIX_user_level' WHERE  `NEWPREFIX_usermeta`.`meta_key` = 'OLDPREFIX_user_level';
UPDATE  `wordpress`.`NEWPREFIX_usermeta` SET  `meta_key` =  'NEWPREFIX_user-settings' WHERE  `NEWPREFIX_usermeta`.`meta_key` = 'OLDPREFIX_user-settings';
UPDATE  `wordpress`.`NEWPREFIX_usermeta` SET  `meta_key` =  'NEWPREFIX_user-settings-time' WHERE  `NEWPREFIX_usermeta`.`meta_key` = 'OLDPREFIX_user-settings-time';
UPDATE  `wordpress`.`NEWPREFIX_usermeta` SET  `meta_key` =  'NEWPREFIX_dashboard_quick_press_last_post_id' WHERE  `NEWPREFIX_usermeta`.`meta_key` = 'OLDPREFIX_dashboard_quick_press_last_post_id';

In the table options

UPDATE `wordpress`.`NEWPREFIX_options` SET option_name = 'NEWPREFIX_user_roles' WHERE option_name = 'OLDPREFIX_user_roles'

When to use MyISAM or InnoDB

When designing a database in MySQL one of the most common questions one can ask themselves is, is it better to use MyISAM or InnoDB engines for tables. There are other types of engines, but these are most common. There are also many articles on this topic, but I found that it boils down to a few simple things:

If you need FULLTEXT search, you need to use MyISAM.

If you need Foregin key support (for cascading and such), or you need to support transactions, you need to use InnoDB.



In general, if you do not need any of the special features, it's better to use MyISAM as it performs better (faster and more disk-friendly) for web applications.


There are other features that are not present in other engines as well.

 MyISAM Storage Engine Features

Storage limits	256TB	Transactions	No	Locking granularity	Table
MVCC	No	Geospatial data type support	Yes	Geospatial indexing support	Yes
B-tree indexes	Yes	T-tree indexes	No	Hash indexes	No
Full-text search indexes	Yes	Clustered indexes	No	Data caches	No
Index caches	Yes	Compressed data	Yes[a]	Encrypted data[b]	Yes
Cluster database support	No	Replication support[c]	Yes	Foreign key support	No
Backup / point-in-time recovery[d]	Yes	Query cache support	Yes	Update statistics for data dictionary	Yes
[a] Compressed MyISAM tables are supported only when using the compressed row format. Tables using the compressed row format with MyISAM are read only. [b] Implemented in the server (via encryption functions), rather than in the storage engine. [c] Implemented in the server, rather than in the storage engine. [d] Implemented in the server, rather than in the storage engine.

Key Advantages of InnoDB

InnoDB is a high-reliability and high-performance storage engine for MySQL. Key advantages of InnoDB include:

• Its design follows the ACID model, with transactions featuring commit, rollback, and crash-recovery capabilities to protect user data.
• Row-level locking (without escalation to coarser granularity locks) and Oracle-style consistent reads increase multi-user concurrency and performance.
• InnoDB tables arrange your data on disk to optimize common queries based on primary keys. Each InnoDB table has a primary key index called the clustered index that organizes the data to minimize I/O for primary key lookups.
• To maintain data integrity, InnoDB also supports FOREIGN KEY referential-integrity constraints.
• You can freely mix InnoDB tables with tables from other MySQL storage engines, even within the same statement. For example, you can use a join operation to combine data from InnoDB and MEMORY tables in a single query.
• InnoDB has been designed for CPU efficiency and maximum performance when processing large data volumes.

PHP :: Advice on using count()

I may be a little late realising this, but a few dozen thousand lines of PHP code in, it's better late than never.

Let's look at example #1 on count() manual
http://php.net/manual/en/function.count.php

$result = count(null); // $result == 0
$result = count(false); // $result == 1


Does this strike you as a bit odd? Why the hell should count(0) or count(false) be equal to 1?

Well strangely enough, that's how it is. So for example, if you wrote a mysql_query() wrapper where you return false if the query fails and if you expect an array where you check the number of items, you find out that if the query fails, the count will return 1, and you might get some unexpected results.

Keeping computer security in mind, it's best to avoid count() when just checking if some data is returned.

Alternatives are empty() if checks if a variable contains something other than 0, '0', null, false, array() or ''.

OR, in your wrapper functions, if the query fails, just return NULL!

MySQL not starting when restoring files in /var/lib/mysql

If you get errors like:


120226  1:54:14 [Note] Plugin 'FEDERATED' is disabled.
120226  1:54:14  InnoDB: Initializing buffer pool, size = 8.0M
120226  1:54:14  InnoDB: Completed initialization of buffer pool
120226  1:54:15  InnoDB: Started; log sequence number 0 44233
120226  1:54:15 [ERROR] Event Scheduler: Failed to open table mysql.event
120226  1:54:15 [ERROR] Event Scheduler: Error while loading from disk.
120226  1:54:15 [Note] Event Scheduler: Purging the queue. 0 events
120226  1:54:15 [ERROR] Aborting


120226  1:54:15  InnoDB: Starting shutdown...
120226  1:54:20  InnoDB: Shutdown completed; log sequence number 0 44233
120226  1:54:20 [Note] mysqld: Shutdown complete

or

120226  1:59:18 [Note] Plugin 'FEDERATED' is disabled.

mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)

120226  1:59:18 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.

120226  1:59:18  InnoDB: Initializing buffer pool, size = 8.0M

120226  1:59:18  InnoDB: Completed initialization of buffer pool

120226  1:59:18  InnoDB: Started; log sequence number 0 44233

120226  1:59:18 [ERROR] mysqld: Can't find file: './mysql/host.frm' (errno: 13)

120226  1:59:18 [ERROR] Fatal error: Can't open and lock privilege tables: Can't find file: './mysql/host.frm' (errno: 13)

You need to check the file permissions.

The user and group is mysql:mysql

File permissions are rw for user and group (660)

Solution

chown mysql:mysql -R /var/lib/mysql

chmod 660 -R /var/lib/mysql

MySQL error 1236: Client requested master to start replication from impossible position

Symptoms:
[1236] Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position'

110902 16:47:08 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
110902 16:47:08 [ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position', Error_code: 1236
110902 16:47:08 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000033', position 4621679

on the master
root@dimko:/var/lib/mysql# ls -la mysql-bin.000033
-rw-rw---- 1 mysql mysql 4620018 2011-09-01 13:45 mysql-bin.000033

4620018 is less than 4621679, therefore it's an invalid position.


Causes:
Master server has crashed and the binlog cache has not been flushed to disk. Slave has recieved a new position, did not recieve data, and data gets lost in a crash (however it might have been written to table, but not in binlog).


Solution:
Use this CHANGE MASTER statement on the slave.
CHANGE MASTER TO MASTER_LOG_FILE=[NEXT FILE], MASTER_LOG_POS=4;
SLAVE START;

in my case that would be

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000034', MASTER_LOG_POS=4;
SLAVE START;

I don't know why the master log position needs to be 4 for the new file.

What happens:
When the master server restarts it logs binary changes to a new binlog file, so that we minimize data loss by skipping to the next file (everything from the previous file was written already).

Prevention:
Add this line to my.cnf:

sync_binlog = 1

 With this setting the master server flushes cache in the binlog after every write, so that in case of a crash you can lose one statement at most.