Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.3(EOL)
-
None
-
Linux
Description
When doing 'CHECKSUM TABLE t' on a partitioned spider table it will fetch all rows from the different data nodes sequentially and store the result on the spider head. On very large tables the mysqld process will be killed due to OOM (without a trace in the error log).
One suggested workaround is to set spider_quick_mode = 3 before running such statement, but we would prefer that the command is sent to each data node and executed in parallel and then aggregate (xor?) the result on the spider head.
This appears to be a specific case of the more general issue that a large result may cause an Out-Of-Memory on the spider head. This should never be the case, and thus we would prefer that spider have an upper limit on how much results it can cache on the spider head, or some other way to avoid a valid query causing a server crash due to out of memory.
Attachments
Issue Links
- causes
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
MDEV-16880 Provide checksum aggregate functions, and partition-level checksums
-
- Open
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 10.3 [ 22126 ] | |
| Assignee | Jacob Mathew [ jacob-mathew ] |
| Attachment | heap_profile.pdf [ 45673 ] |
Checksum per-partition has been requested for Oracle MySQL as well: https://bugs.mysql.com/bug.php?id=78733
Probably the same issue as the more generic queries in MDEV-16520?
Also the server crashes if using spider_quick_mode = 3: MDEV-16521
| Link | This issue relates to MDEV-16880 [ MDEV-16880 ] |
| Link |
This issue relates to |
| Assignee | Jacob Mathew [ jacob-mathew ] | Kentoku [ kentoku ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
Add handler methods for pushing down checksum table with options.
This changes are included small server side changes, please review about this.
60ed52f
| Assignee | Kentoku [ kentoku ] | Michael Widenius [ monty ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
| Priority | Major [ 3 ] | Critical [ 2 ] |
I'd suggest a different approach. Make existing handler::checksum() method to calculate the checksum in the engine, the slow way. Move current implementation from sql_table.cc to handler::checksum().
And to get the fast checksum value from the engine — use handler::info(), not handler::checksum().
| Fix Version/s | 10.4 [ 22408 ] |
> And to get the fast checksum value from the engine — use handler::info(), not handler::checksum().
Currently, hsndler::info() does not return checksum value. Should I add checksum value into ha_statistics class?
Also, I think it requires to move logic from handler::checksum() to handler::info() of all storage engines. Would it possible to I avoid it?
| Assignee | Michael Widenius [ monty ] | Sergei Golubchik [ serg ] |
Yes, that's what I mean, moving checksum to handler::info(), ha_statistics looks like a good place.
Only myisam and aria support live checksum, there are no other engines that are affected, as far as I can see.
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| Status | Stalled [ 10000 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
| Assignee | Sergei Golubchik [ serg ] | Kentoku [ kentoku ] |
serg
I added checksum_null parameter to ha_statistics, because Spider have to set null value if Spider get null from data nodes. Would you please review this again?
a252067
| Assignee | Kentoku [ kentoku ] | Sergei Golubchik [ serg ] |
| Status | Stalled [ 10000 ] | In Review [ 10002 ] |
| Assignee | Sergei Golubchik [ serg ] | Kentoku [ kentoku ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| issue.field.resolutiondate | 2019-06-10 15:26:34.0 | 2019-06-10 15:26:34.834 |
| Fix Version/s | 10.4.6 [ 23412 ] | |
| Fix Version/s | 10.3 [ 22126 ] | |
| Fix Version/s | 10.4 [ 22408 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Link |
This issue causes |
| Workflow | MariaDB v3 [ 87390 ] | MariaDB v4 [ 154405 ] |
| Zendesk Related Tickets | 177946 |
The attached heap_profile.pdf was created by:
export HEAPPROFILE=/tmp/mybin.hprof
export LD_PRELOAD="/usr/lib64/libtcmalloc_and_profiler.so.4"
start mysqld
ran the CHECKSUM TABLE big_table and then generated a pdf by:
sudo pprof --base=/tmp/mybin.hprof.0554.heap --pdf /usr/local/mysql/bin/mysqld /tmp/mybin.hprof.0632.heap > ~/heap_profile.pdf