PDO / MySQL / PHP / OS X：MySQL服务器在后续查询中消失了吗？

Question

I think this is an issue in code somewhere, but the code's so simple I'm not sure what it could be.

I've verified wait_timeout is high enough and have gone through everything here: http://dev.mysql.com/doc/refman/5.1/en/gone-away.html without any success.

This happens reproducibly on the second query executed in one script run so I'm sure it's a coding error.

I created a really simple wrapper around the PDO class to have a singleton database handle:

<?php

class PDOWrapper
{
    protected static $instance;
    protected $dbh;

    function __construct()
    {
        if ( is_null(static::$instance) )
        {
            static::$instance = $this;
            $this->connect_to_db();
        }
    }

    static function instance()
    {
        if ( is_null(static::$instance) )
        {
            new static;
        }

        return static::$instance;
    }

    private function connect_to_db()
    {
        $db_info = array(
            0 => array(
                'hostname' => "Host",
                'username' => "User",
                'password' => "Pass",
                'db' => "DB",
            )
        );

        //Try to connect to the database
        try 
        {
            $dbh = new PDO('mysql:host=' . $db_info[0]['hostname'] . ';dbname=' . $db_info[0]['db'], $db_info[0]['username'], $db_info[0]['password'], array( PDO::ATTR_PERSISTENT => true, PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_EMULATE_PREPARES => true ));
        }
        catch (PDOException $e)
        {
            log_message("Error connecting to DB!: " . $e->getMessage(), LOG_LEVEL_CRITICAL );
            return false;
        }

        $this->dbh = $dbh;
    }

    public static function get_dbh()
    {
        if ( is_null(static::$instance) )
        {
            new static;
        }

        return static::$instance->dbh;
    }
}

I then use the wrapper like so:

function somefunc(){
    $dbh = PDOWrapper::get_dbh();
    $future_sth = $dbh->prepare("SELECT * FROM some_table");
    $future_sth->execute();
    $ret = $future_sth->fetchAll(PDO::FETCH_ASSOC);
    print_r($ret);
    $future_sth->closeCursor();
    return $ret;
}

I call this function repeatedly as part of an event loop. The first time it calls it, the print_r runs fine and it prints out the rows I expect to see.

After the function has been executed once, however, I get the following:

Warning: Error while sending QUERY packet. PID=92871
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away'

I don't know why it'd have "gone away". My my.cnf looks ok. Wait timeout is massive and this happens immediately as soon as I run the second query anyway. Any ideas?

It doesn't look like anything is obviously wrong in the MySQL error log:

120925 12:48:46 mysqld_safe Starting mysqld daemon with databases from /usr/local/var/mysql
120925 12:48:46 [Warning] The syntax '--log' is deprecated and will be removed in a future release. Please use '--general-log'/'--general-log-file' instead.
120925 12:48:46 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
120925 12:48:46 InnoDB: The InnoDB memory heap is disabled
120925 12:48:46 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120925 12:48:46 InnoDB: Compressed tables use zlib 1.2.5
120925 12:48:46 InnoDB: Initializing buffer pool, size = 128.0M
120925 12:48:46 InnoDB: Completed initialization of buffer pool
120925 12:48:46 InnoDB: highest supported file format is Barracuda.
120925 12:48:46  InnoDB: Waiting for the background threads to start
120925 12:48:47 InnoDB: 1.1.8 started; log sequence number 2273680401
120925 12:48:47 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
120925 12:48:47 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
120925 12:48:47 [Note] Server socket created on IP: '0.0.0.0'.
120925 12:48:47 [Note] Event Scheduler: Loaded 0 events
120925 12:48:47 [Note] /usr/local/Cellar/mysql/5.5.25a/bin/mysqld: ready for connections.
Version: '5.5.25a-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution

Answer 1

I figured it out.

I was working on a multi-process daemon using pcntl_fork. The parent process was responsible for running a loop to query the database and fork children to perform additional work depending on what data it saw.

The children didn't need a DB connection, however they were still given one because pcntl_fork was used. I was just using exit() to kill the child processes when they were done with their work, which caused the 'friendly' PHP cleanup to close the active MySQL connection it perceived the child to have.

Control would go back to the parent, who would find their DB connection was suddenly no longer valid when they tried to find more data in the database to send off to children.

The fix, for me, was to use posix_kill(getmypid(), 9); to kill the children rather than exit();.