on my CentOS release 5.10 (Final), kernel version: Linux 2.6.18-371.6.1.el5 #1 SMP Wed Mar 12 20:08:05 EDT 2014 i686 i686 i386 GNU/Linux, I have mysql version mysql-5.6.17-4.el5.
My mysqld crashes after " service mysqld start " with errors in log. Could you please help:
2014-04-24 07:46:00 24175 [Note] Server hostname (bind-address): '*'; port: 3306
2014-04-24 07:46:00 24175 [Note] IPv6 is available.
2014-04-24 07:46:00 24175 [Note] - '::' resolves to '::';
2014-04-24 07:46:00 24175 [Note] Server socket created on IP: '::'.
14:46:00 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=33554432
read_buffer_size=131072
max_used_connections=0
max_threads=500
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 = 229484 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0xa22d290
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 = ffffffffbfaeb048 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x33)[0x856f7d3]
/usr/sbin/mysqld(handle_fatal_signal+0x43e)[0x828b29e]
[0xad7420]
/usr/sbin/mysqld(_Z9get_fieldP11st_mem_rootP5Field+0x67)[0x83c3127]
/usr/sbin/mysqld[0x82b4db8]
/usr/sbin/mysqld(_Z10acl_reloadP3THD+0x4ba)[0x82b6d7a]
/usr/sbin/mysqld(_Z8acl_initb+0x134)[0x82bb984]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x938)[0x8194548]
/usr/sbin/mysqld(main+0x32)[0x8187372]
/lib/libc.so.6(__libc_start_main+0xdc)[0x688ebc]
/usr/sbin/mysqld(__gxx_personality_v0+0x3b9)[0x8187281]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): is an invalid pointer
Connection ID (thread ID): 0
Status: NOT_KILLED
free command output:
[root#localhost ~]# free
total used free shared buffers cached
Mem: 1034656 634984 399672 0 55416 283292
-/+ buffers/cache: 296276 738380
Swap: 2096472 144 2096328
Thank you in advance!
fix described here: http://bugs.mysql.com/bug.php?id=70431
"start the server by adding skip-grant-tables to my.cnf and check what the structure of mysql.user table looks like."
"As a general rule, to upgrade from one release series to another, go to the
next series rather than skipping a series. To upgrade from a release series
previous to MySQL 5.5, upgrade to each successive release series in turn
until you have reached MySQL 5.5, and then proceed with the upgrade to MySQL
5.6.".
Related
I've successfully configured my Ubuntu server so MySQL can use hugepages. Problem is when I want to enable memlock option in my.cnf and /proc/sys/vm/hugetlb_shm_group is set to another group (MySQL is a member of this group).
# uname -a
Linux hostname 3.13.0-32-generic #57~precise1-Ubuntu SMP Tue Jul 15 03:51:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
# mysqld --version
mysqld Ver 5.5.53-0ubuntu0.12.04.1 for debian-linux-gnu on x86_64 ((Ubuntu))
# egrep ^Huge /proc/meminfo
HugePages_Total: 15000
HugePages_Free: 15000
HugePages_Rsvd: 0
HugePages_Surp: 0
# id mysql
uid=107(mysql) gid=113(mysql) groups=113(mysql),117(hugetlb)
If /proc/sys/vm/hugetlb_shm_group is set to 113 everything goes well no matter of memlock option.
But if I set /proc/sys/vm/hugetlb_shm_group to 117 it works only without the memlock option. If I enable it I get this error when MySQL starts:
InnoDB: HugeTLB: Warning: Failed to allocate 21978152960 bytes. errno 1
InnoDB HugeTLB: Warning: Using conventional memory pool
Any idea what can be wrong?
Turned out to be a problem with ulimit. Settings in /etc/security/limits.conf are ignored so I got it working with simple edit in /etc/init/mysql.conf:
exec /usr/bin/mysqld
changed to
script
ulimit -l unlimited
/usr/bin/mysqld
end script
While trying to repair a corrupted table which it stuck at optimizing stage for 12 hours, my smartness went ahead and rebooted the server
After reboot mysql won't start
Running mariadb 10.1.20
Storage Engine AREA
RAM 32 gb
OS: Centos 6.7
My.cnf
#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]
[mysqld]
port = 3306
default-storage-engine = aria
aria-pagecache-buffer-size = 1024M
skip_name_resolve
skip-networking
bulk_insert_buffer_size = 8M
connect_timeout = 10
interactive_timeout = 50
query_cache_type = 0
query_cache_limit = 10M
query_cache_min_res_unit = 2k
query_cache_size = 0
table_open_cache = 2048
thread_stack = 256K
transaction_isolation = REPEATABLE-READ
read_buffer_size = 2M
read_rnd_buffer_size = 16M
sort_buffer_size = 8M
table_cache = 4096
join_buffer_size = 10M
key_buffer_size = 512M
max_allowed_packet = 16M
bulk_insert_buffer_size = 64M
myisam_recover_options = BACKUP, FORCE
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 5G
thread_cache_size = 1024
max_heap_table_size = 64M
tmp_table_size = 64M
thread_handling = pool-of-threads
wait-timeout = 30
interactive-timeout = 30
concurrent_insert = 2
net_buffer_length = 2K
wait_timeout = 300
host_cache_size = 2000
max_connections = 1000
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
So i tried myisamchk
myisamchk --silent --force --fast --update-state /var/lib/mysql//.MYI
myisamchk: MyISAM file /var/lib/mysql/fmartinto2/core_members.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/fmartinto2/core_sessions.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/content_gener.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/content.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/content_playlist.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/content_views.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/emails_queue.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/episodes.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/links.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/link_votes.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/messages.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/playlists.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/playlist_views.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/users.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/watched_already.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: MyISAM file /var/lib/mysql/martin_new/watchlist.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
Then used it again with more memory
myisamchk --silent --force --fast --update-state \
--key_buffer_size=512M --sort_buffer_size=512M \
--read_buffer_size=4M --write_buffer_size=4M \
/var/lib/mysql/*/*.MYI
Returned empty After i removed --silent and re run it again it return
MyISAM file: /var/lib/mysql/martin_new/users.MYI is already checked
Mysql Error log:
161221 20:30:55 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
/usr/sbin/mysqld: Can't read dir of '/etc/my.cnf.' (Errcode: 2 "No such file or directory")
Fatal error in defaults handling. Program aborted
161221 20:30:55 mysqld_safe mysqld from pid file /var/lib/mysql/martin.cr.pid ended
161221 20:35:00 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
/usr/sbin/mysqld: Can't read dir of '/etc/my.cnf.' (Errcode: 2 "No such file or directory")
Fatal error in defaults handling. Program aborted
161221 20:35:00 mysqld_safe mysqld from pid file /var/lib/mysql/martin.cr.pid ended
161221 20:50:32 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2016-12-21 20:50:32 140464028563488 [Note] /usr/sbin/mysqld (mysqld 10.1.20-MariaDB) starting as process 3489 ...
2016-12-21 20:50:32 140464028563488 [Note] mysqld: Aria engine: starting recovery
recovered pages: 0% 10% 20% 30% 40%161221 20:50:33 [ERROR] 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.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
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.
Server version: 10.1.20-MariaDB
key_buffer_size=536870912
read_buffer_size=2097152
max_used_connections=0
max_threads=1001
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10795087 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
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 = 0x0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2b)[0x7fc0552f85cb]
/usr/sbin/mysqld(handle_fatal_signal+0x4d5)[0x7fc054e51375]
/lib64/libpthread.so.0(+0x375780f7e0)[0x7fc0544537e0]
/usr/sbin/mysqld(+0x99f356)[0x7fc055222356]
/usr/sbin/mysqld(+0x9a09ad)[0x7fc0552239ad]
/usr/sbin/mysqld(+0x9a444c)[0x7fc05522744c]
/usr/sbin/mysqld(+0x9a4f0e)[0x7fc055227f0e]
/usr/sbin/mysqld(+0x97dc4d)[0x7fc055200c4d]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x68)[0x7fc054e538d8]
/usr/sbin/mysqld(+0x46ded5)[0x7fc054cf0ed5]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x8da)[0x7fc054cf1e3a]
/usr/sbin/mysqld(+0x3ce045)[0x7fc054c51045]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x1d9b)[0x7fc054c5395b]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7fc052865d1d]
/usr/sbin/mysqld(+0x3c4999)[0x7fc054c47999]
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.
161221 20:50:33 mysqld_safe mysqld from pid file /var/lib/mysql/martin.cr.pid ended
161221 20:56:50 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2016-12-21 20:56:51 140139510470688 [Note] /usr/sbin/mysqld (mysqld 10.1.20-MariaDB) starting as process 2830 ...
2016-12-21 20:56:51 140139510470688 [Note] mysqld: Aria engine: starting recovery
recovered pages: 0% 10% 20% 30% 40%161221 20:56:51 [ERROR] 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.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
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.
Server version: 10.1.20-MariaDB
key_buffer_size=536870912
read_buffer_size=2097152
max_used_connections=0
max_threads=1001
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10795087 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
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 = 0x0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2b)[0x7f74c66665cb]
/usr/sbin/mysqld(handle_fatal_signal+0x4d5)[0x7f74c61bf375]
/lib64/libpthread.so.0(+0x375780f7e0)[0x7f74c57c17e0]
/usr/sbin/mysqld(+0x99f356)[0x7f74c6590356]
/usr/sbin/mysqld(+0x9a09ad)[0x7f74c65919ad]
/usr/sbin/mysqld(+0x9a444c)[0x7f74c659544c]
/usr/sbin/mysqld(+0x9a4f0e)[0x7f74c6595f0e]
/usr/sbin/mysqld(+0x97dc4d)[0x7f74c656ec4d]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x68)[0x7f74c61c18d8]
/usr/sbin/mysqld(+0x46ded5)[0x7f74c605eed5]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x8da)[0x7f74c605fe3a]
/usr/sbin/mysqld(+0x3ce045)[0x7f74c5fbf045]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x1d9b)[0x7f74c5fc195b]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f74c3bd3d1d]
/usr/sbin/mysqld(+0x3c4999)[0x7f74c5fb5999]
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.
161221 20:56:51 mysqld_safe mysqld from pid file /var/lib/mysql/martin.cr.pid ended
161221 21:00:05 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2016-12-21 21:00:05 139723942508576 [Note] /usr/sbin/mysqld (mysqld 10.1.20-MariaDB) starting as process 3404 ...
2016-12-21 21:00:05 139723942508576 [Note] mysqld: Aria engine: starting recovery
recovered pages: 0% 10% 20% 30% 40%161221 21:00:06 [ERROR] 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.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
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.
Server version: 10.1.20-MariaDB
key_buffer_size=536870912
read_buffer_size=2097152
max_used_connections=0
max_threads=1001
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10795087 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
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 = 0x0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2b)[0x7f14049e85cb]
/usr/sbin/mysqld(handle_fatal_signal+0x4d5)[0x7f1404541375]
/lib64/libpthread.so.0(+0x375780f7e0)[0x7f1403b437e0]
/usr/sbin/mysqld(+0x99f356)[0x7f1404912356]
/usr/sbin/mysqld(+0x9a09ad)[0x7f14049139ad]
/usr/sbin/mysqld(+0x9a444c)[0x7f140491744c]
mysys/stacktrace.c:268(my_print_stacktrace)[0x7f1404917f0e]
maria/ha_maria.cc:3594(ha_maria_init)[0x7f14048f0c4d]
sql/handler.cc:513(ha_initialize_handlerton(st_plugin_int*))[0x7f14045438d8]
sql/sql_plugin.cc:1408(plugin_initialize)[0x7f14043e0ed5]
sql/sql_plugin.cc:1678(plugin_init(int*, char**, int))[0x7f14043e1e3a]
sql/mysqld.cc:5196(init_server_components)[0x7f1404341045]
sql/mysqld.cc:5787(mysqld_main(int, char**))[0x7f140434395b]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f1401f55d1d]
/usr/sbin/mysqld(+0x3c4999)[0x7f1404337999]
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.
161221 21:00:06 mysqld_safe mysqld from pid file /var/lib/mysql/martin.cr.pid ended
Use the myisamcheck tool to 'repair' the MyISAM tables. I don't know if there is a corresponding took for aria tables, but that seems to be where it blew up.
Suggest filing a bug report with mariadb.com
I am on Mac 10.11.3 (15D21)
About Docker I have:
$ docker version
Client:
Version: 1.10.3
API version: 1.22
Go version: go1.5.3
Git commit: 20f81dd
Built: Thu Mar 10 21:49:11 2016
OS/Arch: darwin/amd64
Server:
Version: 1.10.3
API version: 1.22
Go version: go1.5.3
Git commit: 20f81dd
Built: Thu Mar 10 21:49:11 2016
OS/Arch: linux/amd64
For Mysql
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
mysql latest 7a5866c2edbf 12 days ago 361.3 MB
...
I did the following:
mkdir -p /Users/me/docker/mysql/data
chmod -R 777 /Users/me/docker/mysql/data
(Even with sudo for each command)
It from Pro Docker and from: Permission denied when mounting Docker volume in OSX
Even doing:
docker -v /Users/me/docker/mysql/data:/var/lib/mysql mysql chown -R mysql /var/lib/mysql
It from: Database Fails to Start - Host Directory as a Data Volume
When I execute: (showing in multiple lines for better visualisation)
docker run -v /Users/me/docker/mysql/data:/var/lib/mysql --name manolitomysql
-e MYSQL_DATABASE='mysqldb' -e MYSQL_USER='mysql' -e MYSQL_PASSWORD='mysql'
-e MYSQL_ALLOW_EMPTY_PASSWORD='yes' -e MYSQL_ROOT_PASSWORD='' -d mysql
I always get:
$ docker logs manolitomysql
Initializing database
2016-03-27T16:04:33.520170Z 0 [Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
2016-03-27T16:04:35.089907Z 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
2016-03-27T16:04:35.090006Z 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
2016-03-27 16:04:35 0x7f061a050740 InnoDB: Assertion failure in thread 139664183068480 in file fil0fil.cc line 868
InnoDB: Failing assertion: success
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:04:35 UTC - mysqld got signal 6 ;
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.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
key_buffer_size=8388608
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 = 68188 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
mysqld(my_print_stacktrace+0x2c)[0xe57c7c]
mysqld(handle_fatal_signal+0x459)[0x7896b9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7f0619c2d8d0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f061841b067]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f061841c448]
mysqld[0x75fc29]
mysqld[0x1180f68]
mysqld(_Z40fil_open_log_and_system_tablespace_filesv+0xe4)[0x1185a74]
mysqld[0x107afe0]
mysqld(_Z34innobase_start_or_create_for_mysqlv+0x3692)[0x107eb12]
mysqld[0xf4a05d]
mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x51)[0x7d3981]
mysqld[0xc53716]
mysqld(_Z11plugin_initPiPPci+0x5c8)[0xc5a5c8]
mysqld[0x782164]
mysqld(_Z11mysqld_mainiPPc+0x7b2)[0x7835d2]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f0618407b45]
mysqld[0x77a274]
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.
What extra configuration is need it?
For the audience, the following works:
1 Create a Dockerfile with
FROM mysql:latest
RUN deluser mysql
RUN useradd mysql
RUN mkdir -p /Users/me/docker/mysql/data
RUN chmod -R 777 /Users/me/docker/mysql/data
2 Create a new image using the previous Dockerfile
3 Run your new container using the previous new image
You may have better control using a Dockerfile with the following instructions:
RUN useradd mysql
RUN mkdir /var/lib/mysql && chown -R mysql:mysql /var/lib/mysql
I tried that restarting EC2 instance and sudo service httpd restart.
But I still get this message:
[ec2-user#ip-* ~]$ sudo service mysqld start
MySQL Daemon failed to start.
Starting mysqld: [FAILED]
Also I get this message:
[ec2-user#ip-* ~]$ mysqld
160127 7:01:48 [Note] mysqld (mysqld 5.5.46) starting as process 2745 ...
160127 7:01:48 [Warning] Can't create test file /var/lib/mysql/ip-*.lower-test
160127 7:01:48 [Warning] Can't create test file /var/lib/mysql/ip-*.lower-test
160127 7:01:48 [Note] Plugin 'FEDERATED' is disabled.
mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
160127 7:01:48 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
160127 7:01:48 InnoDB: The InnoDB memory heap is disabled
160127 7:01:48 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160127 7:01:48 InnoDB: Compressed tables use zlib 1.2.8
160127 7:01:48 InnoDB: Using Linux native AIO
160127 7:01:48 InnoDB: Initializing buffer pool, size = 128.0M
160127 7:01:48 InnoDB: Completed initialization of buffer pool
160127 7:01:48 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.
I don't know what should I do..
Cheers!
EDIT
(+ I'm also using amazon RDS.)
Now, I tried sudo chown -R mysql:mysql /var/lib/mysql too.
But
[ec2-user#ip-* ~]$ mysql_upgrade
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed
[ec2-user#ip-* ~]$ ls -lh /var/lib/mysql/
합계 29M
-rw-rw---- 1 mysql mysql 5.0M 1월 27 06:52 ib_logfile0
-rw-rw---- 1 mysql mysql 5.0M 1월 27 06:12 ib_logfile1
-rw-rw---- 1 mysql mysql 18M 1월 27 06:52 ibdata1
drwx------ 2 mysql mysql 4.0K 1월 20 07:03 mysql
drwx------ 2 mysql mysql 4.0K 1월 20 07:03 performance_schema
drwx------ 2 mysql mysql 4.0K 1월 20 07:03 test
As per today the nano instances with 0.5GiB memory do not allow running mysqld - they do not have enough memory. Running a micro instance with 1GiB memory fixes the problem completely. I think guys at AWS should have made a note about this in the LAMP installation instructions, as this research costed me several hours or even a day before I figured it out.
I answer myself to my question to help other people in the same problem.
I resolved this problem from these steps:
Restart your EC2 instance.
Type sudo service httpd restart. (I don't know why I should do these two steps.)
Type sudo chown -R mysql:mysql /var/lib/mysql. - Before typing this command, check your user= option in your /etc/my.cnf. If there is no user= option, your user is "mysql". (Visit https://stackoverflow.com/a/21435052/1570534)
Change the innodb_buffer_pool_size option inside /etc/my.cnf from 128 (can be different) to 500M. If you don't have innodb_buffer_pool_size option in your /etc/my.cnf, add innodb_buffer_pool_size=500M in [mysqld] section.
I hope it helps you!
I also faced the same issue when setting up an instance on Lightsail with the lowest cost instance (512MB, 1 vCPU, 20 GB SSD).
I was able to solve the issue by adding a swap file in the instance.
Here is the step to create a swap:
Use the dd command to create a swap file on the root file system, where "bs" is the block size and "count" is the number of blocks. In this example the swap file is 1 GB:
$ sudo dd if=/dev/zero of=/swapfile bs=1M count=1000
Update the read and write permissions for the swap file:
$ chmod 600 /swapfile
Set up a Linux swap area:
$ mkswap /swapfile
Make the swap file available for immediate use by adding the swap file to swap space:
$ swapon /swapfile
Verify that the procedure was successful:
$ swapon -s
Enable the swap file at boot time by editing the /etc/fstab file:
$ vi /etc/fstab
$ /swapfile swap swap defaults 0 0
If the issue is in Amazon Linux OS, please check whether you have free swap.
I faced the same issue, when I add more swap, mysql service start working.
You can see more from here http://www.linuxblackmagic.com/2018/04/mysql-daemon-failed-to-start-in-amazon.html
This will surely work for you.
Shivin Vijai
I had this problem, similar to #Michael Zelensky, when I tried to make use of an Amazon t3.nano machine. (FWIW t3.micro needed no extra adjustments on my end, but I was trying to see "how low could I go" )
I was able to find a workaround that seems to be working for now. Simply add:
table_definition_cache=400
.. to the [mysqld] section in /etc/my.cnf . This apparently lowered some of the memory usage enough to allow me to then perform a service mysqld start and the service came up (along with my Wordpress websites :) )
Thanks to some AWS support specialists and also this website for helping me figure this out: http://www.tocker.ca/2014/03/10/configuring-mysql-to-use-minimal-memory.html
I am getting following error while starting mysql ...can someone help:
]# service mysql start
Starting MySQL.Manager of pid-file quit without updating fi[FAILED]
Following is my my.cnf file...
** my.cnf file *****
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
table_cache = 2048
innodb_buffer_pool_size = 2G
innodb_file_per_table
innodb_log_buffer_size = 8M
innodb_log_file_size = 128M
innodb_additional_mem_pool_size = 4M
innodb_table_locks = 0
default-storage-engine=InnoDB
join_buffer_size = 2M
query_cache_size = 512M
query_cache_limit = 2M
sort_buffer_size = 8M
read_buffer_size = 8M
read_rnd_buffer_size = 4M
key_buffer = 512M
key_buffer_size = 256M
max_allowed_packet = 16M
max_connections = 250
long_query_time = 5
log_slow_queries = ekb-qa-app-02-slow.log
innodb_autoinc_lock_mode=2
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
I received the exact same error...which ended up being misleading to me. The problem (at least for me) ended up being that I had filled the disk to capacity. Try df -h and see if you are at capacity. Hope that helps, and that this error was caused by this as well for you ( since it is simple to fix :) ).
This can be happen due to two reasons:
mysqld is trying to write logs to the disk, which is full.
mysqld is trying to write logs to the file but it doesn't have appropriate permissions.
Try running the mysqld_safe directly and see if the error message is more specific about your problem. This way I was able to realize the my log file had a permissions problem.
For me, the issue was insufficient privileges to the mysql data files. The data files were copied over from another file system as root. Once I changed the group and ownership of the files to mysql:mysql the error went away.
The /etc/init.d/mysql[d] startup script can also outsmart itself by printing overlapping error messages, but you only end up seeing one. You may also see "[FAILED]" or "[OK]" overlapping in the middle of the script output, and some of this may even depend on the exact terminal software you use.
Meanwhile, in my case, the true error was buried underneath this:
Manager of pid-file quit wi[FAILED]dating file
I finally looked closely enough at my mysqld error log, and found the real issue:
/usr/sbin/mysqld: File 'MASTER/master15-bin.index' not found (Errcode: 2)
Like other similar cases here, the problem came from copying the whole /var/lib/mysql directory over from a different host. Here I was setting up a fresh replication server, and so the MASTER and SLAVE variables are different in /etc/my.cnf of course. My master binlogs are in a MASTER subdirectory.
Once I cleaned that up, everything was fine.
So this "Manager of pid-file quit" error was another red herring. I'm just adding this story here to show yet again that (1) the answer probably lies in your error log, and (2) may have nothing to do with this error you see from mysqld_safe.
I just prefix sudo command in the below statement and mysql started.
$ sudo /etc/rc.d/init.d/mysql start
Input password:
Starting MySQL.
I checked and found that MySQL is running by issuing below command:
$ mysqladmin -u root -pjoomla1 ping
mysqld is alive
For me the issue was with multiple my.cnf file put in server , removing one of it(wrong file) helped me resolve the issue
If you have mysql on it's own partition (such as /var/lib/mysql), make sure that it hasn't gone read-only. to do this, attempt to create (touch) a file in that partition. if it has gone read-only, it will let you know and you will need to run a manual fsck on that partition. first make sure there are no running processes ( lsof /var/lib/mysql | awk '{print $1}'|sort|uniq -c|awk '{print $2}') then umount the partition before fscking it.
here's what I noticed after playing with my.cnf config file to try optimum performance.
If I set innodb_log_file_size to a wrong value and I try restarting the mysql server, it shuts down ok, but when it tries to start, I get something similar to the following:
Starting MySQL.The server quit without updating PID file ([FAILED]mysql/<insert pid file here>).
Then when I checked the error log to find out whats going on, I saw all this:
140709 22:47:30 mysqld_safe mysqld from pid file /var/lib/mysql/<pid filename>.pid ended
140709 22:47:31 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140709 22:47:31 [Warning] Using unique option prefix thread_cache instead of thread_cache_size is deprecated and will be removed...
140709 22:47:31 [Note] Plugin 'FEDERATED' is disabled.
140709 22:47:31 InnoDB: The InnoDB memory heap is disabled
140709 22:47:31 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140709 22:47:31 InnoDB: Compressed tables use zlib 1.2.3
140709 22:47:31 InnoDB: Using Linux native AIO
140709 22:47:31 InnoDB: Initializing buffer pool, size = 512.0M
140709 22:47:31 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 67108864 bytes!
140709 22:47:31 [ERROR] Plugin 'InnoDB' init function returned error.
140709 22:47:31 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140709 22:47:31 [ERROR] Unknown/unsupported storage engine: InnoDB
140709 22:47:31 [ERROR] Aborting
140709 22:47:31 [Note] /usr/sbin/mysqld: Shutdown complete
140709 22:47:31 mysqld_safe mysqld from pid file /var/lib/mysql/<pid filename>.pid ended
Except that I replaced the pid filename with "pid filename".
Websites think you can set innodb_log_file_size to a value but something is trying to tell me that it is a value that the mysql server calculates and its something you can't set.
This suggestion will HELP also.
REMOVE the following list so DEFAULTS can support your effort from [mysqld] section of my.cnf/.ini
sort_buffer_size
read_buffer_size
read_rnd_buffer_size
join_buffer_size
to improve(reduce) response time.
Why would you intentionally read 16M of read_rnd_buffer_size data when you could get the data you need with the DEFAULT of 256K ?
i think it will fix via hash
query_cache
you didn't mention what system are you using here. For CentOS, Fedora, and Red Hat Enterprise Linux, use service mysqld instead of mysql
sudo /etc/init.d/mysqld start
I believe the issue might be with the variable "performance_schema" found within your my.cnf file. This variable should be commented out. Give it a try.