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.
Related
I am trying to disable the query_cache_type in my mariadb pod in docker due to known performance issues with that and InnoDB. I have some current settings in a production server running on an rpm that have the following settings:
query_cache_limit=1048576
query_cache_size=1048576
query_cache_type=OFF
Yet when I try to mimic these settings on my new server, it defaults to having query_cache_type set to ON when I look at "show GLOBAL VARIABLES"
| query_cache_type | ON
I have tried to look in the error logs and see now mention of the term query_cache_type. I also restarted the docker mariadb instance to refresh the database configs and it did not update. Is there anything I should check? Could it possibly be that I need to completely remove the database to have it start with the new configs? I would rather not manually change it as it should be grabbing the right configs from my.cnf.
Starting from MariaDB 10.1.7, query_cache_type is automatically set to ON if the server is started with the query_cache_size set to a non-zero (and non-default) value.
-- https://mariadb.com/kb/en/query-cache/
So, add (or change) this to the [mysqld] section of my.cnf:
query_cache_size=0
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
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.
I am running a drupal site. I got an error in my site user warning: Got a packet bigger than 'max_allowed_packet' bytes query. I have set the value as high as 128M . Even after that same error is reported.
What is the issue here?? Why is it not working ??
Is there a maximum limit for the value max_allowed_packet ?
This is the bleeding edge:
set global max_allowed_packet=1073741824;
Although, it is probably not a good idea to set it that high in your case.
As a side note, I experienced this error with mysqldump, and setting this maximum didn't help. This did the trick: $ mysqldump --max_allowed_packet=999M -u root -p table_name > table_name.sql
Often this can be caused by the variables not actually taking effect- you make the configuration change, but in the wrong my.cnf, or you forget to bounce the app, etc.
An easy way to check a running mysql instance is to do something like this in a shell:
mysqladmin variables -u root -p
and enter in your root password. This will dump all of the current variables (including max_allowed_packet), and will let you verify what it's set to. If it's set to 128M and you're still choking on it, then you'll need to increase it- but it's pretty unlikely.
first is you need to set your max_allowed_packet to 128M in your my.cnf file.
to find it, use "locate my.cnf" command in your command line.
the file should look like this:
#
!includedir /etc/my.cnf.d
#max_allowed_packet = 1024M
[mysqld]
port = 3306
key_buffer_size = 256M
# max_allowed_packet = 100M
table_open_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
thread_concurrency = 8
bind-address = 202.90.158.47
# skip-networking
log = /var/log/mysql.access.log
log-error = /var/log/mysql.error.log
wait_timeout = 1
[mysqldump]
#max_allowed_packet = 101M
be sure to uncomment(remove the # sign before the max_allowed_packet = 128M line)
and finally, restart your sql using command "/etc/init.d/mysqld restart"
that should do the trick. :D
Edit your /etc/my.cnf, adding the max_allowed_packet variable.
It should look like this:
[mysqld]
max_allowed_packet=1000000000
Then restart your server.
Try setting max_allowed_packet = 128M as the very last option under the [mysqld] category of my.cnf.
When I had it as the first option, it would not work, but when I had it as the last option, it worked! I think this is because some other variables were over-riding max_allowed_packet.
After changing my.cnf, restart MySQL using sudo service mysql restart, and check the setting using SHOW VARIABLES LIKE 'max_allowed_packet';
You need to set the setting in all sections that apply to the action you are doing, and always in the [MySQLd] section. The setting applies to the buffer of the elements you are using. So under [MySQLd] is for your MySQL server proces deamon on linux / service on windows. And if you want to make a dump with MySQLDump add it as parameter on the command line or make a section [MySQLDump] in your my.ini as well for this tool with the same parameter to make it permanent. If you want to import the dump again with MySQL again use the parameter on the command line or make a section [MySQL] with again the same parameter in your my.ini to make the choice permanent for this tools also.
I kept on talking about my.ini because i am on windows but on linux that is my.cnf of course.
I decided to explain it here because it took me ages to figure this out because it is not explained anywhere. In examples however i noticed some ppl having the setting under multiple sections so i started to google more and found correlation between the sections and the actions they where doing. Now i never have this problem anymore and settings as high as the mentioned 128M here are not needed in most cases. However because it's the maximum the server will use for this buffer if you have the memory just set it high enough to never get into trouble with your actions. The size you actually need is a little bit larger than the largest record in your database.
I experienced this error with mysqldump with LONGBLOB fields, and setting this maximum didn't help. This did the trick:
$ mysqldump --max_allowed_packet=999M -u root -p table_name > table_name.sql
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