I am executing SHOW FULL PROCESSLIST
and from the response I get the "Host" field is empty.
Quoting from the docs here
Host
The host name of the client issuing the statement (except for system
user where there is no host). SHOW PROCESSLIST reports the host name
for TCP/IP connections in host_name:client_port format to make it
easier to determine which client is doing what.
Who is a system user? The root
user?
I have permitted remote access to the root
user.
The same case on my another system where there a root
user with the remote access and executing SHOW FULL PROCESSLIST
shows localhost:<thread-id>
in the host field.
How to know in which case MySQL shows the host
name in SHOW FULL PROCESSLIST`?
Best Answer
The
system user
is the user defined to execute MySQL Replication.There are two DB Connections dedicated to performing MySQL Replication
The
system user
is referred to as a non-client thread in the MySQL Documentation aboutSHOW PROCESSLIST;
As far seeing localhost:#####, that number after the colon is a really a port number within mysqld assigned to localhost.
UPDATE 2012-04-27 18:00 EDT
Questions from your comment
Answers to Questions from your comment
No, you cannot rename the system user. It is dedicated to handle MySQL Replication only. The only way to manipulate properties of of the
system user
would be throught the GRANT command issued to create the replication user.For example, when you setup a replication user, you issue a command like this:
When
START SLAVE
is issued on a Slave, the Master authenticates the DB Thread coming from the Slave and assign one thread on the Master. The thread on the Master will ship binary log entries to the I/O Thread on the Slave. The I/O Thread on the Slave is assigned tosystem user
for handling communcation between Master and Slave. The SQL Thread on the Slave is also assigned tosystem user
for handling intracommunication of local relay log entries to be processed FIFO (Frist In, First Out) by mysqld running on the Slave. No direct access is permitted via the MySQL Client on the Slave except forSTOP SLAVE;
(Kills both I/O Thread and SQL Thread)STOP SLAVE IO_THREAD;
STOP SLAVE SQL_THREAD;
START SLAVE;
(Creates both I/O Thread and SQL Thread)START SLAVE IO_THREAD;
START SLAVE SQL_THREAD;
Of course, you could issue
KILL ####;
where #### is the process ID of either the I/O Thread or SQL Thread. You would be totally respsonsible for reestablishing replication at the risk of losing the correct log file and position if theKILL
command misses any communication because of an unnatural stoppage of a replicaton thread.