MYSQL Unable to start the service - mysql

I just downloaded MySQL 5.0.9 source code and build and installed as root user:
./configure
./make
./make install
Now I am trying to bring up mysqld but the error says:
[root libexec]# ./mysqld
120718 7:37:09 [ERROR] Fatal error: Can't change to run as user 'mysql' ; Please check that the user exists!
120718 7:37:09 [ERROR] Aborting
120718 7:37:09 [Note] ./mysqld: Shutdown complete
[root libexec]#
Note that I did all my activity as a root user and am trying to start the service for the very first time itself?
I did what user868766 stated below but was unable to successfully execute last command. However now I get something else while trying to invoke it directly:
BTW how do we set the MySQL root password?
[root libexec]# ./mysqld
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
120718 7:52:35 InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
120718 7:52:35 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...
120718 7:52:35 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: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
120718 7:52:35 InnoDB: Started; log sequence number 0 0
120718 7:52:35 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
I just ran as per info present in the link provided by user868766:
[root bin]# mysql_install_db
Note using command other than that was giving issues:
[root bin]# mysql_install_db -user=mysql -ldata=/opt/mysql/mysql/data
Installing MySQL system tables...
120718 8:35:00 [Warning] Ignoring user change to 'ser=mysql' because the user was set to 'mysql' earlier on the command line
120718 8:35:00 [Warning] Ignoring user change to 'ser=mysql' because the user was set to 'mysql' earlier on the command line
/usr/local/libexec/mysqld: File 'data=/opt/mysql/mysql/data' not found (Errcode: 2)
120718 8:35:00 [ERROR] Could not use data=/opt/mysql/mysql/data for logging (error 2). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
OK
Filling help tables...
120718 8:35:00 [Warning] Ignoring user change to 'ser=mysql' because the user was set to 'mysql' earlier on the command line
120718 8:35:00 [Warning] Ignoring user change to 'ser=mysql' because the user was set to 'mysql' earlier on the command line
/usr/local/libexec/mysqld: File 'data=/opt/mysql/mysql/data' not found (Errcode: 2)
120718 8:35:00 [ERROR] Could not use data=/opt/mysql/mysql/data for logging (error 2). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
OK
To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/local/bin/mysqladmin -u root password 'new-password'
/usr/local/bin/mysqladmin -u root -h idc-bldtool01 password 'new-password'
Alternatively you can run:
/usr/local/bin/mysql_secure_installation
which will also give you the option of removing the test
databases and anonymous user created by default. This is
strongly recommended for production servers.
See the manual for more instructions.
You can start the MySQL daemon with:
cd /usr/local ; /usr/local/bin/mysqld_safe &
You can test the MySQL daemon with mysql-test-run.pl
cd mysql-test ; perl mysql-test-run.pl
Please report any problems with the /usr/local/bin/mysqlbug script!
The latest information about MySQL is available on the web at
http://www.mysql.com
Support MySQL by buying support/licenses at http://shop.mysql.com
[root bin]# ls -l /opt/mysql/mysql/data
total 0
However after this I am able to bring mysqld up:
[root libexec]# ./mysqld
InnoDB: Log scan progressed past the checkpoint lsn 0 36808
120718 8:37:22 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 0 43655
120718 8:37:22 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
120718 8:37:23 InnoDB: Started; log sequence number 0 43655
120718 8:37:23 [Note] ./mysqld: ready for connections.
Version: '5.0.91' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
Now I am trying to setup the root password as hinter in the above console dump:
[root~]# /usr/local/bin/mysql_secure_installation
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQL
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MySQL to secure it, we'll need the current
password for the root user. If you've just installed MySQL, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
Enter current password for root (enter for none):
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
Enter current password for root (enter for none):
Aborting!
Cleaning up...
Please let me know how can I resolve the issue?
Thanks to user868766 I managed to resolve and able to bring up mysql and connect to it.

Please try this :
1. cd /var/lib/mysql
2. adduser mysql
3. chown mysql:mysql -R /var/lib/mysql
4. service mysqld restart
Please execute the command in given order it should help you.

Related

homebrew installed mysql#5.7 does not start

