Perhaps instead, you require a Stored Procedure on your slave that you can run from a cron job mysql -e "call sp_udfs" to do the processing across the tables to alter that data. Events disable by default in a slave You could do a lot of work with that approach. This way you can control its behaviour much better than triggers. Other benefit, you can run any form of replication you wish, row, statement or mixed
wait_timeout
is a screwball one:
"On thread startup, the session wait_timeout value is initialized from the global wait_timeout value or from the global interactive_timeout value, depending on the type of client (as defined by the CLIENT_INTERACTIVE connect option to mysql_real_connect()). See also interactive_timeout. "
max_connections
claims to have an upper bound of 100000, but I would say that even 10000 is unreasonably large. Does it work to put max_connections=1000
in my.cnf
?
You understand that you need to, after changing my.cnf,
- restart mysqld
- disconnect and reconnect to see the change
- use
SHOW GLOBAL
, not SHOW
, which defaults to SHOW SESSION
.
The interaction between GLOBAL
and SESSION
(for both VARIABLES
and STATUS
) varies with the setting. For many, not all things, session is initialized to global when you login. And wait_timeout
is probably the quirkiest.
Warning
If you had 100000 connections each running complex SELECTs
needing, say, 3 tmp tables, then you might need 100000 * 3 * 256M = 76.8TB of RAM to handle the tmp table! ( 256M = min(tmp_table_size, max_heap_table_size) ). This is a strong reason not to set all those things so high.
Best Answer
fiddle