According to MySQL Documentation, the global variable Uptime is defined as "The number of seconds that the server has been up.".
However, can somebody please explain to me how this value is actually computed? What does it use as a reference, System Time?
I am asking this question because I just came across a weird situation : when rebooting a VM with MySQL, ntpd service terminated, and at startup (since was not on chkconfig), the time got shifted +8 hours, as you can see by the following :
15:01:00 hostname shutdown[30383]: shutting down for system reboot
15:01:00 hostname init: Switching to runlevel: 6
...
15:01:06 hostname ntpd[27553]: ntpd exiting on signal 15
15:01:06 hostname syslog-ng[27399]: Termination requested via signal, terminating;
...
23:04:03 hostname kernel: Bootdata ok
The same shift is recorded in the MySQL error logs :
15:01:03 InnoDB: Starting shutdown...
15:01:05 InnoDB: Shutdown completed; log sequence number 2746293826
15:01:06 [Note] /usr/sbin/mysqld: Shutdown complete
15:01:06 mysqld_safe mysqld from pid file /var/lib/mysql/data/hostname.pid ended
23:04:06 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql/data
After we fixed the time by starting ntpd, it seemed that the Uptime got shifted :
mysql> show global status like 'Uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime | 18005 |
+---------------+-------+
1 row in set (0.00 sec)
mysql> show global status like 'Uptime_since_flush_status';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| Uptime_since_flush_status | 18007 |
+---------------------------+-------+
Is this behavior possible, or it probably related to other factors?
Thank you for your patience and understanding.
Should be very simple. The application will create a timestamp from when it starts and compare it to the current time. These times are given from the system time.
So if you modify the system time, it will not adjust the initial timestamp. It will consider the time change as the current time and relay that as its comparison.
Related
I have a mysql galera server ( innodb) datadir which got crashed with because of network failure . I am trying to restore the db thru the filesystem . tried innodb_force_recovery flag 1 ,
[mysqld]
innodb_force_recovery = 1
Started the database
/etc/init.d/mysql start
Database is up but the the logs shows errors.
2022-03-04 11:07:08 139852880054528 [ERROR] mysqld: Table './mysql/user' is marked as crashed and should be repaired
2022-03-04 11:07:08 139852880054528 [Warning] Checking table: './mysql/user'
2022-03-04 11:07:08 139852880054528 [ERROR] mysql.user: 1 client is using or hasn't closed the table properly
2022-03-04 11:07:08 139852880054528 [ERROR] mysqld: Table './mysql/db' is marked as crashed and should be repaired
2022-03-04 11:07:08 139852880054528 [Warning] Checking table: './mysql/db'
2022-03-04 11:07:08 139852880054528 [ERROR] mysql.db: 1 client is using or hasn't closed the table properly
2022-03-04 11:07:08 139852878686976 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
Repaired the table
bash-4.2$ myisamchk -r --update-state /var/lib/mysql/mysql/user.MYI
- recovering (with sort) MyISAM-table '/var/lib/mysql/mysql/user.MYI'
Data records: 15
- Fixing index 1
bash-4.2$ myisamchk -r --update-state /var/lib/mysql/mysql/db.MYI
- recovering (with sort) MyISAM-table '/var/lib/mysql/mysql/db.MYI'
Data records: 18
- Fixing index 1
- Fixing index 2
Restarted the db server
/etc/init.d/mysql start
The db server is coming up . but showing only information_schema database . no other database is listed not even system db like mysql,performance_schema.
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 7
Server version: 10.1.24-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
+--------------------+
1 row in set (0.02 sec)
Checked the datadir and the folders and all looks good . Any change in process or different process to get it working?
Not sure what's going on here, as far as I know everything is set as it's supposed to be but the log stays empty:
[root#myLaptop Me]# cat /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
[mysqld_safe]
log-error=/var/log/mysqld.log
log=/var/log/mysqld.general.log
general_log_file=/var/log/mysqld.general.log
pid-file=/var/run/mysqld/mysqld.pid
[root#myLaptop Me]# service mysqld stop
Redirecting to /bin/systemctl stop mysqld.service
[root#myLaptop Me]# service mysqld start
Redirecting to /bin/systemctl start mysqld.service
[root#myLaptop Me]# mysql -u root -p
Enter password:
... Welcome stuff
Server version: 5.5.30 MySQL Community Server (GPL)
mysql> SET GLOBAL log_output = "FILE";SET GLOBAL general_log = 'ON';
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.05 sec)
mysql> SHOW PROCESSLIST;
+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+------+---------+------+-------+------------------+
| 3 | root | localhost | NULL | Query | 0 | NULL | SHOW PROCESSLIST |
+----+------+-----------+------+---------+------+-------+------------------+
1 row in set (0.00 sec)
mysql> quit
Bye
[root#myLaptop Me]# tail /var/log/mysqld.general.log
[root#myLaptop Me]# <= shows nothing at all
[root#myLaptop Me]# ls -l /var/log/mysqld.general.log
-rw-r--r--. 1 mysql mysql 0 May 31 10:06 /var/log/mysqld.general.log
[root#myLaptop Me]# tail /var/log/mysqld.log
130531 10:28:04 InnoDB: Completed initialization of buffer pool
130531 10:28:04 InnoDB: highest supported file format is Barracuda.
130531 10:28:04 InnoDB: Waiting for the background threads to start
130531 10:28:05 InnoDB: 5.5.30 started; log sequence number 2969208
130531 10:28:05 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130531 10:28:05 [Note] - '0.0.0.0' resolves to '0.0.0.0';
130531 10:28:05 [Note] Server socket created on IP: '0.0.0.0'.
130531 10:28:05 [Note] Event Scheduler: Loaded 0 events
130531 10:28:05 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.30' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL)
[update]
I think fedora 17 starts mysql with parameters that override the my.cnf the log is not where the my.cnf tells it to be:
[root#Laptop Symfony]# mysql -u root -p
mysql> select ##global.general_log_file;
+----------------------------+
| ##global.general_log_file |
+----------------------------+
| /var/lib/mysql/Laptop.log |
+----------------------------+
First, I would check the logging options
please see the logging options from IBM MySQL reference
On my servers, I always create a new directory in /var/log and "give" it to mysql (to be executed as root or via sudo)
sudo mkdir /var/log/mysql
sudo chown mysql:mysql /var/log/mysql
then all logging options from my.cnf are a file inside that directory
log=/var/log/mysql/general.log
log-error=/var/log/mysql/error.log
log-slow-queries=/var/log/mysql/slowquery.log
to be sure in any case, mysql can create and access the files. Moreover, it helps to visit all the mysql log files at once, since the /var/log directory is pretty busy with many things not related to mysql.
Then, as why the current log files are empty, some log information may be buffered at the time you check the files. To force mysql to write to the files (or the underlying IO libraries) so that the text is visible from outside mysql (ie tail), you can execute (mysql command)
FLUSH LOGS;
There is an interesting article on empty log files.
be sure that variable:general_log=ON，if this variable is "OFF"，mysql will not print anything to general_log file.
you can check mysql error log file to look up is there any errors happened
My MySQL events never want to execute.
I use the latest 5.6.10 release but the problem was also in the 5.5 versions.
I have 1 Master- Many Slaves configuration. I want to run the event on the Master.
In my.ini i have already set
event_scheduler=ON
2, Checking this:
show variables like '%event_scheduler%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| event_scheduler | ON |
+-----------------+-------+
show processlist\G
Id: 1
User: event_scheduler
Host: localhost
db: NULL
Command: Daemon
Time: 720
State: Waiting on empty queue
Info: NULL
...
3, Next i have a recurring event on the master server.
This never want to execute. I also tried to change the date to different time.
CREATE EVENT IF NOT EXISTS dbname.event_xyz
ON SCHEDULE EVERY 1 DAY STARTS '2013-02-05 00:15:00'
ON COMPLETION PRESERVE
DISABLE ON SLAVE
COMMENT 'Collect data from ...'
DO CALL dbname._procedurename;
I have no errors calling the "_procedurename" procedure directly.
4, The creator of the event and the procedure is the "root".
5, The output of the
show events\G
Db: dbname
Name: event_xyz
Definer: root#localhost
Time zone: SYSTEM
Type: RECURRING
Execute at: NULL
Interval value: 1
Interval field: DAY
Starts: 2013-02-05 00:15:00
Ends: NULL
Status: SLAVESIDE_DISABLED
Originator: 1
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: utf8_general_ci
6, Restarting the master server i get the following lines in the
masterservername.err:
...
Event Scheduler: Purging the queue. 0 events
...
Event Scheduler: Loaded 0 events
...
and the
show processlist\G
shows that the event_scheduler
State: Waiting on empty queue !
So, my question is why does not run the event on my master server?
Why the event scheduler does not know anything about the previously defined event?
Am I missing something?
Perhaps this is a bug.
The solution was to remove the
DISABLE ON SLAVE
parameter from the event declaration command.
After this, the event state changed to "ENABLED" status and fired by the Event Scheduler on the Master server.
On the slaves the State of this event replicated with "SLAVESIDE_DISABLED" status.
So, for what purpose exists the "DISABLE ON SLAVE" parameter in the CREATE EVENT syntax?
This might be bug http://bugs.mysql.com/bug.php?id=67191 , fixed in 5.6.14
I am running MySQL on an Amazon Linux AMI. There is nothing connected to it. There are no connections and no other applications running that use MySQL. It is completely idle, but yet, top is reporting that mysql is using 62% of the CPU? Why is this happening and how do I fix it?
Cpu(s): 0.2%us, 0.2%sy, 0.0%ni, 97.8%id, 0.0%wa, 0.0%hi, 0.0%si, 1.7%st
Mem: 1738504k total, 390708k used, 1347796k free, 56888k buffers
Swap: 917500k total, 0k used, 917500k free, 229804k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2959 mysql 20 0 466m 39m 5244 S 62.2 2.3 4:00.67 mysqld
1 root 20 0 19252 1504 1212 S 0.0 0.1 0:00.20 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
There are no connections...
mysql> show processlist;
+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+------+---------+------+-------+------------------+
| 5 | root | localhost | NULL | Query | 0 | NULL | show processlist |
+----+------+-----------+------+---------+------+-------+------------------+
UPDATE:
My issue was definitely related to the Lead Second bug. Kudos to nico-ekito. Thanks!
The only thing I can think of is to inspect what mysqld is really doing using strace, as user root:
strace -p 2959
Normally, strace should block immediately and show you a call to select(), because mysqld should be waiting for connections.
The call should be something like:
select(SOCKETNO, [OTHER_FDs], NULL, NULL, NULL)
especially important is the fourth parameter, which is a timeout timeval. If NULL, it means that mysqld will sleep until someone connects. If not NULL, it means that mysqld will wait for the specified time and then do some maintenance work. A very small timeval might explain the CPU consumption.
I believe that MySQL always employs a NULL (infinite) timeout. It makes sense and this is how the mysqlds I'm able to reach now are behaving.
However, there might be some connection handling issues that prevent select from sleeping again. Check whether this behaviour appears as soon as mysqld starts, or after someone connects.
Closing out this question. My issue was indeed related to the Leap Second fiasco.
I have no idea of what I have done here, but my InnoDB engine seems to have gone from my MySQL server. I recently upgraded it from the dotdeb repository, then installed mysql-server.
There is no mention of InnoDB in my my.cnf except some comments which explain InnoDB is enabled by default, which I don't understand. There is also no mention of InnoDB in SHOW ENGINES.
Is there something I'm missing here?
If it matters, my MySQL server version is: 5.5.24-1~dotdeb.1 (Debian).
EDIT: SHOW ENGINES:
mysql> SHOW ENGINES;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO |
| FEDERATED | NO | Federated MySQL storage engine | NULL | NULL | NULL |
| BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO |
| MyISAM | DEFAULT | MyISAM storage engine | NO | NO | NO |
| CSV | YES | CSV storage engine | NO | NO | NO |
| ARCHIVE | YES | Archive storage engine | NO | NO | NO |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
8 rows in set (0.00 sec)
The problem is most probably a non-matching log file size: mysql expects the innodb log files to be exactly the size that is specified in the config file. To check whether this is really the issue, do the following:
sudo /etc/init.d/mysql restart
sudo tail -n 1000 /var/log/syslog
(I'm assuming you are on Debian)
If you see some errors reported there regarding innodb and log file size (Sorry, I can't remember the exact wording of the message), then the fix is easy:
locate the logfiles (probably /var/lib/mysql/ib_logfile0 and /var/lib/mysql/ib_logfile1)
stop the mysql server
rename the log files: sudo mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.bak etc.
start the mysql server
check in /var/log/syslog whether the errors are no longer happening
connect to mysql and check via SHOW ENGINES; whether InnoDB is available now...
Hope this helps!
The first thing to do is to run SHOW ENGINES at the MySQL prompt to confirm if Innodb is disabled.
If it is, check the error log for the MySQL server. It will have details on why InnoDB was disabled. There are several reasons MySQL might disable InnoDB on startup. For example, if the innodb log file size specified in my.cnf does not match the size of the existing log file(s) on disk.
I've got this problem with Debian 7 server with preinstalled mysql 5.5. There was no InnoDB engine after SHOW ENGINES
As severin mentioned before run this:
sudo /etc/init.d/mysql restart
sudo tail -n 1000 /var/log/syslog
I've got this one:
InnoDB: Error: io_setup() failed with EAGAIN after 5 attempts.
And solution on other line:
InnoDB: You can disable Linux Native AIO by setting innodb_use_native_aio = 0 in my.cnf
After adding innodb_use_native_aio = 0 to my.cnf InnodDB appeared in SHOW ENGINES
Check if you have enough space on disk and where mysql.sock is stored.
Stop MYSQL
Edit my.cnf and increase:
innodb_buffer_pool_size=100M (May vary per case)
Add:
[mysqld]
innodb_force_recovery = 1
Execute the following
mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.bak
mv /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1.bak
Start MySQL and take backups just in case.
Log in to mysql and: show engines; - Check to see that InnoDB is listed and SUPPORT = YES.
If all is good up until 6, exit and edit my.cnf setting this back:
[mysqld]
innodb_force_recovery = 0
Restart MySQL
Go to your websites, check that all works, and good luck!
PS - You may want to check what caused this, perhaps working on your production server, or restarting caused your log files to get corrupted. You're in the clear for now, so have a look around and make sure all else looks good, especially free disk space and offsite backups.