MySQL 5.1 to MySQL 5.6 update causes php-cgi error: PDO issue? I recently performed a MySQL upgrade on Windows Server 2008R2, moving from MySQL 5.1 to MySQL 5.6.22 (Community Edition). The server is currently using PHP 5.3.0.

Things went just fine for all my WordPress installs (no problems on cutover); however, all my Drupal 7 sites are now generating 500 errors (coming from php-cgi.exe via php5ts.dll from what I can tell).

To address concerns about the broad nature of the question, this is the specific Windows event log message:


  Faulting application name: php-cgi.exe, version: 5.3.0.0, time stamp: 0x4a492a25
  Faulting module name: php5ts.dll, version: 5.3.0.0, time stamp: 0x4a4929bb
  Exception code: 0xc0000005
  Fault offset: 0x0015e1b0
  Faulting process id: 0x7bb4
  Faulting application start time: 0x01d01fa8dec6e9a6
  Faulting application path: C:\PHP\php-cgi.exe
  Faulting module path: C:\PHP\php5ts.dll
  Report Id: 2e661541-8b9c-11e4-a303-001b210e0a6a  


I've checked database credentials, time zone defaults, and haven't changed IIS settings, folder permissions, or anything of that nature.

The one difference that stands out is that Drupal uses PDO for access, and I'm wondering if there is a potential issue there with the version being used, since all these sites worked fine with MySQL 5.1.

PDO seems to be showing version 5.0.5-dev (rev 1.3.2.27).

I can't locate anything that leads to identification, troubleshooting or resolution.

(I'm off to try to replicate with just a simple PDO test.)

Has anybody encountered this and/or have documentation that might help isolate/resolve things?

NOTE: The closest I've come is to somebody using PDO drivers for MSSQL (not MySQL) where there was a faulty Drupal layer on top of PDO. Details here - http://forums.iis.net/t/1181446.aspx?PHP+5+3+8+Problems



UPDATE:

Not PDO...

The following example (with real values) works fine.

$dsn = 'mysql:host=localhost;dbname=DBNAME';
$username = 'USER';
$password = 'PASS';
$options = array();

$dbh = new PDO($dsn, $username, $password, $options);

if ($dbh) {

    $stmt = $dbh-&gt;query('SELECT * FROM MYTABLE LIMIT 1');
    $results = $stmt-&gt;fetchAll(PDO::FETCH_ASSOC);

    print_r($results);

}
else {
    echo 'Failed.';
}




UPDATE 2:

I have double checked any options set by the prior install of MySQL 5.1 that might not have been carried over. I realize more things are auto-set and defaults might have changed, which could be part of the issue.

The other issue that might come into play is changing the server collation default from utf8 to utf8mb4 ... It looks like Drupal 7 should support this (discussion, in the framework of Drupal 8 goes back to 2011 - https://www.drupal.org/node/1314214). The tables continue to show ut8 collation, so data should be unaffected.

MySQL 5.6 does introduce explicit_defaults_for_timestamp but I haven't been able to find anything implying it should be an issue either (setting 0/1 results in the same error).
As noted above, the whole thing was resolved by pushing the default character set back to utf8 from the incompatible (for Drupal, but not for WordPress) utf8mb4...

Relevant my.ini settings as follows:

[client]

default-character-set = utf8 # not utf8mb4

[mysql]

default-character-set = utf8 # not utf8mb4

[mysqld]

# REF: http://stackoverflow.com/a/24487309/3174018
collation-server = utf8_unicode_ci 
character-set-server = utf8 # not utf8mb4