My team is getting this below error message on AWS Cluster Aurora RDS on reader and writer instances:
Waiting for table level lock
Kindly note:
We are NOT USING Lock Tables explicitly anywhere
We are NOT USING MyISAM Tables
We are NOT USING any Kind of MYSQL Dump
.
mysql> show variables like '%innodb_table%';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| innodb_table_locks | ON |
+--------------------+-------+
1 row in set (0.00 sec)
mysql> show variables like '%innodb_autoinc_lock_mode%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| innodb_autoinc_lock_mode | 1 |
+--------------------------+-------+
1 row in set (0.00 sec)
For those who know about this issue - Is there anyway we can replicate the issue on our Testing Node.
Is it normal, that the MySQL global variable gtid_executed changes multiple times in a minute?
These MySQL commands were executed in a time range of 10 seconds:
mysql> show global variables like 'gtid_executed';
+---------------+-------------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------------+
| gtid_executed | d4eeed2f-6cc7-11e9-aa15-fa163e5318c7:1-26918205 |
+---------------+-------------------------------------------------+
1 row in set (0.00 sec)
mysql> show global variables like 'gtid_executed';
+---------------+-------------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------------+
| gtid_executed | d4eeed2f-6cc7-11e9-aa15-fa163e5318c7:1-26918206 |
+---------------+-------------------------------------------------+
1 row in set (0.00 sec)
mysql> show global variables like 'gtid_executed';
+---------------+-------------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------------+
| gtid_executed | d4eeed2f-6cc7-11e9-aa15-fa163e5318c7:1-26918207 |
+---------------+-------------------------------------------------+
1 row in set (0.00 sec)
Every time there is a different value! Is that normal?
It is a single node SaaS MySQL RDS instance in a cloud environment.
Thank you kindly in advance.
If you have activity on the server this is a normal behaviour, as for each new transaction a new GTID value is assigned to it incremented by one.
I want to print query by MySQL's version in .sql file.
When I use MySQL version 5.6, want to print (2 column)
SELECT user, host FROM mysql.user;
or, I use MySQL version 5.7 or 8, want to print (3 column)
SELECT user, host, account_locked FROM mysql.user;
Because MySQL 5.6 version doesn't have account_locked column.
mysql> SELECT * FROM information_schema.GLOBAL_VARIABLES WHERE variable_name = 'version';
+---------------+-----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+---------------+-----------------+
| VERSION | 5.6.22-71.0-log |
+---------------+-----------------+
1 row in set (0.00 sec)
mysql> SHOW VARIABLES LIKE 'version';
+---------------+-----------------+
| Variable_name | Value |
+---------------+-----------------+
| version | 5.6.22-71.0-log |
+---------------+-----------------+
1 row in set (0.00 sec)
mysql> SELECT ##version;
+-----------------+
| ##version |
+-----------------+
| 5.6.22-71.0-log |
+-----------------+
1 row in set (0.00 sec)
In a Stored Procedure, you can do something like
IF (##version < "5.7") THEN
SELECT user, host FROM mysql.user;
ELSE
SELECT user, host, account_locked FROM mysql.user;
ENDIF;
It gets messier if you also need to handle MariaDB, with its "10.x.y". And, if Percona has any differences, you need to dig deeper into the "version".
I've found that session variables have priority over global variables.
Is it possible to apply global variables which is set by "set global" query to opened session so make local one to same with global one?
Or, is there any way to wait all opened session finish their tasks, and make sleeping session to reconnect?
You can reset any session variable back to its global variable equivalent whenever you want, you don't have to reconnect.
e.g.
mysql> SET ##session.foreign_key_checks=0;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT ##global.foreign_key_checks,##session.foreign_key_checks;
+-----------------------------+------------------------------+
| ##global.foreign_key_checks | ##session.foreign_key_checks |
+-----------------------------+------------------------------+
| 1 | 0 |
+-----------------------------+------------------------------+
1 row in set (0.00 sec)
mysql> SET ##session.foreign_key_checks=##global.foreign_key_checks;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT ##global.foreign_key_checks,##session.foreign_key_checks;
+-----------------------------+------------------------------+
| ##global.foreign_key_checks | ##session.foreign_key_checks |
+-----------------------------+------------------------------+
| 1 | 1 |
+-----------------------------+------------------------------+
1 row in set (0.00 sec)
Yes, session variables are prioritized to use over global variables, and there are 2 kinds of global and session variables.
Like "transaction_isolation", one can automatically set global variables to session variables after changing global variables and reconnecting (logging out and logging in) MySQL.
Like "wait_timeout", one cannot automatically set global variables to session variables after changing global variables and reconnecting (logging out and logging in) MySQL.
For example about "transaction_isolation", REPEATABLE-READ is the default value for "transaction_isolation" global and session variables as shown below:
mysql> SELECT ##global.transaction_isolation, ##session.transaction_isolation;
+--------------------------------+---------------------------------+
| ##global.transaction_isolation | ##session.transaction_isolation |
+--------------------------------+---------------------------------+
| REPEATABLE-READ | REPEATABLE-READ |
+--------------------------------+---------------------------------+
Then, we set READ-UNCOMMITTED to "transaction_isolation" global variable as shown below:
mysql> SET GLOBAL transaction_isolation = 'READ-UNCOMMITTED';
Then, READ-UNCOMMITTED is only set to "transaction_isolation" global variable as shown below:
mysql> SELECT ##global.transaction_isolation, ##session.transaction_isolation;
+--------------------------------+---------------------------------+
| ##global.transaction_isolation | ##session.transaction_isolation |
+--------------------------------+---------------------------------+
| READ-UNCOMMITTED | REPEATABLE-READ |
+--------------------------------+---------------------------------+
Then, log out MySQL:
mysql> exit
Then, log in MySQL:
C:\Users\kai>mysql -u root -p
Now, READ-UNCOMMITTED is also set to "transaction_isolation" session variable as shown below:
mysql> SELECT ##global.transaction_isolation, ##session.transaction_isolation;
+--------------------------------+---------------------------------+
| ##global.transaction_isolation | ##session.transaction_isolation |
+--------------------------------+---------------------------------+
| READ-UNCOMMITTED | READ-UNCOMMITTED |
+--------------------------------+---------------------------------+
And for example about "wait_timeout", 28800 is the default value for "wait_timeout" global and session variables as shown below:
mysql> SELECT ##global.wait_timeout, ##session.wait_timeout;
+-----------------------+------------------------+
| ##global.wait_timeout | ##session.wait_timeout |
+-----------------------+------------------------+
| 28800 | 28800 |
+-----------------------+------------------------+
Then, we set 1000 to "wait_timeout" global variable as shown below:
mysql> SET GLOBAL wait_timeout = 1000;
Then, 1000 is only set to "wait_timeout" global variable as shown below:
mysql> SELECT ##global.wait_timeout , ##session.wait_timeout;
+-----------------------+------------------------+
| ##global.wait_timeout | ##session.wait_timeout |
+-----------------------+------------------------+
| 1000 | 28800 |
+-----------------------+------------------------+
Then, log out MySQL:
mysql> exit
Then, log in MySQL:
C:\Users\kai>mysql -u root -p
Now, 1000 is not set to "wait_timeout " session variable as shown below:
mysql> SELECT ##global.wait_timeout , ##session.wait_timeout;
+-----------------------+------------------------+
| ##global.wait_timeout | ##session.wait_timeout |
+-----------------------+------------------------+
| 1000 | 28800 |
+-----------------------+------------------------+
So in this case, just set 1000 to "wait_timeout " session variable as shown below;
mysql> SET SESSION wait_timeout = 1000;
Or, set DEFAULT which is 1000 of "wait_timeout" global variable to "wait_timeout" session variable as shown below:
mysql> SET SESSION wait_timeout = DEFAULT;
Now, 1000 is also set to "wait_timeout" session variable as shown below:
mysql> SELECT ##global.wait_timeout, ##session.wait_timeout;
+-----------------------+------------------------+
| ##global.wait_timeout | ##session.wait_timeout |
+-----------------------+------------------------+
| 1000 | 1000 |
+-----------------------+------------------------+
I have done a GTID replication in MySQL 5.7.18, I have setup the fail over both master and slave health is good. When I am trying to down master I am getting this error.
Failover starting in 'auto' mode...
2017-05-29 14:53:56 PM CRITICAL The server IP :3306 does not comply to the latest GTID feature support. Errors:
Missing gtid_executed system variable.
So I googled, they were telling to check global variable and variable which I don't understand. This is my master status of gtid_exe
mysql> show variables like '%**gtid_exe%'**;
+----------------------------------+-------+
| Variable_name | Value |
+----------------------------------+-------+
| gtid_executed_compression_period | 1000 |
+----------------------------------+-------+
1 row in set (0.00 sec)
mysql> show global variables like '%**gtid_exe%**';
+----------------------------------+-------------------------------------------------+
| Variable_name | Value |
+----------------------------------+-------------------------------------------------+
| **gtid_executed** | c6b90b56-4084-11e7-8af7-00163e4da2ba:1-26006378 |
| gtid_executed_compression_period | 1000 |
+----------------------------------+-------------------------------------------------+
2 rows in set (0.01 sec)