mysql> \s -------------- mysql Ver 14.14 Distrib 5.7.33, for Linux (x86_64) using EditLine wrapper
Connection id: 513 Current database: Currentuser: root@localhost SSL: Notin use Current pager: stdout Using outfile: '' Using delimiter: ; Server version: 8.0.16 MySQL Community Server - GPL Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: utf8mb4 Db characterset: utf8mb4 Client characterset: utf8 Conn. characterset: utf8 UNIX socket: /tmp/mysql.sock Uptime: 4 days 21 hours 55 min 37 sec
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).
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
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).
-- with IP range CREATEUSER'myuser'@'192.168.1.0/24' IDENTIFIED BY'YourSecurePasswordHere'; CREATEUSER'myuser'@'192.168.1.%' IDENTIFIED BY'YourSecurePasswordHere';
Grant Privileges
Grant privileges to user:
1 2
mysql>GRANT EVENT ON animals.*TO'myuser'@'%'; mysql> FLUSH PRIVILEGES;
***************************2.row*************************** Id: 2620 User: myuser Host: 35.194.40.52:59948 db: NULL Command: Binlog Dump Time: 615115 State: Source has sent all binlog to replica; waiting for more updates Info: NULL
-- when GTID is ON ***************************1.row*************************** Id: 11437 User: myuser Host: 34.121.192.197:56772 db: NULL Command: Binlog Dump GTID Time: 800846 State: Master has sent all binlog to slave; waiting for more updates Info: NULL
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.
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.
-- if you enabled binlog, the retention is set automatically -- check binlog retention binlog_expire_logs_seconds is for latest version mysql>show variables where variable_name in \ ('binlog_expire_logs_seconds', 'expire_logs_days'); +----------------------------+---------+ | Variable_name |Value| +----------------------------+---------+ | binlog_expire_logs_seconds |2592000| | expire_logs_days |0| +----------------------------+---------+ 2rowsinset (0.00 sec)
One server can have both MyISAM and InnoDB for different tables.
1 2 3 4
SELECTcount(table_name) as table_count FROM information_schema.tables tab WHERE engine !='InnoDB' AND table_type ='BASE TABLE' AND table_schema notin ('information_schema','sys','performance_schema','mysql');