Check Status
1 | mysql> \s |
- Threads: This indicates the total number of currently connected client threads (connections) to the MySQL server
- Questions: This is a cumulative counter representing the total number of queries (statements) that the server has executed since it was last started
- Slow queries: This is a cumulative counter for the number of queries that have taken longer than the long_query_time system variable setting to execute. By default, long_query_time is usually 10 seconds.
- Opens: This is a cumulative counter for the number of files (tables, logs, etc.) that MySQL has opened.
- Flush tables: This is a cumulative counter for the number of times a FLUSH TABLES command (or similar flush operation) has been executed. FLUSH TABLES forces MySQL to close all open tables and reload them from disk. This is often done after making changes to table structures, privileges, or for backup purposes.
- Open tables: This represents the actual number of tables that are currently open in the MySQL table cache. These tables are kept open to avoid the overhead of opening and closing them repeatedly, improving performance.
- Query per second: It’s calculated as Questions / Uptime (where Uptime is the server’s running time in seconds).
Check Service ID
1 | mysql> SHOW VARIABLES LIKE 'server_id'; |
Each server (source and all replicas) in a replication chain must have a
unique server_id
. When a source server writes changes to its binary log, it
includes its server_id
with each event.
Replicas use this ID to:
- Prevent loops: A replica will skip applying events that originated from a server with its own server_id to avoid infinite loops in multi-master or circular replication topologies.
- Identify the source: In more complex replication setups, the server_id helps identify which server generated a particular set of changes
Check Users
1 | mysql> SELECT User, Host FROM mysql.user; |
Or you can use
1 | SELECT USER(); |
These are the most common and direct ways to see the current user.
- USER() returns the username and host that the client attempted to authenticate with.
- CURRENT_USER() returns the username and host that the MySQL server actually authenticated the client connection with. This is the user account that determines your privileges.
They can sometimes be different (e.g., if you tried to connect with a non-existent user, MySQL might connect you as an anonymous user).
Check Active User States
1 | mysql> SELECT Id, User, Host, db, Command, Time, State, Info FROM information_schema.processlist\G |
Show DBs/Schemas
1 | mysql> show databases; |
Drop Schema
1 | DROP SCHEMA animals; |
List Tables
1 | use <db>; |
Describe Table
1 | mysql> describe animals.animals; |
Drop Table
Please check the table dependency first
1 | DROP TABLE animals.animals; |
Create User
For example, create a user for replication purposes, logging in with root(or at least with create user privilege)
1 | CREATE USER 'myuser'@'%' IDENTIFIED BY 'YourSecurePasswordHere'; |
Grant Privileges
Grant privileges to user:
1 | mysql> GRANT EVENT ON animals.* TO 'myuser'@'%'; |
Show Privileges
1 | mysql> SHOW GRANTS FOR 'myuser'@'%'; |
Revoke Privileges
1 | mysql> REVOKE EVENT ON `animals`.* FROM `myuser`@`%`; |
Check Replication
This is important if you launch the replication and how to check the progress or status.
On Source Server
1 | SHOW MASTER STATUS\G |
On Replica
1 | SHOW SLAVE STATUS\G |
Replica_IO_Running (I/O Thread / Receiver Thread)::
This thread is responsible for connecting to the source server and reading the binary log events. Think of it as the “data fetcher.” It streams the changes (SQL statements, row changes, etc.) from the source’s binary logs.
Once received, the I/O thread writes these events to a local file on the replica called the relay log. The relay log acts as a temporary cache of the binary log events from the source.
If a replica is offline for a period, the I/O thread can quickly retrieve all the accumulated binary log events from the source once it reconnects, even if the SQL thread takes longer to process them.
Replica_SQL_Running (SQL Thread / Applier Thread):
This thread is responsible for reading the events from the relay log (written by the I/O thread) and executing them on the replica’s database. Think of it as the “data applier.”
Its goal is to apply the changes to the replica’s data as quickly and efficiently as possible to keep the replica synchronized with the source.
Check Binlog is on
1 | mysql> show variables where variable_name in ('log_bin', 'binlog_format'); |
Inspect Binlog Event
You can do inspection by mysqlbinlog cli, but we can also do it from SQL, reference from CSQL PITR public document.
1 | show binary logs; |
Check GTID is on
1 | mysql> show variables where variable_name in ('gtid_mode','enforce_gtid_consistency'); |
Check MyISAM vs InnoDB
One server can have both MyISAM and InnoDB for different tables.
1 | SELECT count(table_name) as table_count FROM information_schema.tables tab |