I am trying to make mysqld use my.cnf in a different location using the command below.
./bin/mysqld --defaults-file=/apps/local/mysql/my.cnf
It is not working and the server is not starting but if i start mysqld with the command below it works fine.
./bin/mysqld --datadir=/apps/local/mysql/data
--basedir=/apps/local/mysql --port=3306 --tmpdir=/tmp --socket=/tmp/mysql.sock --pid-file=/apps/local/mysql/data/zizou.pid --log-error=/apps/local/mysql/data/zizou.err
Is there something wrong with my config file ? my.cnf looks as below.
[client]
port=3306
socket=/tmp/mysql.sock
[mysqld]
# * Basic Settings
user=mysql
pid-file=/apps/local/mysql/data/zizou.pid
socket=/tmp/mysql.sock
port=3306
basedir=/apps/local/mysql
datadir=/apps/local/mysql/data
tmpdir=/tmp
log-error=/apps/local/mysql/data/zizou.err
lc-messages-dir=/apps/local/mysql
skip-external-locking
[mysqldump]
quick
Also, i am using mysql database for drupal 6. It is using the default storage engine MYISAM. Recently, we saw an issue where the tmpdir is being used full. It only has space of 1GB. So, when we changed the tmpdir to a place where there is lot of storage, it has used 41GB in few hours of starting the server and its generating a lot of CPU load which is taking our website down.
We switched tmpdir to the directory with 1GB and there is no high CPU load and the website is working but the disk is being full. This is making me to clean it frequently. Are there any measures that i need to take to get out of this problem ?
EDIT: Can i keep deleting the .MYI and .MYD files and start the mysql server ? Is this healthy to do ?
Sorry for long post. These issues are bugging a lot.
Thank you
To setup different instance of mysql you can check here: http://dev.mysql.com/doc/refman/5.1/en/multiple-unix-servers.html
For tmpdir issue, probably you are running heavy queries.
You might get some help from here: skip copying to tmp table on disk mysql
Related
I'm facing an issue that the only way I found myself to solve it is making a factory reset of my machine.
The problem I have is that the inserts, updates, deletes and schema modifications are taking a lot of time. The disk goes up to 100%, but performs with very slow speeds. This happens when making modifications by:
Restoring backups from Workbench (speeds up to 5MB/s)
Applying migrations and seeding a new db from a NodeJS process (speeds up to 1MB/s): this process used to be finished in 2 minutes, but now it takes about 30/40 minutes.
I think this started happening when I started trying to restore big backups (like 14GB of data). I believe this is not a coincidence.
The computer works great. Copying and pasting big files speeds the disk up to 400MB/s, what is a great performance. I use it for gaming and never see any related issues, so seems like the problem only happens with MYSQL.
My environment is:
Razer Blade 15, 16GB RAM, 512 GB SSD NvME (CA5-8D512), I7 10TH processor
Windows 10
WSL 2 (Ubuntu 20.04)
MySql 8.0 (running on WSL)
MySQL Workbench (running on Windows)
My mysqld.cnf file looks like this:
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3308
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
skip-log-bin
bind-address = 127.0.0.1
mysqlx-bind-address = 127.0.0.1
key_buffer_size = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover-options = BACKUP
log_error = /var/log/mysql/error.log
max_binlog_size = 100M
expire_logs_days = 10
sql_mode=''
default-time-zone=+00:00
Additional information: I tried also using Ubuntu OS, but the same issue happened.
Schema changes are supposed to be rare. You seem to be doing them a lot.
The reason 8.0 is significantly slower than previous versions is that schema changes are now ACID, and can be rolled back. This necessitates hanging on to dropped tables, column changes, etc. That costs a lot of I/O.
Meanwhile, I suggest that the inserts, updates, and deletes are not any slower than in previous versions.
If you rarely load copies of the dataset, then consider LVM techniques. They are orders of magnitude faster than any "restore" -- even before 8.0.
I have the same effect that MySQL 8.0 ist much slower than 5.7.
To prepare an upgrade I put an 8.0 as a replication secondary to the 5.7 production primary.
The 8.0 ist unable to keep up with primary changes, seconds-behind-master is growing and growing.
When I change the secondary to a 5.7 the replication works fine.
When I am trying to check binary log:
SHOW BINARY LOGS;
I get this error:
ERROR 1381 (HY000): You are not using binary logging.
How to resolve this? Can anybody help?
Set the log-bin variable in your MySQL configuration file, then restart MySQL.
An example my.cnf (on Linux/unix) or my.ini (on Windows) would look like:
[client]
...
[mysqld]
...
log-bin=mysql-bin
---
Once restarted, MySQL automatically creates a new binary log (does so upon every restart).
You may also wish to look at the following variables:
server-id = 1
expire_logs_days = 4
sync_binlog = 1
Read details on the MySQL documentation. If you're after replication setup (a primary reason for using binary logs), check out Replication configuration checklist.
Line
log-bin=mysql-bin
must placed above lines:
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
You will need to activate binary logging at startup
Add the following lines in /etc/my.cnf under the [mysqld] section
[mysqld]
log-bin=mysql-bin
expire-logs-days=7
Then, run this
service mysql restart
The next time you login to mysql, you will see a binary log listing and will rotate out after 7 days.
The default location of the binary logs will be /var/lib/mysql or where datadir is defined. If you specify a folder before the binlog name, then that folder is the location.
For example
[mysqld]
log-bin=/var/log/mysql-bin
expire-logs-days=7
UPDATE 2012-07-12 02:20 AM EDT
Please restart mysql as follows and tell us if binary logging in on
service mysql restart --log-bin=mysql-bin
To enable the binary log, start the server with the --log-bin[=base_name] option.
If no base_name value is given, the default name is the value of the pid-file option (which by default is the name of host machine) followed by -bin.
If the basename is given, the server writes the file in the data directory unless the basename is given with a leading absolute path name to specify a different directory. It is recommended that you specify a basename.
Or you can directly use:
log-bin=mysql-bin
and then restart your mysql service. Then binary file will be generated. If you are using lampp on Linux machine then you will find this file in /lampp/var/mysql/mysql-bin.000001
FWIW, I had the same issue after I tried to set up my.cnf.master and my.cnf.slave files and symlink them to my.cnf for master and slave, respectively. The idea was to be able to switch the machine from master to slave and back easily.
It turned out that mysqld simply did not handle the symlink as expected. Hard-linking the file worked (ln my.cnf.master my.cnf). Careful if you do something like this, as overwriting one of the hard-linked filenames could break the link and create two separate files instead (depending on the method of rewriting employed by the software you use for it).
I've found logging will silently fail to happen even if my.cnf config is right, so you can also try re-creating your log folder.
This may be necwssary if the logs are in an odd state. (In my case, I had simply ceased logging in my.cnf and then re-enabled it, but nothing happened, probably because the existing files were not the latest updates?).
Something like this should work:
sudo service mysql stop
sudo mv /var/log/mysql /tmp/mysqlold # or rm -fr if you're brave
mkdir /var/log/mysql
chown -R mysql:mysql /var/log/mysql
sudo service mysql start
Obligatory warning: Obviously, take care when deleting anything on a database server. This will destroy/disrupt/corrupt any replication using this database as master (though you can resume replication as a slave). That said, I believe this should be safe insofar as it doesn't delete the database itself.
I went out of my mind with this issue on a MySQL 5.5 master running Debian. None of the above worked. Finally, I rebooted the server and logging was enabled.
Remove section [mysqld_safe] and replace with [mysqld].
It works for me.
My problem is that, when trying to run MYSQL on Fedora, I am faced with the following error:
mysql: unknown variable 'max_connections=40'
It does the exact same thing for any other of the commands, such as mysqldump, mysqlcheck etc etc
The my.cnf file reads the following, though I've renamed it and the error still occurs. It almost seems like it's a system variable that I am unable to edit without running mysql, thus the catch 22!
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
I've also of course checked the system for any other my.cnf files.
I'm really lost and starting to tear my hair out. Any help would be greatly appreciated! :)
Thanks
Matt
assuming that your good configuration file is /etc/my.cnf (which may not be), edit your mysql init file and add --init-file /etc/my.cnf to the mysqld command to make sure that it is indeed reading from the the init file that you think it is reading from.
Error : mysql: unknown variable 'max_connections=**'
One of the reasons this occurred was that max_connections parameter was updated under [mysql] section , we were able to log in after we added that under [mysqld] section.
Recently, I have found out that I can maximize mysql performance when if I have good hardware. Since I've been using InnoDB I added additional configuration into my.ini
Here is the newly added configurations:
innodb_data_file_path = ibdata1:10M:autoextend
innodb_buffer_pool_size = 2G
innodb_additional_mem_pool_size = 2M
innodb_log_file_size = 256M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 120
Then I restart all of the services. But when I used my program, an error occurred "Unknown table engine 'InnoDB'".
What I have tried to solve this problem:
I delete the log file the restart the service but I still got the error.
Other solutions did not fix my problem.
InnoDB engine was disabled after adjusting config.
Removing borked ib_* log files in mysql data dir fixed my issue, and allowed me to use 2G buffer pool for InnoDB:
http://www.turnkeylinux.org/forum/support/20090111/drupal-6-problem-enable-innodb#comment-131
I just retried deleting the logfile and restarted the services, and it works! But beware of allotting 2G because innodb might not compile, please use 1G if 2G doesn't work.
I have ran into this problem as well. The problem was that I was allocating more memory to InnoDB than the server had with the variable innodb_buffer_pool_size. MySQL did not complain about not being able to allocate the memory in its logs about this.
I tried all of those (and many others) but the one method that worked for me is:
Stop MySql Server
/etc/init.d/mysql stop
Delete the log files
rm ib_logfile0 ib_logfile1
Rename the InnoDB file (If nothing else works because it will be recreated)
mv ibdata1 old_ibdata1
I have this configs in /etc/mysql/my.cnf -> Even if you don't specify this, MySql will use the default values.
[mysqld]
datadir=/data/mysql/data
socket=/var/run/mysqld/mysqld.sock
#Not a must to define the following
innodb_log_file_size=1G
innodb_file_per_table=1
innodb_flush_method=O_DIRECT
innodb_buffer_pool_size=1G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_lock_wait_timeout=18000
Start MySql Server
/etc/init.d/mysql start
Another option you have if you mangle your my.cnf file completely is to replace it with a default config from the mysql install there . For linux:
You have the following options,
/usr/share/mysql/my-huge.cnf
/usr/share/mysql/my-innodb-heavy-4G.cnf
/usr/share/mysql/my-large.cnf
/usr/share/mysql/my-medium.cnf
/usr/share/mysql/my-small.cnf
Here is an example to install it:
#backup original config
mv /etc/my.cnf{,.bak}
#copy new my.cnf from template
cp /usr/share/mysql/my-large.cnf /etc/my.cnf
More information on these options is available at http://dev.mysql.com/doc/mysql/en/option-files.html
Had this issue when restoring from backup. Problem was I had a bit different settings in my.ini. So in case someone gets this issue just be sure to set the same settings (copy my.ini), stop the MySQL service, then restore whole data folder and then start the MySQL service again.
In MariaDB 10.1, there's an ignore-builtin-innodb option that should be disabled to stop fix error.
So, I'd like to be able to set the max log file size to 64M, but after doing so with innodb_log_file_size=64M MySQL starts OK, but nothing seems to work properly.
EDIT: and by properly I mean not at all. Setting other InnoDB variables aren't causing any problems.
How should I go about troubleshooting this one?
Make sure MySQL shuts down cleanly, and delete (or move elsewhere) all ib_logfile* files from MySQL data directory (/var/lib/mysql/ usually).
I've tested it and worked for me. Here's source of this hint.
InnoDB reports some errors in show table status comment field. You'll find other problems in MySQL error log (hostname.err in MySQL data directory).
I ran into this problem too, and as per #porneL's answer, here were my specific bash steps to correct this:
service mysql stop # Stop MySQL
rm /var/lib/mysql/ib_logfile0 # Delete log file 1
rm /var/lib/mysql/ib_logfile1 # Delete log file 2
vim my.conf # Change innodb_log_file_size = 64M
service mysql start # Start MySQL
I found these specific steps on the MySQL forums.
Before changing the innodb_log_file_size, you must flush all remaining transactional data out of it. You simply set innodb_fast_shutdown to 0 or 2.
innodb_fast_shutdown = 0 : InnoDB does a slow shutdown, a full purge and an insert buffer merge before shutting down
innodb_fast_shutdown = 2 : InnoDB flushes its logs and shuts down cold, as if MySQL had crashed; no committed transactions are lost, but the crash recovery operation makes the next startup take longer.
In light of this, this is how you handle it
mysql -ANe"SET GLOBAL innodb_fast_shutdown = 2"
vi /etc/my.cnf # Change innodb_log_file_size = 64M
service mysql stop # Stop MySQL
rm /var/lib/mysql/ib_logfile0 # Delete log file 1
rm /var/lib/mysql/ib_logfile1 # Delete log file 2
service mysql start # Start MySQL