I had to move from mysql (8.0.29) to mysql#5.7. MySQL in its newest formula does not compile any longer on my machine, because the machine is running Mojave in order to have native Aperture support.
I installed mysql#5.7 and changed path in my .zshrc to point to the new /usr/local/opt/mysql#5.7/bin.
After this I am still unable to start MySQL. When I run brew services list, I get:
mysql#5.7 stopped USER ~/Library/LaunchAgents/homebrew.mxcl.mysql#5.7.plist
When I try to run /usr/local/opt/mysql/bin/mysqld_safe --datadir=/usr/local/var/mysql I get:
√ ~ % /usr/local/opt/mysql/bin/mysqld_safe --datadir=/usr/local/var/mysql
2022-10-07T17:06:21.6NZ mysqld_safe Logging to '/usr/local/var/mysql/MACHINE.DOMAIN.TLD.err'.
2022-10-07T17:06:21.6NZ mysqld_safe Starting mysqld daemon with databases from /usr/local/var/mysql
/usr/local/opt/mysql/bin/mysqld_safe: line 199: 9704 Abort trap: 6 env MYSQLD_PARENT_PID=9530 nohup /usr/local/opt/mysql/bin/mysqld --basedir=/usr/local/opt/mysql --datadir=/usr/local/var/mysql --plugin-dir=/usr/local/opt/mysql/lib/plugin --log-error=MACHINE.DOMAIN.TLD.err --pid-file=mMACHINE.DOMAIN.TLD.pid < /dev/null >> /usr/local/var/mysql/MACHINE.DOMAIN.TLD.err 2>&1
2022-10-07T17:06:21.6NZ mysqld_safe mysqld from pid file /usr/local/var/mysql/MACHINE.DOMAIN.TLD.pid ended
When I check the error log file MACHINE.DOMAIN.TLD.err, I get the following output:
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 = 68222 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
0 mysqld 0x0000000101a676a9 my_print_stacktrace + 58
1 mysqld 0x00000001019e5473 handle_fatal_signal + 698
2 libsystem_platform.dylib 0x00007fff6d0b6b5d _sigtramp + 29
3 ??? 0x0000000103ae5380 0x0 + 4356723584
4 libsystem_c.dylib 0x00007fff6cf706a6 abort + 127
5 mysqld 0x0000000101c568b9 _Z23ut_dbg_assertion_failedPKcS0_m + 161
6 mysqld 0x0000000101c5929b _ZN2ib5fatalD2Ev + 91
7 mysqld 0x0000000101c592d9 _ZN2ib5fatalD1Ev + 9
8 mysqld 0x0000000101affc6d _ZL18fil_node_open_fileP10fil_node_t + 2435
9 mysqld 0x0000000101b0946b _ZL23fil_node_prepare_for_ioP10fil_node_tP12fil_system_tP11fil_space_t + 191
10 mysqld 0x0000000101b09b71 _Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_ + 796
11 mysqld 0x0000000101ad0dfc _ZL17buf_read_page_lowP7dberr_tbmmRK9page_id_tRK11page_size_tb + 415
12 mysqld 0x0000000101ad0f53 _Z13buf_read_pageRK9page_id_tRK11page_size_t + 56
13 mysqld 0x0000000101abc5d4 _Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb + 971
14 mysqld 0x0000000101c464d4 _Z31trx_rseg_get_n_undo_tablespacesPm + 251
15 mysqld 0x0000000101c296ab _Z34innobase_start_or_create_for_mysqlv + 6608
16 mysqld 0x0000000101b589d3 _ZL13innobase_initPv + 3636
17 mysqld 0x00000001014cde2e _Z24ha_initialize_handlertonP13st_plugin_int + 78
18 mysqld 0x0000000101931b46 _ZL17plugin_initializeP13st_plugin_int + 81
19 mysqld 0x000000010193164a _Z40plugin_register_builtin_and_init_core_sePiPPc + 706
20 mysqld 0x00000001019da4e2 _Z11mysqld_mainiPPc + 2918
21 libdyld.dylib 0x00007fff6cecb3d5 start + 1
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.
2022-10-07T16:36:18.6NZ mysqld_safe mysqld from pid file /usr/local/var/mysql/MACHINE.DOMAIN.TLD.pid ended
2022-10-07T16:36:28.6NZ mysqld_safe Logging to '/usr/local/var/mysql/MACHINE.DOMAIN.TLD.err'.
2022-10-07T16:36:28.6NZ mysqld_safe Starting mysqld daemon with databases from /usr/local/var/mysql
2022-10-07T16:36:29.201378Z 0 [Note] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled
2022-10-07T16:36:29.201633Z 0 [Note] /usr/local/opt/mysql#5.7/bin/mysqld (mysqld 5.7.39) starting as process 8643 ...
2022-10-07T16:36:29.205774Z 0 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
2022-10-07T16:36:29.207723Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-10-07T16:36:29.207755Z 0 [Note] InnoDB: Uses event mutexes
2022-10-07T16:36:29.207775Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2022-10-07T16:36:29.207791Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.12
2022-10-07T16:36:29.210674Z 0 [Note] InnoDB: Number of pools: 1
2022-10-07T16:36:29.210835Z 0 [Note] InnoDB: Using CPU crc32 instructions
2022-10-07T16:36:29.212601Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2022-10-07T16:36:29.224493Z 0 [Note] InnoDB: Completed initialization of buffer pool
2022-10-07T16:36:29.273548Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000!
2022-10-07 18:36:29 0x110a1e5c0 InnoDB: Assertion failure in thread 4574012864 in file ut0ut.cc line 921
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:36:29 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.
I really hope someone can point me into the right direction. Maybe you cannot switch your databases back to 5.7 from 8?
Update
When I delete my v8 DB and try to run mysqld --initialize I get:
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicuuc.70.dylib
Referenced from: /usr/local/bin/mysqld
Reason: image not found
zsh: abort mysqld --initialize
After restoring the whole /usr/local directory from Timemachine to a state before updating and upgrading Homebrew and its formulae, everything appears to be working again.
I do not know what caused my dysfunctional system. I suspect that, when I upgraded single formulae or when I installed a new formulae last week, something must have gone wrong.
The symptoms were, that single apps refused to run by complaining about the missing library /usr/local/opt/icu4c/lib/libicuuc.70.dylib. In fact icu4c had been upgraded to version 71.1.
Restoring the whole directory /usr/local returned all the apps, which I discovered as non working to a running state. I haven't run a brew update or brew upgrade yet.

