terrymanu commented on issue #35159:
URL:
https://github.com/apache/shardingsphere/issues/35159#issuecomment-3495206047
Based on the analysis of GitHub issue #35159, this is a limitation of the
MySQL replication mechanism, not a bug in ShardingSphere itself.
Root Cause
1. MySQL hostname length limitation: MySQL has a length limit for the
report-host parameter in master-slave replication (typically 60 characters)
2. Kubernetes environment characteristics: Pod names deployed in
Kubernetes are typically very long, such as:
- shardingsphere-proxy-apache-shardingsphere-proxy-charts-58222lk
- shardingsphere-proxy-apache-shardingsphere-proxy-charts-5885fzf
- shardingsphere-proxy-apache-shardingsphere-proxy-charts-58twgsm
Code Flow Analysis
From MySQLBinlogClient.java:195-203, we can see the slave registration
flow:
private void registerSlave() {
responseCallback = new DefaultPromise<>(eventLoopGroup.next());
InetSocketAddress localAddress = (InetSocketAddress)
channel.localAddress();
MySQLComRegisterSlaveCommandPacket packet = new
MySQLComRegisterSlaveCommandPacket(
connectInfo.getServerId(), localAddress.getHostName(), //
hostname obtained here is too long
connectInfo.getUsername(), connectInfo.getPassword(),
localAddress.getPort());
resetSequenceID();
channel.writeAndFlush(packet);
waitExpectedResponse(MySQLOKPacket.class); // "too long 'report-host'"
error thrown here
}
Problem Classification
- This is not a ShardingSphere bug, but an inherent limitation of the
MySQL replication protocol
- The error originates from MySQL server-side validation of the
report-host parameter length
- Maintainer @sandynz has confirmed this is a MySQL limitation with no
other solution for now
Solution
Recommended Approach: Shorten Pod Names
Customize shorter Pod names in your Helm chart configuration:
# values.yaml
fullnameOverride: "ss-proxy"
Or use:
# values.yaml
nameOverride: "ss-proxy"
You can also set a shorter hostname through environment variables:
# values.yaml
env:
- name: MY_HOSTNAME
value: "ss-proxy-0"
If Problem Persists
If the issue still exists after shortening Pod names, please provide the
following information:
1. Complete error logs: More detailed MySQL error information
2. MySQL version information: Result of SELECT VERSION()
3. Helm configuration: Current values.yaml configuration being used
4. Actual Pod hostname: Output of kubectl exec <pod-name> -- hostname
Conclusion
This is a MySQL replication protocol limitation, not a ShardingSphere bug.
Your solution of shortening Pod names is correct and follows ShardingSphere
usage patterns. ShardingSphere acts as a MySQL replication client in
this scenario and cannot bypass MySQL server-side limitations.
Your workaround (shortening Pod names) is currently the best solution
available.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
