Starting MySQL.Manager of pid-file quit without updating fi error - mysql

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.

Related

Mariadb won't start after hard reboot

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

Unable to start mysql after restarting server

I restarted server where mysql is installed since then it is not getting started below is the error log i got when the try to start mysqld service.I checked whether any mysqld_safe is running using ps ax | grep mysql seems nothing is running
160506 08:54:53 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
160506 08:54:59 mysqld_safe Starting mysqld daemon with databases from /data/mysql
160506 8:54:59 [ERROR] /usr/libexec/mysqld: ambiguous option '--i' (ignore-builtin-innodb, interactive_timeout)
160506 8:54:59 [ERROR] Aborting
160506 08:54:59 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
My.cnf
[mysqld]
server-id=832
#datadir=/var/lib/mysql
#datadir=/database/mysql/data
datadir=/data/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
lower_case_table_names=1
max_connections=2048
#check
# this happens when max_allowed_packet=1M but not when max_allowed_packet=2M,
i# actually 1638400 is already fine
max_allowed_packet=1024M
key_buffer=128M
max_user_connections=32768
tmp_table_size=128M
table_cache=524288 # old value is 1024M
query_cache_size=512M
query_cache_type=1
sort_buffer=128M
join_buffer_size=32M
read_buffer=128M
#set-variable = write_buffer=128M Timeout occurs if opened this
#record_buffer=128M old parameter please use read_buffer_size instead
read_buffer_size=512M # old value is 128M
myisam_sort_buffer_size=64M
myisam_max_sort_file_size=2G
back_log=100
interactive_timeout=10000
wait_timeout=1000
connect_timeout=1000
net_read_timeout=1000
open_files_limit=30000
thread_concurrency=512
thread_cache_size=16384 #old value is 128M
thread_stack=8M
#end of check
## extra parameters verify and remove
#TransactionDeadlockDetectionTimeout=100 Notworking
#HeartbeatIntervalDbDb=3000
#HeartbeatIntervalDbApi=3000
#innodb_buffer_pool_size=4096M
innodb_buffer_pool_size=1G
innodb_additional_mem_pool_size=512M
innodb_thread_concurrency=0
innodb_file_per_table=1
sort_buffer=128M
#log_slow_queries=ON
slow_query_log=/database/mysql/log/slowlog
max_sp_recursion_depth=5
## upto Here
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
Re-installing mysql binaries does the job for me

Percona XtraDB Cluster 5.6 does not start

