1

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->query('SELECT * FROM MYTABLE LIMIT 1');
    $results = $stmt->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).

  • What error do you get? Without that we can't help you. – mpdonadio Dec 24 '14 at 18:40
  • I'd add this as an answer, but it turns out utf8 vs utf8mb4 was the issue. – floatingpointmatt Dec 24 '14 at 19:18
1

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.