it is friday but no weekend yet. :( My colleague is on vacation and I myself am not a MySQL Pro.
So this morning today our pages stopped working and I am trying to fix for hours now but couldn't solve it myself.
So, baseline error is:
"Status: "InnoDB: Fatal: Trying to access page number 62087 in space 0 space name /var/lib/mysql/db/ibdata1, which is outside the tablespace bounds. Byte offset 0, len 16384 i/o type 10.Please check that the configuration matches the InnoDB system tablespace location (ibdata files)""
I did find a quite similar problem here: https://dba.stackexchange.com/questions/183862/trying-to-solve-outside-tablespace-bounds-mysql-error-but-recovering-table-wi
Sadly there is no solution provided.
The command "mysqldump" from the post above won't work anyway, as the whole service is not starting up.
I recreated the DB status from yesterday using snapper -> that is why I absolutely have no clue why it does not work now. Tried the timestamp from Wednesday - same issue.
Configuration reads:
[mysqld]
datadir=/var/lib/mysql/db
socket=/var/lib/mysql/mysql.sock
innodb_data_home_dir = /var/lib/mysql/db
innodb_data_file_path = ibdata1:10M:autoextend
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# include all files from the config directory
#
!includedir /etc/my.cnf.d
innodb_force_recovery=4
Moving / renaming the original ibdata1 did not solve anything. The thought was that maybe letting the system recreate the file would solve the problem.
Any input on this is highly appreciated.
I do not much care about data loss as long as the service will be running again, which has the highest priority right now.
Thanks a lot
James
Related
My Ubuntu 22.04 server is suddenly telling me that "The redo log file "./#innodb_redo/#ib_redo0 size 23289856 is not a multiple of innodb_page_size." My innodb_page_size is 16K, so the error is correct, but I can't seem to find any advice on how to fix it. I tried moving ib_redo0 out of the way but that didn't help. Any ideas?
I also encountered this issue. It appeared to be specific to using ZFS on Ubuntu, in my case it was during an upgrade to MYSQL 8.0.30-0ubuntu0.20.04.2.
Following details in this Ubuntu issue report and this MySQL issue report I was able to come up with a solution that worked in my environment.
There are 3 commands below to be ran as root or with sudo. You should replace 8192 in the first with the result of <broken_file_size> % <default_page_size>. The default page size is usually 16384 unless modified.
You may need to replace the #ib_redo0 part of the second command with the broken file reported in the error message.
These commands are intended to pad out the reportedly invalid file with zeros.
Perform a backup before running!
# Gather required zeros to append
# Will create a "zeros" file in the current directory
# This has been calculated based upon 23289856 % 16384 = 8192 or <broken_file_size> % <default_page_size>
dd if=/dev/zero bs=1 count=8192 of=./zeros
# Append zeroes to invalid file
cat zeros >> /var/lib/mysql/#innodb_redo/#ib_redo0
# Restart MySQL
systemctl restart mysql.service
I'd be wary of remaining on ZFS, even if the above fixes things, for the sake of potentially hitting the same issue again.
I had the same Problem in a LXD Container running on ZFS. I had to move it to a different type of storage-pool, e.g. Directory or BTRFS.
After that the solution of #DanBrown worked for me too.
Thank you.
I have a problem running MySQL 8 where the error logs are not being written. The contents of /etc/mysql/my.cnf includes:
[mysqld]
log_error_verbosity=2
log_error=/var/log/mysql/error.log
slow_query_log_file=/var/log/mysql/slow.log
long_query_time=5
slow_query_log=1
general_log_file=/var/log/mysql/general.log
general_log=1
With this configuration, both the slow.log and the general.log files are written correctly. The owner of these files is mysql:adm.
However, none of the error logs are written. The only thing that gets written to this file is the system messages when mysql is restarted.
The one thing I see different with error.log is that the owner of this file is mysql:mysql. I tried changing the owner of this file to mysql:adm, but still, no error logs are being written.
Any ideas would be greatly appreciated!
I',m having a huge issue with running MySQL#5.7 on my freshly installed 16" Macbook (with OSX 10.15.1 Catalina) During certain actions I get errors like
PDO::__construct(): MySQL server has gone away.
This is caused by the following error I found in the MySQL log.
2019-11-27T13:24:04.835245Z 0 [Warning] File Descriptor 3226 exceeded FD_SETSIZE=1024
After some research, I tried stuff like sudo launchctl limit maxfiles 65536 200000
When i run launchctl limit i get the follwing data
cpu unlimited unlimited
filesize unlimited unlimited
data unlimited unlimited
stack 8388608 67104768
core 0 unlimited
rss unlimited unlimited
memlock unlimited unlimited
maxproc 4096 4096
maxfiles 524288 524288
This looks fine to me. To get the max processes and max files correct I also tried
sudo sysctl -w kern.maxfilesperproc=524288
my.cnf looks like this
[mysqld]
open_files_limit=999999
local_infile=ON
secure_file_priv=""
max_allowed_packet=1073741824
max_connections=100000
key_buffer_size=2G
innodb_buffer_pool_size=12G
query_cache_size=67108864
query_cache_type=1
query_cache_limit=4194304
table_open_cache=4096
innodb_buffer_pool_instances=24
innodb_sort_buffer_size=2G
sort_buffer_size=1G
innodb_flush_log_at_trx_commit=0
innodb_log_file_size=3G
interactive_timeout=3600
max_connect_errors=1000000
thread_cache_size=4096
log_error=/var/log/mysql/error.log
[mysqld_safe]
open_files_limit=999999
There is of course a solution to change my table_open_cache to a lower value but that hurts performance and before i always had this on a higher number.
Anybody any clue where this FD_SETSIZE is coming from and how to change it so its used properly
rebooting has no effect by the way.
Resource explaining issue: https://expressionengine.com/blog/mysql-5.7-server-os-x-has-gone-away
try setting following environment variables in mysql configuration file (my.cnf)
interactive_timeout = 300
wait_timeout = 300
I was having this issue on Big Sur v 11.6. The solution for me was modifying the MySQL config with:
max_allowed_packet=256M
table_open_cache=250
How can I view mysql slow_query_log to see which query is taking too much time?
First, you need to check if it's enabled in your MySQL configuration (mysql.ini or mysql.cnf, depending on your system):
# enable slow log:
slow_query_log = 1
# log queries longer than n seconds:
long_query_time = 5
# where to log:
slow_query_log_file = /path/to/your/logs/mysql-slow.log
Restart your MySQL server, then watch the logfile using whatever program you like - tail is the simplest:
tail -f /path/to/your/logs/mysql-slow.log
You may need to play a bit with the long_query_time setting to find the limit where the volume of logging isn't too low or too high, but just right.
Check the location of this log in my.ini file, and then open it in any text editor.
if you ask google for "slow_query_log", this is the first hit - explaining all you need to know. you have to enable it, set a filename you like (if it's already set, you can find the configuration in you my.ini), start your queries and look ito that file...
If you're running mysqld < 5.2, your my.cnf may look like
log-slow-queries=/var/log/mysql/mysql-slow.log //where to store log
long_query_time=3 //quickest query to log
I've bee tearing my hair out trying to get MySQL 5 running on CentOS 5 but I've had hardly any luck.
If I leave everything as default, and launch the initial install it works a charm, but if I tell the my.cnf to use a different drive to store the data, I continuously get the "Timeout error occurred trying to start MySQL Daemon." error.
My.cnf is as follows:
[mysqld]
datadir=/database/mysql
socket=/database/mysql/mysql.sock
user=mysql
old_passwords=1
log-error=/database/log/mysqld.log
long_query_time = 10
log_slow_queries = /database/log/mysql-slow.log
query-cache-type = 1
query-cache-size = 8M
innodb_file_per_table
skip-bdb
set-variable = local-infile=0
[mysqld_safe]
pid-file=/var/run/mysqld/mysqld.pid
The folders all have the right privileges and the mysqld.log doesn't have any error messages in there, according to it, MySQL launced successfuly.
Oh, and /database is a mounted drive, but even if I trial it on a local directory, I get the same error.
Any ideas what could be going wrong? i've seriously waisted more than 5 hours on this now :(
CHEERS
Shouldn't the datadir be set to the other drive and everything else (socket) point to the standard install locations?
Did you check selinux settings? Make sure it is disabled (setenforce disabled), or spent some time learn about it (chcon command) To disable on boot look into /etc/sysconfig
Run the command : getenforce, if it says "Enforced", SE-Linux is On