Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
Description
This was noticed some time ago and I believe is still present. No explicit bug report was made at the time.
If the spider node and data nodes have a different sql_mode setup then this may cause issues.
Example seen was to have sql_mode = STRICT_TRANS_TABLES on data nodes and the spider node and some input data which was accepted on the spider node was rejected by the data node as not being valid. This broke the data load. Other mismatches could also trigger issues.
My expectation would for the spider node to validate the data nodes' sql_mode matches the spider node, or to push out the spider node's current sql_mode setting (or when it changes as we can have session local sql_nodes) to the data nodes on connection or as the value changes.
I think this still applies in spider on 10.3.
Attachments
Issue Links
- is duplicated by
-
MDEV-13383 Spider is not maintaining SQL_MODE across nodes
- Closed
- relates to
-
MDEV-16246 insert timestamp into spider table from mysqldump gets wrong time zone.
- Closed