Reinstall mysql-server after upgrade to Ubuntu 18.04 - errors

Mysql needed to be reinstalled after I upgraded to Ubuntu 18.04. I did 'sudo service mysqld stop' before the upgrade, and then the cleanup step must have removed mysql server. When it wasn't found I did:
sudo apt-get remove mysql-server
sudo apt-get install mysql-server
...
Setting up mysql-server-5.7 (5.7.22-0ubuntu18.04.1) ...
update-alternatives: using /etc/mysql/mysql.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode
mysqld: [Warning] World-writable config file '/etc/mysql/my.cnf' is ignored.
Please enable --log-error option or set appropriate redirections for standard output and/or standard error in daemon mode.
Warning: Unable to start the server. Please restart MySQL and run mysql_upgrade to ensure the database is ready for use.
mysqld: [Warning] World-writable config file '/etc/mysql/my.cnf' is ignored.
Please enable --log-error option or set appropriate redirections for standard output and/or standard error in daemon mode.
Warning: Unable to start the server.
...
I then ran 'systemctl status mysql.service' which reported this:
Jul 19 11:21:49 steve-VAIO mysqld[6106]: 2018-07-19T18:21:49.828124Z 0 [ERROR] InnoDB: Operating system error number 2 in a file oper
Jul 19 11:21:49 steve-VAIO mysqld[6106]: 2018-07-19T18:21:49.828132Z 0 [ERROR] InnoDB: The error means the system cannot find the pat
Jul 19 11:21:49 steve-VAIO mysqld[6106]: 2018-07-19T18:21:49.828140Z 0 [ERROR] InnoDB: Could not find a valid tablespace file for `my
Jul 19 11:21:49 steve-VAIO mysqld[6106]: 2018-07-19T18:21:49.828199Z 0 [Warning] InnoDB: Cannot calculate statistics for table `mysql
Jul 19 11:21:49 steve-VAIO mysqld[6106]: 2018-07-19T18:21:49.828232Z 0 [ERROR] Can't open and lock privilege tables: Tablespace is mi
Jul 19 11:21:49 steve-VAIO mysqld[6106]: 2018-07-19T18:21:49.846964Z 0 [Note] InnoDB: Buffer pool(s) load completed at 180719 11:21:4
Jul 19 11:21:49 steve-VAIO mysqld[6106]: 2018-07-19T18:21:49.934673Z 0 [Note] Event Scheduler: Loaded 0 events
Jul 19 11:21:49 steve-VAIO mysqld[6106]: 2018-07-19T18:21:49.934950Z 0 [Note] /usr/sbin/mysqld: ready for connections.
Jul 19 11:21:49 steve-VAIO mysqld[6106]: Version: '5.7.22-0ubuntu18.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu
Jul 19 11:21:49 steve-VAIO systemd[1]: Started MySQL Community Server.
mysqld is running and my databases are available, but I'm sure this will bite me again when it updates. phpMyAdmin shows the mysql database, which seems healthy. At the top of the list of databases is one called '#mysql50#mysql.bkp'.
Any suggestions for cleaning this up?
After suggestion to run mysql_upgrade, I did:
steve#steve-VAIO:~/workspace/JavascriptCourse$ mysql_upgrade -u root -p
mysql_upgrade: [Warning] World-writable config file '/etc/mysql/my.cnf' is ignored.
Enter password:
Checking if update is needed.
Checking server version.
Running queries to upgrade MySQL server.
mysql_upgrade: [ERROR] 1812: Tablespace is missing for table `mysql`.`plugin`.
So I'll hunt for a fix for this table's tablespace.

