10 months ago
## Issue Description
I'm unable to modify certain MySQL global variables on Railway's MySQL plugin, even though my root
user has full SUPER privileges. The SET GLOBAL commands execute without errors, but the values
remain unchanged.
## Environment
- Railway MySQL Plugin (not custom deployment)
- MySQL version: 8.x
- Machine specs: 4GB RAM, 2 CPU cores
- User: root with SUPER and SYSTEM_VARIABLES_ADMIN privileges
## Affected Parameters
The following parameters cannot be changed:
```sql
-- Attempt to set wait_timeout
SET GLOBAL wait_timeout = 14400; -- Try to set 4 hours
SHOW VARIABLES LIKE 'wait_timeout'; -- Still shows 28800 (8 hours)
-- Attempt to set tmp_table_size
SET GLOBAL tmp_table_size = 134217728; -- Try to set 128MB
SHOW VARIABLES LIKE 'tmp_table_size'; -- Still shows 16777216 (16MB)
-- Attempt to set max_heap_table_size
SET GLOBAL max_heap_table_size = 134217728; -- Try to set 128MB
SHOW VARIABLES LIKE 'max_heap_table_size'; -- Still shows 16777216 (16MB)
-- Attempt to set long_query_time
SET GLOBAL long_query_time = 2; -- Try to set 2 seconds
SHOW VARIABLES LIKE 'long_query_time'; -- Still shows 10 seconds
Working Parameters
These parameters CAN be successfully modified:
SET GLOBAL max_connections = 2000; -- Works ✓
SET GLOBAL innodb_io_capacity = 10000; -- Works ✓
Questions
1. Is this a known limitation of Railway's MySQL plugin?
2. Are these parameters intentionally locked for stability/resource management?
3. Would deploying a custom MySQL container (instead of the plugin) allow full parameter control?
4. If these are hard limits, could you document which parameters are modifiable vs locked?
Thank you for any clarification on Railway's MySQL parameter policies!
Pinned Solution
10 months ago
I'm not very experienced with MySQL, but shouldn't you do:
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';I think this is about scoping, session vs global. PostgreSQL has the same concept. You're changing the global variable, but when you do SHOW 'wait_timeout' , you're looking at your session variable still.
And for something that survives restarts, you probably want SET PERSIST?
See: https://dev.mysql.com/doc/refman/8.4/en/persisted-system-variables.html
3 Replies
10 months ago
Hey there! We've found the following might help you get unblocked faster:
If you find the answer from one of these, please let us know by solving the thread!
10 months ago
I'm not very experienced with MySQL, but shouldn't you do:
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';I think this is about scoping, session vs global. PostgreSQL has the same concept. You're changing the global variable, but when you do SHOW 'wait_timeout' , you're looking at your session variable still.
And for something that survives restarts, you probably want SET PERSIST?
See: https://dev.mysql.com/doc/refman/8.4/en/persisted-system-variables.html
10 months ago
## SOLVED - The issue was SESSION vs GLOBAL variable scoping
Thanks to everyone who helped! The problem has been resolved. Here's what happened for anyone
encountering similar issues:
### 🔍 The Problem
I was using SET GLOBAL to modify parameters but checking with SHOW VARIABLES, which shows
SESSION values by default, not GLOBAL values. This made it appear that the parameters weren't being
changed.
### What I was doing wrong:
```sql
SET GLOBAL wait_timeout = 14400; -- Setting GLOBAL variable
SHOW VARIABLES LIKE 'wait_timeout'; -- But checking SESSION variable (wrong!)
-- Result: Still showed 28800, thought it failed
The correct approach:
SET GLOBAL wait_timeout = 14400; -- Setting GLOBAL variable
SHOW GLOBAL VARIABLES LIKE 'wait_timeout'; -- Check GLOBAL variable (correct!)
-- Result: Shows 14400, success!
📊 Key Learning:
- SHOW VARIABLES = Shows SESSION values (current connection)
- SHOW GLOBAL VARIABLES = Shows GLOBAL values (affects new connections)
- SET GLOBAL changes don't always sync to current session
Verification Script:
-- Check both SESSION and GLOBAL to understand the difference
SELECT 'wait_timeout' as param,
@@global.wait_timeout as global_value,
@@session.wait_timeout as session_value,
CASE WHEN @@global.wait_timeout = @@session.wait_timeout
THEN 'Synced'
ELSE 'Different - new connections will use GLOBAL'
END as status;
✨ Result:
Railway MySQL doesn't actually restrict these parameters! All the following work perfectly:
- max_connections
- wait_timeout
- tmp_table_size
- max_heap_table_size
- long_query_time
- innodb_io_capacity
The confusion was purely due to checking SESSION values instead of GLOBAL values.
Thanks again to @[username] for pointing out the SESSION vs GLOBAL distinction - that was the key
insight that solved everything!
Hope this helps anyone else who encounters similar "parameter won't change" issues. Always remember
to check GLOBAL variables when using SET GLOBAL! 🚀
Status changed to Solved chandrika • 10 months ago