Few hours ago, Mysql shuts down on my production server. I've tried to restart it with 'service mysqld restart' as usual (I'm on a centos), but:
MySQL Daemon failed to start.
In my log file, I have :
151125 10:53:10 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151125 10:53:10 InnoDB: Initializing buffer pool, size = 8.0M
151125 10:53:10 InnoDB: Completed initialization of buffer pool
151125 10:53:10 InnoDB: Started; log sequence number 0 6283559
01:53:10 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=8384512
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338336 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x29) [0x8509b9]
/usr/libexec/mysqld(handle_fatal_signal+0x483) [0x6a3ef3]
/lib64/libpthread.so.0() [0x3e59e0f790]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
151125 10:53:10 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
I am losing potential clients every second, so I will appreciate your help, thank you
EDIT
Problem solved ! My partition was full :
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 15G 15G 0M 100% /
I've deleted some useless backups/logs files and restart mysql.
Thank you
Related
I have recently updated mysql that was located under my xampp folder, and i've got the following errors, reporting from the log file :
2018-04-19T12:59:19.667059Z 0 [System] [MY-010116] [Server] C:\xampp\mysql\bin\mysqld.exe (mysqld 8.0.11) starting as process 9324
2018-04-19T12:59:20.025280Z 1 [ERROR] [MY-013090] [InnoDB] InnoDB: Unsupported redo log format (0). The redo log was created before MySQL 5.7.9
2018-04-19T12:59:20.026140Z 1 [ERROR] [MY-012930] [InnoDB] InnoDB: Plugin initialization aborted with error Generic error.
2018-04-19T12:59:20.229069Z 1 [ERROR] [MY-011013] [Server] Failed to initialize DD Storage Engine.
2018-04-19T12:59:20.230803Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2018-04-19T12:59:20.231371Z 0 [ERROR] [MY-010119] [Server] Aborting
2018-04-19T12:59:20.233136Z 0 [System] [MY-010910] [Server] C:\xampp\mysql\bin\mysqld.exe: Shutdown complete (mysqld 8.0.11) MySQL Community Server - GPL.
I have been told if updating your mysql, you should comment out the deprecated configs that are located in your my.ini, but i had no idea what to comment out, so i left it as it is.
Any idea what causes this?
If you have already installed MySQL and did not perform a slow shutdown using the
innodb_fast_shutdown
Flag, simply go to your MySQL directory
/var/lib/mysql/
And remove the log files (Do not do this if you need the table data in your database until you have backed up your database):
ib_logfile0
ib_logfile1
Back them up before if you need them again.
Docker users
I faced with the same error while using dockerized mariaDB.
The solution was:
remove the docker image:
docker image ls
docker rmi imagename
remove the volume:
docker volume ls
docker volume rm yourvolume
remove the container:
docker ps -a
docker rm yourcontainer
Then:
docker-compose up
Windows 10 Users
Also in windows if you want to remove the log files as it was suggested earlier:
The ib_logfiles are in
C:\ProgramData\MySQL\MySQL Server x.x\Data
Mac OS X Users
The ib_logfiles are here
rm /usr/local/var/mysql/ib_logfile*
In my case, I have deleted the complete folder /var/lib/mysql and restarted the mysql service and it worked...
rm -rf /var/lib/mysql
Note: You may loose your data if you delete that folder
I have a PHP daemon script downloading remote images and storing them local temporary before uploading to object storage.
PHP internal memory usage remains stable but the memory usage reported by Docker/Kubernetes keeps increasing.
I'm not sure if this is related to PHP, Docker or expected Linux behavior.
Example to reproduce the issue:
Docker image: php:7.2.2-apache
<?php
for ($i = 0; $i < 100000; $i++) {
$fp = fopen('/tmp/' . $i, 'w+');
fclose($fp);
unlink('/tmp/' . $i);
unset($fp);
}
Calling free -m inside container before executing the above script:
total used free shared buff/cache available
Mem: 3929 2276 139 38 1513 1311
Swap: 1023 167 856
And after executing the script:
total used free shared buff/cache available
Mem: 3929 2277 155 38 1496 1310
Swap: 1023 167 856
Apperantly the memory is released but calling docker stats php-apache from host indicate something other:
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
ccc19719078f php-apache 0.00% 222.1MiB / 3.837GiB 5.65% 1.21kB / 0B 1.02MB / 4.1kB 7
The initial memory usage reported by docker stats php-apache was 16.04MiB.
What is the explanation? How do I free the memory?
Having this contianer running in a Kubernetes cluster with resource limits causes the pod to fail and restart repeatedly.
Yes, a similar issue has been reported here.
Here's the answer of coolljt0725, one of the contributors, answering why a RES column in top output shows something different, than docker stats (I'm just gonna quote him as is):
If I understand correctly, the memory usage in docker stats is exactly read from containers's memory cgroup, you can see the value is the same with 490270720 which you read from cat /sys/fs/cgroup/memory/docker/665e99f8b760c0300f10d3d9b35b1a5e5fdcf1b7e4a0e27c1b6ff100981d9a69/memory.usage_in_bytes, and the limit is also the memory cgroup limit which is set by -m when you create container. The statistics of RES and memory cgroup are different, the RES does not take caches into account, but the memory cgroup does, that's why MEM USAGE in docker stats is much more than RES in top
What a user suggested here might actually help you to see the real memory consumption:
Try set the param of docker run --memory，then check your
/sys/fs/cgroup/memory/docker/<container_id>/memory.usage_in_bytes
It should be right.
--memory or -m is described here:
-m, --memory="" - Memory limit (format: <number>[<unit>]). Number is a positive integer. Unit can be one of b, k, m, or g. Minimum is 4M.
And now how to avoid the unnecessary memory consumption. Just as you posted, unlinking a file in PHP does not necessary drop memory cache immediately. Instead, running the Docker container in privileged mode (with --privileged flag) it is then possible to call echo 3 > /proc/sys/vm/drop_caches or sync && sysctl -w vm.drop_caches=3 periodcally to clear the memory pagecache.
And as a bonus, using fopen('php://temp', 'w+') and storing the file temporary in memory avoids the entire issue.
The issues referred by Alex explained the memory usage difference between free -m inside the container and docker stats from host. Buffer/cache is included in the latter.
Unlinking a file in PHP does not necessary drop memory cache immediately.
Instead, running the Docker container in privileged mode I was able to call echo 3 > /proc/sys/vm/drop_caches periodcally to clear the memory pagecache.
I was doing some testing with memcached using php sessions.
The following steps cause problems.
Start memcache
Login to application which creates a session
Restart memcache
Try to navigate to another page
Browser hangs for 30 seconds and logs out
Requests after logging in again take 30 seconds but works. Randomly it stops taking 30 seconds to perform actions and is back to normal speed
What is the cause of this odd behavior
Sometimes I get the following error:
A PHP Error was encountered
Severity: Warning
Message: Unknown: Failed to write session data (memcache). Please verify that the current setting of session.save_path is correct (tcp://10.181.16.192:11211?persistent=1&weight=1&timeout=1&retry_interval=15)
Filename: Unknown
Line Number: 0
EDIT:
If I restart memcache then apache the problem does not occur
I noticed TCP connections change to CLOSE_WAIT when restarting memcached.
But if I restart memcache and apache back to back without delay then it solves the problem.
It seems like there is some sort of bug in the way php handles connections to memcache where it doesn't recognize the connection is valid anymore and causes the issues described.
[root#php-pos-web ~]# netstat -natp | grep '11211'
tcp 1 0 10.181.16.33:58722 10.181.16.192:11211 CLOSE_WAIT 7574/httpd
tcp 205 0 10.181.16.33:58753 10.181.16.192:11211 ESTABLISHED 7583/httpd
tcp 1 0 10.181.16.33:58745 10.181.16.192:11211 CLOSE_WAIT 7578/httpd
tcp 1 0 10.181.16.33:58749 10.181.16.192:11211 CLOSE_WAIT 7573/httpd
There is a bug in starting in 3.0.4 of the memcache pecl extension. This does not happen on the latest stable release (2.2.7). I have reported this bug to the team. I think it has something to do with session locking. This bug does not occur in memcached extension.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
The MySQL server is restarting frequently. 75 times in less than 24 hours. And finally its ending without restarting!
Please check the details log here: mysqld.log
140113 10:18:22 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
140113 10:18:31 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140113 10:18:31 InnoDB: Initializing buffer pool, size = 8.0M
140113 10:18:31 InnoDB: Completed initialization of buffer pool
140113 10:18:31 InnoDB: Started; log sequence number 16 1064411530
140113 10:18:32 [Note] Event Scheduler: Loaded 0 events
140113 10:18:32 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.61' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
140113 18:45:09 mysqld_safe Number of processes running now: 0
140113 18:45:10 mysqld_safe mysqld restarted
140113 18:45:10 InnoDB: Initializing buffer pool, size = 8.0M
140113 18:45:10 InnoDB: Completed initialization of buffer pool
140113 18:45:10 InnoDB: Started; log sequence number 16 1064411530
140113 18:45:11 [Note] Event Scheduler: Loaded 0 events
140113 18:45:11 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.61' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
......
140114 9:50:12 InnoDB: Initializing buffer pool, size = 8.0M
140114 9:50:12 InnoDB: Completed initialization of buffer pool
140114 9:50:12 InnoDB: Started; log sequence number 16 1064411530
140114 9:50:13 [Note] Event Scheduler: Loaded 0 events
140114 9:50:13 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.61' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
140114 09:55:07 mysqld_safe Number of processes running now: 0
140114 09:55:07 mysqld_safe mysqld restarted
140114 9:55:08 InnoDB: Initializing buffer pool, size = 8.0M
140114 9:55:08 InnoDB: Completed initialization of buffer pool
140114 09:55:08 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
In the meantime its killing 62 processes due to out of memory. Please check the detail log: messages
Jan 14 09:41:53 centos63 kernel: Out of memory: Kill process 16795 (mysqld) score 20 or sacrifice child
Jan 14 09:41:53 centos63 kernel: Killed process 16795, UID 27, (mysqld) total-vm:574508kB, anon-rss:20488kB, file-rss:164kB
I am running a cronjob in each 5 minutes which is affecting some tables with about 200000, 50000, 25000 data in three tables.
SELECT over 1,257 members then over 9,844 member_boards and then INSERT/UPDATE over 168,624 member_cards using the below pseudocode:
<?php
$qry = _("SELECT _members");
while($member = mysql_fetch_assoc($res))
{//1,257
$qry = _("SELECT _member_boards");
while($db_board = mysql_fetch_assoc($board_res))
{//9,844
$s_lists = curl_download("https://api.com/boards/lists");
foreach ($lists as $list) {//9,844
if(!strcmp('SOMETHING', $list->name)){//Matching with API and DB
$curl = "https://api.com/lists/cards";
foreach ($cards as $card) {//168,624
$qry = _("SELECT _member_cards");
if($card_row = mysql_fetch_assoc($card_res)){
$qry = _("UPDATE _member_cards");
}
else{
echo $qry = _("INSERT _member_cards");
}
}
}
}
}
$qry = _("UPDATE _member_cards");
}
?>
So what can be the reason and how can I solve this issue?
RAM 512 MB until now.
CentOS
Can scaling RAM up to 1 GB solve the issue?
Your MySQL server is getting killed because it uses too much memory; you can either add more RAM to the server or try lowering MySQL's memory usage by changing some values in its configuration file; however that may affect performance.
Take a look at this question and this one for guides about tweaking MySQL's configuration - it's not an easy task and it's based on trial and error, you should try different values until you get a good balance between performance and memory usage.
trying to get my first little PHP script to connect to a local mySql database and am having some trouble. I used a cookie cutter script from the net to get going and am having some issues. In order to debug so far all I've done is place echo statements before and after the line where I connect to the database and noticed that there is a problem with the connection statement.
Here is the code i'm using, taken verbatim from W3Schools:
<?php
$con = mysql_connect("localhost","peter","abc123");
if (!$con)
{
die('Could not connect: ' . mysql_error());
}
mysql_select_db("my_db", $con);
$result = mysql_query("SELECT * FROM Persons");
while($row = mysql_fetch_array($result))
{
echo $row['FirstName'] . " " . $row['LastName'];
echo "<br />";
}
mysql_close($con);
?>
Naturally I changed the passwords and all that and verified that I can connect to the database from the mysql command line tool.
Any tips would be greatly appreciated.
Here is the log located at: /var/log/mysql/error.log
Version: '5.1.54-1ubuntu4' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
110727 1:38:22 [Note] /usr/sbin/mysqld: Normal shutdown
110727 1:38:22 [Note] Event Scheduler: Purging the queue. 0 events
110727 1:38:23 InnoDB: Starting shutdown...
110727 1:38:25 InnoDB: Shutdown completed; log sequence number 0 15895194
110727 1:38:25 [Note] /usr/sbin/mysqld: Shutdown complete
110727 14:08:56 [Note] Plugin 'FEDERATED' is disabled.
110727 14:08:56 InnoDB: Initializing buffer pool, size = 8.0M
110727 14:08:56 InnoDB: Completed initialization of buffer pool
110727 14:08:57 InnoDB: Started; log sequence number 0 15895194
110727 14:08:58 [Note] Event Scheduler: Loaded 0 events
110727 14:08:58 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.54-1ubuntu4' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
SO I learn't how to get some meaningful debug info from PHP thanks to #nix, add the following lines to the top of the php file:
ini_set('display_errors', 1);
ini_set('log_errors', 1);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');
Well. try restarting mysql daemon:
sudo service mysqld restart
try connecting to mysql from command line using
-h localhost
and
-h 127.0.0.1
Also - check for exact error you're getting in:
/var/log/mysql.err
or
/var/log/mysql/mysql.log
P.S. your code works for me.
UPDATE:
So - in the end as it turns out - mysqli was disabled in PHP. Problem solved.:)
So it turns out that the php5-mysql library was not installed.
sudo apt-get install php5-mysql
that's it!
Thanks to #nix for taking care of this one.