mysql not starting on mamp

I've been using MAMP for quite a while now but a few months ago it started to give me issues. I've since looked online through google searches and stack overflow to find a resolution but I haven't seen anything that could help me yet.
I've searched for some articles but these that I felt would have been close to helping me did not:
MAMP mysql not starting
I'm not sure the path to my data directory? and anything I type in the terminal seems to come back as commmand not found
Mysql service won't start, InnoDB init function error
MAMP mysql server won't start. No mysql processes are running
I attempted to killall but "No matching processes belonging to you were found" error was shown
About an hour ago my mqsql was working but not apache, so I found as article that said to rename Library/bin/envvars to _envvars, apache worked on startup but then mysql didn't.
I'm not getting any errors in my php log but here is my apache and mysql logs.
Here is a snippet from the bottom of the mysql error log
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 35
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
170118 15:52:39 InnoDB: Unable to open the first data file
InnoDB: Error in opening ./ibdata1
170118 15:52:39 InnoDB: Operating system error number 35 in a file operation.
InnoDB: Error number 35 means 'Resource temporarily unavailable'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html
170118 15:52:39 InnoDB: Could not open or create data files.
170118 15:52:39 InnoDB: If you tried to add new data files, and it failed here,
170118 15:52:39 InnoDB: you should now edit innodb_data_file_path in my.cnf back
170118 15:52:39 InnoDB: to what it was, and remove the new ibdata files InnoDB created
170118 15:52:39 InnoDB: in this failed attempt. InnoDB only wrote those files full of
170118 15:52:39 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
170118 15:52:39 InnoDB: remove old data files which contain your precious data!
170118 15:52:39 [ERROR] Plugin 'InnoDB' init function returned error.
170118 15:52:39 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
170118 15:52:39 [ERROR] Unknown/unsupported storage engine: InnoDB
170118 15:52:39 [ERROR] Aborting
170118 15:52:39 [Note] /Applications/MAMP/Library/bin/mysqld: Shutdown complete
170118 15:52:39 mysqld_safe mysqld from pid file /Applications/MAMP/tmp/mysql/mysql.pid ended
and then the apache error log
[Wed Jan 18 15:48:28 2017] [notice] Digest: generating secret for digest authentication ...
[Wed Jan 18 15:48:28 2017] [notice] Digest: done
[Wed Jan 18 15:48:28 2017] [notice] Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8zh DAV/2 PHP/5.3.6 configured -- resuming normal operations
[Wed Jan 18 15:48:31 2017] [notice] caught SIGTERM, shutting down
[Wed Jan 18 15:51:01 2017] [notice] Digest: generating secret for digest authentication ...
[Wed Jan 18 15:51:01 2017] [notice] Digest: done
[Wed Jan 18 15:51:01 2017] [notice] Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8zh DAV/2 PHP/5.3.6 configured -- resuming normal operations
My ports are: apache 80 and mysql 3306.
If anyone might know what might be happening that would be amazing..
Back in December, when I had this same problem in my Mac, I explored a bit and found a very simple solution:
Quit MAMP
In the finder go to Applications/MAMP/db/mysql56/ and delete the last log file, in my case ib_logfile1. (It might be a good idea to back up this file before deleting it, or alternatively move it to a different location instead of deleting it.)
Restart MAMP. That's it!
Some people had reported that deleting also ib_logfile0 was necessary, but not in my case. You can check this in JuanFra.me blog where I first posted my solution last year.
I don't know why or how this solution worked, but it seems that it has been helpful to many others, as reported in JuanFra's blog. I hope it is useful to you as well.
Another copy of MySQL/MariaDB currently running?
ibdata1 on some odd file system partition?
Did you by chance restore from a backup taken from an instance that was up?
The following is excerpted from https://dev.mysql.com/doc/refman/5.7/en/backup-types.html
Physical backup methods have these characteristics:
• Backups can be performed while the MySQL server is not running. If the server is running, it is necessary to perform appropriate locking so that the server does not change database contents during the backup. MySQL Enterprise Backup does this locking automatically for tables that require it.
To stop MySQL There are different cases depending on whether you installed MySQL with the official binary installer, using MacPorts, or using Homebrew:
MacPorts
sudo launchctl unload -w /Library/LaunchDaemons/org.macports.mysql.plist
sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql.plist
Note: this is persistent after reboot.
Homebrew
launchctl unload -w ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist
launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist
Binary installer
sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop
sudo /Library/StartupItems/MySQLCOM/MySQLCOM start
sudo /Library/StartupItems/MySQLCOM/MySQLCOM restart
If MySQL isn't starting it is pretty likely that it could already be running. You can very easily manually turn it off in the terminal.
I've had this happen to me a few times and I believe it has something to do with not shutting MAMP off correctly.
Quit MAMP.
Open the terminal and type: killall -9 mysqld
Restart MAMP.
Quit MAMP
go to /Applications/MAMP/tmp/mysql/ and add file
Restart MAMP. That's it!

