summaryrefslogtreecommitdiff
path: root/sql/partition_element.h
diff options
context:
space:
mode:
authorMattias Jonsson <mattias.jonsson@oracle.com>2013-01-30 17:51:52 +0100
committerMattias Jonsson <mattias.jonsson@oracle.com>2013-01-30 17:51:52 +0100
commitd92a7cb76a6d7c9b53334152abfa8ee93e8fd171 (patch)
treedd3c8ce4f8130d836860c062431eda6346e17965 /sql/partition_element.h
parent16bf552e3eb2cd28306fc84c3406875ece708495 (diff)
parent7aa707f2334097d325738209e1fdbbd52a852e14 (diff)
downloadmariadb-git-d92a7cb76a6d7c9b53334152abfa8ee93e8fd171.tar.gz
Bug#14521864: MYSQL 5.1 TO 5.5 BUGS PARTITIONING
Due to an internal change in the server code in between 5.1 and 5.5 (wl#2649) the hash function used in KEY partitioning changed for numeric and date/time columns (from binary hash calculation to character based hash calculation). Also enum/set changed from latin1 ci based hash calculation to binary hash between 5.1 and 5.5. (bug#11759782). These changes makes KEY [sub]partitioned tables on any of the affected column types incompatible with 5.5 and above, since the calculation of partition id differs. Also since InnoDB asserts that a deleted row was previously read (positioned), the server asserts on delete of a row that is in the wrong partition. The solution for this situation is: 1) The partitioning engine will check that delete/update will go to the partition the row was read from and give an error otherwise, consisting of the rows partitioning fields. This will avoid asserts in InnoDB and also alert the user that there is a misplaced row. A detailed error message will be given, including an entry to the error log consisting of both table name, partition and row content (PK if exists, otherwise all partitioning columns). 2) A new optional syntax for KEY () partitioning in 5.5 is allowed: [SUB]PARTITION BY KEY [ALGORITHM = N] (list_of_cols) Where N = 1 uses the same hashing as 5.1 (Numeric/date/time fields uses binary hashing, ENUM/SET uses charset hashing) N = 2 uses the same hashing as 5.5 (Numeric/date/time fields uses charset hashing, ENUM/SET uses binary hashing). If not set on CREATE/ALTER it will default to 2. This new syntax should probably be ignored by NDB. 3) Since there is a demand for avoiding scanning through the full table, during upgrade the ALTER TABLE t PARTITION BY ... command is considered a no-op (only .frm change) if everything except ALGORITHM is the same and ALGORITHM was not set before, which allows manually upgrading such table by something like: ALTER TABLE t PARTITION BY KEY ALGORITHM = 1 () or ALTER TABLE t PARTITION BY KEY ALGORITHM = 2 () 4) Enhanced partitioning with CHECK/REPAIR to also check for/repair misplaced rows. (Also works for ALTER TABLE t CHECK/REPAIR PARTITION) CHECK FOR UPGRADE: If the .frm version is < 5.5.3 and uses KEY [sub]partitioning and an affected column type then it will fail with an message: KEY () partitioning changed, please run: ALTER TABLE `test`.`t1` PARTITION BY KEY ALGORITHM = 1 (a) PARTITIONS 12 (i.e. current partitioning clause, with the addition of ALGORITHM = 1) CHECK without FOR UPGRADE: if MEDIUM (default) or EXTENDED options are given: Scan all rows and verify that it is in the correct partition. Fail for the first misplaced row. REPAIR: if default or EXTENDED (i.e. not QUICK/USE_FRM): Scan all rows and every misplaced row is moved into its correct partitions. 5) Updated mysqlcheck (called by mysql_upgrade) to handle the new output from CHECK FOR UPGRADE, to run the ALTER statement instead of running REPAIR. This will allow mysql_upgrade (or CHECK TABLE t FOR UPGRADE) to upgrade a KEY [sub]partitioned table that has any affected field type and a .frm version < 5.5.3 to ALGORITHM = 1 without rebuild. Also notice that if the .frm has a version of >= 5.5.3 and ALGORITHM is not set, it is not possible to know if it consists of rows from 5.1 or 5.5! In these cases I suggest that the user does: (optional) LOCK TABLE t WRITE; SHOW CREATE TABLE t; (verify that it has no ALGORITHM = N, and to be safe, I would suggest backing up the .frm file, to be used if one need to change to another ALGORITHM = N, without needing to rebuild/repair) ALTER TABLE t <old partitioning clause, but with ALGORITHM = N>; which should set the ALGORITHM to N (if the table has rows from 5.1 I would suggest N = 1, otherwise N = 2) CHECK TABLE t; (here one could use the backed up .frm instead and change to a new N and run CHECK again and see if it passes) and if there are misplaced rows: REPAIR TABLE t; (optional) UNLOCK TABLES;
Diffstat (limited to 'sql/partition_element.h')
-rw-r--r--sql/partition_element.h7
1 files changed, 3 insertions, 4 deletions
diff --git a/sql/partition_element.h b/sql/partition_element.h
index d6ee44078f5..f4eb282073b 100644
--- a/sql/partition_element.h
+++ b/sql/partition_element.h
@@ -1,7 +1,7 @@
#ifndef PARTITION_ELEMENT_INCLUDED
#define PARTITION_ELEMENT_INCLUDED
-/* Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved.
+/* Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -106,9 +106,8 @@ public:
enum partition_state part_state;
uint16 nodegroup_id;
bool has_null_value;
- /* signed_flag and max_value only relevant for subpartitions */
- bool signed_flag;
- bool max_value;
+ bool signed_flag; // Range value signed
+ bool max_value; // MAXVALUE range
partition_element()
: part_max_rows(0), part_min_rows(0), range_value(0),