每次我启动 mysql 时,使用 /etc/init.d/mysql start 或 service mysql start,它总是超时。
* Starting MySQL (Percona Server) database server mysqld [fail]
但是我可以进入 mysql。我只是想知道安装是否有问题,因为这种情况总是发生,而不是一次性错误。
mysql-error.log显示:
121214 11:25:56 mysqld_safe Starting mysqld daemon with databases from /data/mysql/
121214 11:25:56 [Note] Plugin 'FEDERATED' is disabled.
121214 11:25:56 InnoDB: The InnoDB memory heap is disabled
121214 11:25:56 InnoDB: Mutexes and rw_locks use GCC atomic builtins
121214 11:25:56 InnoDB: Compressed tables use zlib 1.2.3
121214 11:25:56 InnoDB: Using Linux native AIO
121214 11:25:56 InnoDB: Initializing buffer pool, size = 14.0G
121214 11:25:58 InnoDB: Completed initialization of buffer pool
121214 11:26:01 InnoDB: Waiting for the background threads to start
121214 11:26:02 Percona XtraDB (http://www.percona.com) 1.1.8-rel29.2 started; log sequence number 9333955393950
121214 11:26:02 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
121214 11:26:02 [Note] - '0.0.0.0' resolves to '0.0.0.0';
121214 11:26:02 [Note] Server socket created on IP: '0.0.0.0'.
121214 11:26:02 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.005163' at position 624540946, relay log '/data/mysql/mysql-relay-bin.000043' position: 624541092
121214 11:26:02 [Note] Slave I/O thread: connected to master '[email protected]:3306',replication started in log 'mysql-bin.005180' at position 823447620
121214 11:26:02 [Note] Event Scheduler: Loaded 0 events
121214 11:26:02 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.28-29.2-log' socket: '/data/mysql/mysql.sock' port: 3306 Percona Server (GPL), Release 29.2
答案1
错误日志的显示看起来很正常
套接字文件已创建 MySQL 复制已正常
/usr/sbin/mysqld: ready for connections.
启动
特别是因为您看到了/usr/sbin/mysqld: ready for connections.
,您应该能够连接到您刚才声明可以连接的 mysql。
你的 mysqld 进程没有问题。
错误可能来自/etc/init.d/mysql
但不是发生在 mysqld 完成其需要做的所有其他事情之前。
如果你往里面看,/etc/init.d/mysql
有两行
[root@***** init.d]$ cat mysql | grep -n "&" | grep "pid-file"
313: $manager --user=$user --pid-file=$pid_file >/dev/null 2>&1 &
327: $bindir/mysqld_safe --datadir=$datadir --pid-file=$server_pid_file $other_args >/dev/null 2>&1 &
如果/etc/init.d/mysql
超时,那肯定是发生在这两行之后。
以下是检查 pid 文件的代码
wait_for_pid () {
verb="$1"
manager_pid="$2" # process ID of the program operating on the pid-file
i=0
avoid_race_condition="by checking again"
while test $i -ne $service_startup_timeout ; do
case "$verb" in
'created')
# wait for a PID-file to pop into existence.
test -s $pid_file && i='' && break
;;
'removed')
# wait for this PID-file to disappear
test ! -s $pid_file && i='' && break
;;
*)
echo "wait_for_pid () usage: wait_for_pid created|removed manager_pid"
exit 1
;;
esac
# if manager isn't running, then pid-file will never be updated
if test -n "$manager_pid"; then
if kill -0 "$manager_pid" 2>/dev/null; then
: # the manager still runs
else
# The manager may have exited between the last pid-file check and now.
if test -n "$avoid_race_condition"; then
avoid_race_condition=""
continue # Check again.
fi
# there's nothing that will affect the file.
log_failure_msg "Manager of pid-file quit without updating file."
return 1 # not waiting any more.
fi
fi
echo $echo_n ".$echo_c"
i=`expr $i + 1`
sleep 1
done
if test -z "$i" ; then
log_success_msg
return 0
else
log_failure_msg
return 1
fi
}
wait_for_pid()
在启动 mysqld_safe 后调用
# Give extra arguments to mysqld with the my.cnf file. This script
# may be overwritten at next upgrade.
pid_file=$server_pid_file
$bindir/mysqld_safe --datadir=$datadir --pid-file=$server_pid_file $other_args >/dev/null 2>&1 &
wait_for_pid created $!; return_value=$?
最糟糕的情况是,mysqld 在没有 pid 文件的情况下运行。鉴于此,service mysql stop
可能/etc/init.d/mysql stop
无法正常工作,因为它会检查 pid 文件以了解 mysqld 的进程 ID。
如果没有 pid 文件,关闭 mysqld 的正确方法是
# mysqladmin -uroot -h127.0.0.1 --protocol=tcp -p shutdown
警告
这不是一种局部现象。我也看到过这种情况发生在标准 MySQL 二进制文件中。
答案2
看起来 init 脚本使用(参见本例中软件包版本的mysqladmin --defaults-file=/etc/mysql/debian.cnf ping
第 27 行和第 77 行) 检查 Ubuntu 上正在运行的 MySQL/Percona 服务器。这在默认的新安装中有效,但在设置从另一台计算机复制数据文件时,配置的用户不再匹配。/etc/init.d/mysql
percona-server-server-5.5
5.5.28-rel29.2-360.precise
debian.cnf
因此,mysqladmin
命令将失败,并且初始化脚本将报告服务失败,但正如您在日志中看到的那样,它运行正常。
一个解决方案是重新创建初始化脚本所需的 MySQL 用户。在主服务器上,只需像这样添加用户(似乎默认拥有所有权限?!):
GRANT ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TEMPORARY TABLES,
CREATE USER, CREATE VIEW, DELETE, DROP, EVENT, EXECUTE, FILE, INDEX, INSERT,
LOCK TABLES, PROCESS, REFERENCES, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE,
SELECT, SHOW DATABASES, SHOW VIEW, SHUTDOWN, SUPER, TRIGGER, UPDATE
ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY PASSWORD
*replacethiswithaknownhash' WITH GRANT OPTION;
并创建/修改文件/etc/mysql/debian.cnf
:
[client]
host = localhost
user = debian-sys-maint
password = yourpass
socket = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host = localhost
user = debian-sys-maint
password = yourpass
socket = /var/run/mysqld/mysqld.sock
basedir = /usr
您可能需要等待复制过程完成,然后尝试重新启动。
答案3
在 Debian 上遇到了完全相同的问题。服务器实际上启动了,但 init 脚本显示失败:
/etc/mysql/debian.cnf has the mysql socket set at /var/run/mysqld/mysqld.sock
而 my.cnf 可能将其设置为
/var/lib/mysql/mysql.sock
确保 my.cnf 中的套接字和 pid 路径指向设置的内容
/etc/mysql/debian.cnf
另外请确保指向 mysqld 而不是 mysql
答案4
我知道这有点旧了,但现在是 2015 年 4 月 30 日,我们在 Percona 5.6 中遇到了同样的问题。
/etc/init.d/mysql‘start’函数具有以下内容(从 ln:112 开始):
#wait 10sec before start checking if pid file created or server is dead
if [ $dead_check_counter -lt 10 ]; then
dead_check_counter=$(( dead_check_counter + 1 ))
else
if mysqld_status check_dead warn; then break; fi
fi
我们的服务器通常需要大约 40-70 秒才能启动(仅初始化 97GB 的 innodb 缓冲池就需要大约 35 秒),因此自然而然地“启动”会报告它“死亡”,因为套接字文件尚未创建。
我只是增加了“10”的值,这对我来说效果很好。
干杯