MariaDB 10 CentOS 7 moving datadir woes

Brand new "minimal" install of CentOS 7 along with MariaDB 10. I have an additional mounted mirrored volume that I want to use for the datadir. Startup sequence is fine and completes normally when my.cnf [mysqld] is commented out. I've copied the data..
sudo cp -R -p /var/lib/mysql/* /mnt/mysql/
The permissions are identical to those of the original. The volume is in /etc/fstab and mounts fine
/dev/sdb1 /mnt/mysql xfs defaults 0 0
[root#femur mysql]# ls -la
total 110632
drwxr-xr-x. 5 mysql mysql 4096 Oct 20 15:27 .
drwxr-xr-x. 3 root root 18 Oct 16 16:46 ..
-rw-rw----. 1 mysql mysql 16384 Oct 20 15:27 aria_log.00000001
-rw-rw----. 1 mysql mysql 52 Oct 20 15:27 aria_log_control
-rw-r-----. 1 mysql root 7005 Oct 20 13:49 femur.err
-rw-rw----. 1 mysql mysql 12582912 Oct 20 15:27 ibdata1
-rw-rw----. 1 mysql mysql 50331648 Oct 20 15:27 ib_logfile0
-rw-rw----. 1 mysql mysql 50331648 Oct 20 12:21 ib_logfile1
-rw-rw----. 1 mysql mysql 0 Oct 20 12:22 multi-master.info
drwx--x--x. 2 mysql mysql 4096 Oct 20 12:21 mysql
drwx------. 2 mysql mysql 4096 Oct 20 13:37 performance_schema
drwxr-xr-x. 2 mysql mysql 6 Oct 20 12:21 test
this is in my.cnf
!includedir /etc/my.cnf.d
[mysqld]
log_error = /var/log/mysql-error.log
user = mysql
datadir = /mnt/mysql
socket = /mnt/mysql/mysql.sock
This is what I get when I try to start it...
'[root#femur mysql]# sudo systemctl start mysql.service
Job for mysql.service failed. See 'systemctl status mysql.service' and 'journalctl -xn' for details.'
Neither of those two files says much, but this is in /var/log/mysql-error.log
141020 16:07:09 mysqld_safe Starting mysqld daemon with databases from /mnt/mysql
141020 16:07:09 [Warning] Can't create test file /mnt/mysql/femur.lower-test
141020 16:07:09 [Note] InnoDB: Using mutexes to ref count buffer pool pages
141020 16:07:09 [Note] InnoDB: The InnoDB memory heap is disabled
141020 16:07:09 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
141020 16:07:09 [Note] InnoDB: Memory barrier is not used
141020 16:07:09 [Note] InnoDB: Compressed tables use zlib 1.2.7
141020 16:07:09 [Note] InnoDB: Using Linux native AIO
141020 16:07:09 [Note] InnoDB: Using CPU crc32 instructions
141020 16:07:09 [Note] InnoDB: Initializing buffer pool, size = 128.0M
141020 16:07:09 [Note] InnoDB: Completed initialization of buffer pool
2014-10-20 16:07:09 7f6cb59c9880 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.
141020 16:07:09 [ERROR] InnoDB: os_file_get_status() failed on './ibdata1'. Can't determine file permissions
141020 16:07:09 [ERROR] InnoDB: The system tablespace must be writable!
141020 16:07:09 [ERROR] Plugin 'InnoDB' init function returned error.
141020 16:07:09 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
141020 16:07:09 [ERROR] mysqld: File '/mnt/mysql/aria_log_control' not found (Errcode: 13 "Permission denied")
141020 16:07:09 [ERROR] mysqld: Got error 'Can't open file' when trying to use aria control file '/mnt/mysql/aria_log_control'
141020 16:07:09 [ERROR] Plugin 'Aria' init function returned error.
141020 16:07:09 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
141020 16:07:09 [Note] Plugin 'FEEDBACK' is disabled.
141020 16:07:09 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
141020 16:07:09 [ERROR] Unknown/unsupported storage engine: InnoDB
141020 16:07:09 [ERROR] Aborting
141020 16:07:09 [Note] /usr/sbin/mysqld: Shutdown complete
141020 16:07:09 mysqld_safe mysqld from pid file /mnt/mysql/femur.pid ended
http://www.reddit.com/r/linuxadmin/comments/2ebhpf/adventures_in_moving_mariadb_data_folder/ helped a bit, but I wasn't able to get it to work.
Any help would be greatly appreciated.
The issue is indeed SELinux; you need to do three things before MariaDB / MySQL will start on CentOS 7:
Ensure the user:group is mysql:mysql
Set the SELinux tag to mysqld_db_t
Set the SELinux user to system_u
This is as simple as:
chcon -Rt mysqld_db_t /database/db
chcon -Ru system_u /database/db
chown -R mysql:mysql /database/db
The whole thing I needed to do after plugging in a disk is below:
cfdisk /dev/sdb
pvcreate /dev/sdb1
vgcreate database /dev/sdb1
lvcreate -l 100%FREE -n db database
mkfs.ext4 /dev/database/db
mkdir /database
mount /database
mkdir /database/db
chcon -Rt mysqld_db_t /database/db
chcon -Ru system_u /database/db
chown -R mysql:mysql /database/db
systemctl start mariadb
Well that was interesting...
It turns out, that CentOS 7 "minimal" installs SELinux, which apparently was preventing mysql from writing to the mounted mirrored set. I was looking for security items that I might not have thought about and found it right there in the docs. I had previously thought (obviously erroneously) that SELinux was a distribution, not a module. Once I ran the test to see if it was there....
getenforce
I temporarily disabled it to test.
setenforce 0
Finally, I was able to start MariaDB with the directory in the mirrored set as the datadir and no errors. To make this change permanent (because this server is behind a firewall), in /etc/selinux/config, I made
- SELINUX=enforcing
+ SELINUX=disabled
I hope this helps someone else. Have a great day!
I found this step by step guide working for me: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/sect-Managing_Confined_Services-MariaDB-Configuration_Examples.html
You must install:
yum install policycoreutils-python
Guide:
View the SELinux context of the default database location for mysql:
~]# ls -lZ /var/lib/mysql
drwx------. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql
This shows mysqld_db_t which is the default context element for the location of database files. This context will have to be manually applied to the new database location that will be used in this example in order for it to function properly.
Stop the mysqld daemon:
~]# systemctl stop mariadb.service
Create a new directory for the new location of the database(s). In this example, /mysql/ is used:
~]# mkdir -p /mysql
Copy the database files from the old location to the new location:
~]# cp -R /var/lib/mysql/* /mysql/
Change the ownership of this location to allow access by the mysql user and group. This sets the traditional Unix permissions which SELinux will still observe:
~]# chown -R mysql:mysql /mysql
Run the following command to see the initial context of the new directory:
~]# ls -lZ /mysql
drwxr-xr-x. mysql mysql unconfined_u:object_r:usr_t:s0 mysql
The context usr_t of this newly created directory is not currently suitable to SELinux as a location for MariaDB database files. Once the context has been changed, MariaDB will be able to function properly in this area.
Open the main MariaDB configuration file /etc/my.cnf with a text editor and modify the datadir option so that it refers to the new location. In this example the value that should be entered is /mysql:
[mysqld]
datadir=/mysql
Save this file and exit.
Start mysqld. The service should fail to start, and a denial message will be logged to the /var/log/messages file:
~]# systemctl start mariadb.service
Job for mariadb.service failed. See 'systemctl status postgresql.service' and 'journalctl -xn' for details.
However, if the audit daemon is running and with him the setroubleshoot service, the denial will be logged to the /var/log/audit/audit.log file instead:
SELinux is preventing /usr/libexec/mysqld "write" access on /mysql. For complete SELinux messages. run sealert -l b3f01aff-7fa6-4ebe-ad46-abaef6f8ad71
The reason for this denial is that /mysql/ is not labeled correctly for MariaDB data files. SELinux is stopping MariaDB from having access to the content labeled as usr_t. Perform the following steps to resolve this problem:
Run the following command to add a context mapping for /mysql/. Note that the semanageutility is not installed by default. If it missing on your system, install the policycoreutils-pythonpackage.
**~]# semanage fcontext -a -t mysqld_db_t "/mysql(/.*)?"**
This mapping is written to the /etc/selinux/targeted/contexts/files/file_contexts.local file:
~]# grep -i mysql /etc/selinux/targeted/contexts/files/file_contexts.local
/mysql(/.*)? system_u:object_r:mysqld_db_t:s0
Now use the restorecon utility to apply this context mapping to the running system:
**~]# restorecon -R -v /mysql**
Now that the /mysql/ location has been labeled with the correct context for MariaDB, mysqldstarts:
~]# systemctl start mariadb.service
Confirm the context has changed for /mysql/:
~]$ ls -lZ /mysql
drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql
The location has been changed and labeled, and mysqld has started successfully. At this point all running services should be tested to confirm normal operation.

restore physical backups for mysql using xtrabackup

I backup mysql database, and then try to restore it in a later version using xtrabackup, mysql service can't start up.
old mysql version:5.0.90;
new version:5.5.31
Recovery Steps:
innobackupex --use-memory=4G --apply-log /data/backups/2010-03-13_02-42-44/
innobackupex --copy-back /data/backups/2010-03-13_02-42-44/
The second step shows that xtrabackup restored mysql database completely.
sudo mysql service start mysql
I try to start mysql service, it shows "Job failed to start".i check the permission of these database files,as you can see below.
-rw-r--r-- 1 mysql mysql 209715200 7月 11 06:02 ibdata1
-rw-r--r-- 1 mysql mysql 1048576000 7月 11 06:03 ib_logfile0
-rw-r--r-- 1 mysql mysql 1048576000 7月 11 06:03 ib_logfile1
drwxr-xr-x 2 mysql mysql 4096 7月 11 06:02 mysql
drwxr-xr-x 2 mysql mysql 12288 7月 11 06:02 sp5084afbe48ce9
drwxr-xr-x 2 mysql mysql 4096 7月 11 06:02 test
-rw-r--r-- 1 mysql mysql 52 7月 11 06:02 xtrabackup_binlog_pos_innodb
-rw-r--r-- 1 mysql mysql 76 7月 11 06:02 xtrabackup_slave_info
This is the error:
InnoDB: Error: log file ./ib_logfile0 is of different size 0 1048576000 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
130711 6:08:56 [ERROR] Plugin 'InnoDB' init function returned error.
130711 6:08:56 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
130711 6:08:56 [ERROR] Unknown/unsupported storage engine: InnoDB
130711 6:08:56 [ERROR] Aborting
130711 6:08:56 [Note] /usr/sbin/mysqld: Shutdown complete
Check the /etc/mysql/my.cnf and look for the
innodb_log_file_size = 5M
and change that to
innodb_log_file_size = 1000M
Cause 1048576000/1024/1024=1000 and that is how much is InnoDB engine is expecting for log file size.
similar problem