terrymanu commented on issue #37264:
URL:
https://github.com/apache/shardingsphere/issues/37264#issuecomment-3605138661
• Understanding
- On 5.5.1/5.5.2 with hash_mod, sharding-count=32, sharding key product_id
(bigint). Full data lands on shards like 3/4/5, but incremental inserts of the
same product_id land on “complement” shards (3→29, 4→28, 5→27). Suspected that
full and incremental use different
sharding algorithms.
Root Cause
- hash_mod calls hashCode() on the Java object of the sharding value, then
abs % sharding-count. The same numeric value yields different hashCode()
results if passed as different Java types (Long / BigInteger / BigDecimal /
String), leading to different routing. In your
example, BigDecimal hashes to 3, but Long/BigInteger hashes to
29—exactly the 3 vs 29 complement—so full vs incremental likely use different
Java types/decoding, not different algorithms.
Analysis
- Possible difference: full migration/initial load decodes bigint as
BigDecimal or string; incremental writes bind Long/BigInteger via JDBC/driver.
- hash_mod relies on type consistency: the same sharding key must be
passed with the same Java type to produce consistent routing.
- Missing info: table DDL, clients and parameter binding types for full vs
incremental, whether any sync/migration pipeline converts types.
Conclusion / Suggestions
1. First, ensure the sharding key type is consistent: on the write side
use setLong (or a single chosen type), and check the full/incremental pipeline
decoding for bigint to avoid mixing BigDecimal/String with Long.
2. If the type is confirmed identical for full and incremental but the
issue persists, please provide: table DDL, sharding rule, a minimal
reproducible SQL with actual parameter types (print the parameter class), and
the routing/SQL Show logs for further diagnosis.
3. hash_mod details:
https://shardingsphere.apache.org/document/current/en/user-manual/common-config/builtin-algorithm/sharding/#hash_mod-sharding-algorithm
--
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]