All the good days. I want to run for test purposes Percona XtraDb Cluster on ubuntu 14.04. The basis here took these two articles
https://habrahabr.ru/post/152969/
https://www.percona.com/doc/percona-xtradb-cluster/5.6/manual/bootstrap.html
I came instead
Ну и в завершение, перезапускаем демона:
The daemon does not start
$ sudo /etc/init.d/mysql start
* Starting MySQL (Percona XtraDB Cluster) database server mysqld
* The server quit without updating PID file (/var/lib/mysql/vagrant-ubuntu-trusty-64.pid).
...fail!
The logs several errors. Error one:
[ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
Sure I ran mysql_upgrade, but it does not work
$ sudo mysql_upgrade
Looking for 'mysql' as: mysql Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed
Error two:
160502 14:56:26 [ERROR] Plugin 'InnoDB' init function returned error.
160502 14:56:26 [ERROR] Plugin 'InnoDB' registration as a STORAGE
ENGINE failed. 160502 14:56:26 [ERROR] Unknown/unsupported storage
engine: InnoDB 160502 14:56:26 [ERROR] Aborting
All are advised to remove all of the folders / var / lib / mysql and supposedly starts. But I deleted and nothing worked.
My file my.cnf
[mysqld_safe]
# wsrep_urls=gcomm://192.168.33.101:3400,gcomm://192.168.33.102:3400,gcomm://
#wsrep_urls=gcomm://192.168.33.101:3400,gcomm://
[mysqld]
innodb_log_file_size=256M
wsrep_cluster_address=gcomm://192.168.33.101
port=3306
socket=/var/run/mysqld/mysqld.sock
datadir=/var/lib/mysql
basedir=/usr
user=mysql
log_error=/var/log/mysql.err
binlog_format=ROW
default_storage_engine=InnoDB
wsrep_provider=/usr/lib/libgalera_smm.so
wsrep_sst_receive_address=192.168.33.101:3500
wsrep_node_incoming_address=192.168.33.101
wsrep_slave_threads=2
wsrep_cluster_name=cluster0
wsrep_provider_options="gmcast.listen_addr=tcp://192.168.33.101:3400;"
wsrep_sst_method=xtrabackup
wsrep_sst_auth=backup:password
wsrep_node_name=node0
innodb_locks_unsafe_for_binlog=1
innodb_autoinc_lock_mode=2
innodb_buffer_pool_size=5000M
innodb_log_file_size=256M
innodb_log_buffer_size=4M
[client]
port=3306
socket=/var/run/mysqld/mysqld.sock
Actually the question: how to start? If there is anyone working configuration, then please share.
For the record:
Percona is amazing, but highly undocumented.
When it comes to configuring it, ive learned less is better.
important parts:
server-id required
these may be braking it, in my experience.
wsrep_sst_receive_address=192.168.33.101:3500
wsrep_node_incoming_address=192.168.33.101
Config from my cluster:
[mysqld]
server-id=18
datadir=/var/lib/mysql
wsrep_provider=/usr/lib/libgalera_smm.so
# Cluster connection URL -|-node0, -|-node1, -|-node2 -|-node3 -|-node4 -|-node5 -|-node6 -|-node7 -|-node8
wsrep_cluster_address=gcomm://192.168.1.18,192.168.1.19,192.168.1.20 #removed some
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
wsrep_sst_method=rsync
wsrep_sst_auth="root:password"
wsrep_cluster_name=grapes
innodb_buffer_pool_size=5140
innodb_buffer_pool_instances=4
innodb_flush_log_at_trx_commit=0
query_cache_size=0

mysql on amazon linux - MySQL Daemon failed to start

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

Amazon EC2 MySQL Failed to Start

I'm having issues starting MySQL after it randomly stopped working a few minutes ago. I'm getting this error while trying to connect:
Connect failed: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
So I tried to restart MySQL (this had worked for me before) and I got this:
Stopping mysqld: [ OK ]
MySQL Daemon failed to start.
Starting mysqld: [FAILED]
Here's my error log:
130414 20:03:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130414 20:03:45 [Note] Plugin 'FEDERATED' is disabled.
130414 20:03:45 InnoDB: The InnoDB memory heap is disabled
130414 20:03:45 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130414 20:03:45 InnoDB: Compressed tables use zlib 1.2.5
130414 20:03:45 InnoDB: Using Linux native AIO
130414 20:03:45 InnoDB: Initializing buffer pool, size = 128.0M
130414 20:03:45 InnoDB: Completed initialization of buffer pool
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
130414 20:03:45 InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
130414 20:03:46 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
130414 20:03:46 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: 127 rollback segment(s) active.
InnoDB: Creating foreign key constraint system tables
Can anyone offer some tips? I'm pretty noobish at this server stuff :P
Many thanks!
I fixed this by restarting my EC2 instance.
Restarting the instance helps, but it doesn't resolve it permanently.
This is what I used to resolve it:
http://www.prowebdev.us/2012/05/amazon-ec2-linux-micro-swap-space.html
Amazon EC2 Micro Instance Swap Space - Linux
I have a Amazon EC2 Linux Micro instance. Since Micro instances have only 613MB of memory, MySQL crashed every now and then. After a long search about MySQL, Micro Instance and Memory Managment I found out there is no default SWAP space for Micro instance. So if you want to avoid the crash you may need to setup a swap space for your micro instance. Actually performance wise is better to enable swap.
Steps below show how to make a swap space for your Micro instance. I assume you have AWS Account with a Micro instance running.
1.) Run dd if=/dev/zero of=/swapfile bs=1M count=1024
2.) Run mkswap /swapfile
3.) Run swapon /swapfile
4.) Add this line /swapfile swap swap defaults 0 0 to /etc/fstab
Step 4 is needed if you would like to automatically enable swap file after each reboot.
Some useful command related to SWAP space:
$ swapon -s
$ free -k
$ swapoff -a
$ swapon -a
References:
http://www.thegeekstuff.com/2010/08/how-to-add-swap-space/
http://cloudstory.in/2012/02/getting-the-best-out-of-amazon-ec2-micro-instances/
http://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the-performance/
http://aws.amazon.com/ec2/instance-types/
In My case i solved it by clearing some space in server.
I was taking backup of database on daily basis which results in consumption of lots of space.
I deleted all those backup and started mysql.
I also had faced the same challenge this is what I explored, the reason for restarting can be one of the below:
There have been updates applied at your EC2 instance, causing the MySql service to stop and not able to restart again.
There may be other processes running along which cause a crunch in memory, thus not allowing the MySql to restart.
To Tackle this you can either use one of the below:
If your MySql service is going down because of memory issue -- Upgrade your instance.
If your mysqld restart command fails, try to restart the httpd service first and then your mysql service. Here are the commands:
sudo service httpd restart
sudo service mysqld restart
If none of the above work restart your EC2 Instance. Not a permanent fix, but help if you want your services to be up and running, and later want to do an RCA of the issue
If you want you can create a script shown below, and execute it after via a cron-job every 5-10 mins depending on your requirement :
#!/bin/bash
dateFormat=`date "+%Y-%m-%d %T"`
log_file_path="/home/ec2-user/mysql_restart_log.dat"
sudo service mysqld status | grep "is running"
if [ $? -ne 0 ]; then
echo "HTTPD restart attempted ${dateFormat}" >> ${log_file_path}
sudo service httpd restart
if [ $? -ne 0 ]; then
echo "HTTPD restart failed... ${dateFormat}" >> ${log_file_path}
else
echo "HTTPD restart success... ${dateFormat}" >> ${log_file_path}
fi
echo "MYSQL restart attempted ${dateFormat}" >> ${log_file_path}
sudo service mysqld restart
if [ $? -ne 0 ]; then
echo "MYSQL restart failed... ${dateFormat}" >> ${log_file_path}
else
echo "MYSQL restart success... ${dateFormat}" >> ${log_file_path}
fi
fi
Also found this link helpful: mysql on amazon linux - MySQL Daemon failed to start
I had this issue too on an EC2 micro instance I was running WordPress on. Turned out that Apache was being a memory hog, which was not allowing mysqld to start/re-start. Once I edited httpd.conf to tame apache's memory use, httpd started with no issues.
I have seen this issue multiple times on multiple AWS servers, main root cause in my cases was lack of space. I deleted some unused files from the server which were taking space and problem was resolved.
This issue of lack of space will also stop your apache from running.