This is a very interesting question. I would say cheat and use a different replication product (Tungsten Replicator) that automatically sets a session variable as follows whenever it logs in to apply changes to the slave:

set @rep_status=’slave’;

On a non-slave connection this value will be null, whereas the slave connection will have the preceding value. I just added a JIRA to get this added to Tungsten Replicator and will try to get it into our beta-3 build, which is due for later in the month of December. (JIRA reference: https://forge.continuent.org/jira/browse/TREP-130)

Cheers, Robert

Thanks. I tried that too. The results were very strange. It was returning “” for replication events until I did an update to this table besides replication. In this case it changed to the user which did update even for thread which did updates. But yes this is exactly what I’d expect to work:)

Regards
Shlomi

Peter – great challange!

Shlomi
————-

DROP TABLE IF EXISTS uuid_test;
DROP TABLE IF EXISTS replication_status;
CREATE TABLE uuid_test (uuid VARCHAR(12) NOT NULL);
CREATE TABLE replication_status (whoami VARCHAR(12) NOT NULL);

DELIMITER $$

DROP PROCEDURE IF EXISTS `test`.`deduce_whoami` $$
CREATE PROCEDURE `test`.`deduce_whoami` ()
BEGIN
TRUNCATE TABLE uuid_test;
TRUNCATE TABLE replication_status;
SELECT UUID() INTO @current_uuid;
INSERT INTO uuid_test SELECT SUBSTRING_INDEX(UUID(),’-',-1) FROM DUAL;
INSERT INTO uuid_test VALUES(SUBSTRING_INDEX(@current_uuid,’-',-1)) ;

INSERT INTO replication_status SELECT
CASE COUNT(DISTINCT(uuid))
WHEN ‘1′ THEN ‘master’
WHEN ‘2′ THEN ’slave’
END
FROM uuid_test;
END $$

DELIMITER ;

call deduce_whoami();

True you can do the join to the processlist table in 5.1 or 5.0-percona though this is a bit overkill to do for single row update statements I think

I showed example with broken CURRENT_USER() USER() works just “strange” on 5.0.67 – it will show “empty” for a while for replication thread but as soon as I insert any row directly it switches for root@localhost (the guy who did insert.

This is what I tried (in 5.0) however it does not seems to work well with triggers:

CREATE TRIGGER topic_update After UPDATE ON topic
FOR Each Row INSERT INTO topic_log (ts, connection_id, usr, operation,pk)
VALUES (NOW(), CONNECTION_ID(), CURRENT_USER(), ‘UPDATE’, OLD.id);

mysql> select * from topic_log;
+———————+—————+—————-+———–+———+
| ts | connection_id | usr | operation | pk |
+———————+—————+—————-+———–+———+
| 2008-11-27 13:17:41 | 253944746 | root@localhost | UPDATE | 4160633 |
| 2008-11-27 13:17:41 | 253944746 | root@localhost | UPDATE | 5394938 |
| 2008-11-27 13:17:41 | 253944746 | root@localhost | UPDATE | 4628914 |
| 2008-11-27 13:17:41 | 253944746 | root@localhost | UPDATE | 5399979 |
| 2008-11-27 13:17:41 | 253944746 | root@localhost | UPDATE | 4136666 |
| 2008-11-27 13:17:41 | 253944746 | root@localhost | UPDATE | 4749235 |

So it shows root@localhost rather than system user which was used in this case.

Another way would be to rowcount `SHOW PROCESSLIST` or `information_schema`.`PROCESSLIST`
WHERE Id=CONNECTION_ID() AND User=”system user”