Managing data and data archiving using MySQL 5.6 new features of

Transcription

Managing data and data archiving using MySQL 5.6 new features of
Managing data and data archiving
using MySQL 5.6 new features of
Portable Table-space and EXCHANGE
PARTITION
Marco “the Grinch” Tusa
MySQL Conference Santa Clara 2013
About Pythian
• Recognized Leader:
– Global industry-leader in remote database administration services and consulting for Oracle,
Oracle Applications, MySQL and Microsoft SQL Server
– Work with over 250 multinational companies such as Forbes.com, Fox Sports, Nordion and
Western Union to help manage their complex IT deployments
• Expertise:
– Pythian’s data experts are the elite in their field. We have the highest concentration of Oracle
ACEs on staff—9 including 2 ACE Directors—and 2 Microsoft MVPs.
– Pythian holds 7 Specializations under Oracle Platinum Partner program, including Oracle
Exadata, Oracle GoldenGate & Oracle RAC
• Global Reach & Scalability:
– Around the clock global remote support for DBA and consulting, systems administration,
special projects or emergency response
About Me
Marco “The Grinch”
– Former MySQL AB
– 2 kids 1 wife
– History of religions
Ski; Snowboard; scuba
diving; Mountain trekking
Scope
This presentation is to illustrate an operative way to manage the
partition or tables as file, and how to restore them safely and quickly.
Simulate a case where historical data can be needed for future reuse,
using simple file restore bypassing the need of reloading the data.
Getting a better understanding of what you can really do with
DISCARD/IMPORT an EXCHANGE PARTITION.
My Apology …
This
Will be
A long “slide” ride
Scenario
We have:
• MySQL master with information loaded from OLTP system
• MySQL Historical Server with serving reporting information
We need:
• Move Tablespace for a table and import back to a different table
• Move a table from a schema to another.
• Move out data by day from partition to a table not partitioned.
• Import a table to Historical table partitioned.
Different solutions
Portable tablespace is not the only solution
Possible solutions
1. Using data export like mysqldump or Load INTO file
2. Single table backup (xtrabackup)
3. ELTP process
My Motto
Use the right tool for the job… keep that in mind after the
last slide
data dictionary
• Metadata that keeps track of InnoDB-related objects such
as tables, indexes, and table columns.
• Check INFORMATION_SCHEMA
– INNODB_SYS_TABLES
– INNODB_SYS_TABLESPACES
• Check reference manual at chapter 19.30
data dictionary
| INNODB_LOCKS
| INNODB_TRX
| INNODB_SYS_DATAFILES
|
|
|
./.
| INNODB_FT_DEFAULT_STOPWORD
| INNODB_FT_INDEX_TABLE
|
|
| INNODB_LOCK_WAITS
| INNODB_SYS_TABLESTATS
|
|
| INNODB_FT_INDEX_CACHE
| INNODB_SYS_TABLESPACES
|
|
| INNODB_CMP
| INNODB_FT_BEING_DELETED
| INNODB_CMP_RESET
|
|
|
| INNODB_METRICS
| INNODB_SYS_FOREIGN_COLS
| INNODB_FT_CONFIG
|
|
|
| INNODB_CMP_PER_INDEX
| INNODB_CMPMEM_RESET
|
|
| INNODB_BUFFER_POOL_STATS
| INNODB_SYS_COLUMNS
|
|
| INNODB_FT_DELETED
| INNODB_BUFFER_PAGE_LRU
| INNODB_FT_INSERTED
|
|
|
| INNODB_SYS_FOREIGN
|
+---------------------------------------+
| INNODB_CMPMEM
| INNODB_SYS_INDEXES
|
|
| INNODB_SYS_TABLES
| INNODB_SYS_FIELDS
| INNODB_CMP_PER_INDEX_RESET
|
|
|
| INNODB_BUFFER_PAGE
./.
|
data dictionary (digging)
(root@localhost) [information_schema]>select * from INNODB_SYS_TABLES limit 3;
+----------+----------------------------+------+--------+-------+-------------+------------+---------------+
| TABLE_ID | NAME
| FLAG | N_COLS | SPACE | FILE_FORMAT | ROW_FORMAT | ZIP_PAGE_SIZE |
+----------+----------------------------+------+--------+-------+-------------+------------+---------------+
|
14 | SYS_DATAFILES
|
0 |
5 |
0 | Antelope
| Redundant |
0 |
|
11 | SYS_FOREIGN
|
0 |
7 |
0 | Antelope
| Redundant |
0 |
|
12 | SYS_FOREIGN_COLS
|
0 |
7 |
0 | Antelope
| Redundant |
0 |
|
24 | test/tbtest1#P#p001
|
1 |
12 |
10 | Antelope
| Compact
|
0 |
+----------+----------------------------+------+--------+-------+-------------+------------+---------------+
TABLE_ID = Table identifier
NAME = Table Name
FLAG = If is it is a System Table [0] or User table [1]
N_COLS = Self explanatory, Number of columns
SPACE = This is the ID of the TABLESPACE
data dictionary (digging 2)
(root@localhost) [information_schema]>select * from INNODB_SYS_TABLESPACES where space=0 or space=10
limit 3;
+-------+---------------------+------+-------------+----------------------+-----------+---------------+
| SPACE | NAME
| FLAG | FILE_FORMAT | ROW_FORMAT
| PAGE_SIZE | ZIP_PAGE_SIZE |
+-------+---------------------+------+-------------+----------------------+-----------+---------------+
|
10 | test/tbtest1#P#p001 |
0 | Antelope
| Compact or Redundant |
16384 |
0 |
+-------+---------------------+------+-------------+----------------------+-----------+---------------+
SPACE = TABLESPACE id, this is the one!
NAME = Table Name
FLAG = If is it is a System Table [0] or User table [1]
data dictionary (digging 3)
+----------------+---------+----------+-------+-----------+---------------------+
| PARTITION_NAME | Data MB | Index MB | SPACE | PAGE_SIZE | Tablespace
|
+----------------+---------+----------+-------+-----------+---------------------+
| p001
|
0.01 |
0.03 |
10 |
16384 | test/tbtest1#P#p001 |
| p002
| 156.71 |
43.20 |
11 |
16384 | test/tbtest1#P#p002 |
+----------------+---------+----------+-------+-----------+---------------------+
SELECT PARTITION_NAME,TRUNCATE((DATA_LENGTH/1024)/1024,2) as 'Data MB',TRUNCATE
((INDEX_LENGTH/1024)/1024,2) as 'Index MB', SPACE,PAGE_SIZE, CONCAT
(TABLE_SCHEMA,'/',TABLE_NAME,'#P#',PARTITION_NAME) as Tablespace from Partitions join
INNODB_SYS_TABLESPACES on NAME=CONCAT
(TABLE_SCHEMA,'/',TABLE_NAME,'#P#',PARTITION_NAME) where TABLE_NAME='tbtest1' limit 2;
DISCARD & IMPORT
• File per TABLE active (innodb_file_per_table = 1)
• Table must be FLUSH and locked for READS
• Online DDL can be done while TABLESPACE is discard
as for Chapter 5.5.1. “Overview of Online DDL” (not on
the discarded table)
• Partitions CANNOT be removed directly.
DISCARD & IMPORT
REMEMBER
Importing Tablespaces
Cost time… and more.
Exchange Partition what for?
Available from MySQL 5.6 over
Convert a (sub)Partition to a stand alone Table.
Convert a Table without partition to a Partition.
Exchange Partition limitations
• Table MUST have same structure.
• If partition has sub partition cannot be move
• Table exchange with a partition MUST respect partition
data condition.
• Table and Partition MUST have same Storage Engine.
Work Environment
System | Dell Inc.; PowerEdge T710;
Platform | Linux
Release | CentOS release 6.3 (Final)
Kernel | 2.6.32-279.1.1.el6.x86_64
Processors | physical = 2, cores = 8, virtual = 16,
hyperthreading = yes
Speeds | 16x2394.080
Models | 16xIntel(R) Xeon(R) CPU E5620 @ 2.40GH
/dev/sda1
Part
1
64
518192640
/dev/sda2
Part
64
243069
1998784166400
RAID10
Hands on
1/
First work is to DETACH a Table and IMPORT it to
a different table in a different Server.
Hands on
Steps Assuming we already have the table in place:
1. 2. 3. 4. 5. 2/
Take the table creation to replicate the structure SHOW CREATE TABLE test.tbtest_child1\G
Lock the table to copy it FLUSH TABLE test.tbtest_child1 WITH READ LOCK;
Copy to the other server the files DON'T forget the .cnf to a backup directory.
UNLOCK TABLES;
Create a fake table using the create statement stored before
6. Detach the table ALTER TABLE test.tbtest_child1 DISCARD TABLESPACE;
7. MOVE !!! the *.ibd file in a safe place
8. Copy over the previous files from the backup directory
9. CHECK PERMISSION!!
10. Import back the table space ALTER TABLE test.tbtest_child1 IMPORT TABLESPACE;
11. Analyze / check table;
DISCARD & IMPORT (commands)
• FLUSH TABLES test.tbtest_child1 WITH READ LOCK;
(root@mysqlt1) [test]>FLUSH TABLES test.tbtest1 WITH READ LOCK;
Query OK, 0 rows affected (0.02 sec)
• ALTER TABLE test.tbtest_child1 DISCARD
TABLESPACE;
(root@mysqlt1) [test]>ALTER TABLE test.tbtest_child1 DISCARD TABLESPACE;
Query OK, 0 rows affected (0.06 sec)
• ALTER TABLE test.tbtest_child1 IMPORT
TABLESPACE;
(root@mysqlt1) [test]>ALTER TABLE test.tbtest_child1 IMPORT TABLESPACE;
Query OK, 0 rows affected (2.04 sec)
Implementing the steps
Create the table on the target and discard the tablespace
CREATE TABLE `tbtest_child1` (
`a` int(11) NOT NULL,
`bb` int(11) AUTO_INCREMENT NOT NULL,
`partitionid` int(11) NOT NULL DEFAULT '0',
`stroperation` varchar(254) DEFAULT NULL,
`time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`a`,`bb`),
UNIQUE KEY `bb` (`bb`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
(root@mysqlt3) [test]>ALTER TABLE tbtest_child1 DISCARD TABLESPACE;
1/
Implementing the steps
2/
ON TARGET Check the directory, you will only have:
-rw-rw---- 1 mysql mysql 8700 Apr 17 16:56 tbtest_child1.frm
ON SOURCE Check the directory and be sure to have these files :
-rw-r-----. 1 mysql mysql
-rw-rw----. 1 mysql mysql
-rw-r-----. 1 mysql mysql
655 Apr 17 14:51 tbtest_child1.cfg
8700 Apr 15 16:44 tbtest_child1.frm
192937984 Apr 16 17:27 tbtest_child1.ibd
Copy file from SOURCE to TARGET
root@mysqlt1 test]# scp tbtest_child1.* mysql@mysqlt3:/home/mysql/
mysql_instances/instances/mt56master/data/test
Implementing the steps
3/
On Target Import the table space:
(root@mysqlt3) [test]>ALTER TABLE tbtest_child1 IMPORT TABLESPACE;
Query OK, 0 rows affected (2.34 sec)
Check the table as well
(root@mysqlt3) [test]>check table tbtest_child1;
| Table
| Op
| Msg_type | Msg_text |
| test.tbtest_child1 | check | status
| OK
|
Done:
(root@mysqlt3) [test]>select count(*) from tbtest_child1;
| count(*) |
|
358682 |
Checking the ids
On Source (mysqlt1):
>select * from INNODB_SYS_TABLESPACES where NAME like '%tbtest_child1%';
| SPACE | NAME
| FLAG | FILE_FORMAT | ROW_FORMAT
| PAGE_SIZE | ZIP_PAGE_SIZE |
|
8 | test/tbtest_child1 |
0 | Antelope
| Compact or Redundant |
16384 |
0 |
Import same data file to 3 different table
On Target (mysqlt3):
| SPACE | NAME
| FLAG | FILE_FORMAT | ROW_FORMAT
| PAGE_SIZE | ZIP_PAGE_SIZE |
|
6 | test/tbtest_child1 |
0 | Antelope
| Compact or Redundant |
16384 |
0 |
|
9 | test2/tbtest_child1 |
0 | Antelope
| Compact or Redundant |
16384 |
0 |
|
10 | test2/tbtest_child2 |
0 | Antelope
| Compact or Redundant |
16384 |
0 |
Fully portable?
• Move to different Schema
• Move to different table (same structure different name)
• Move to different Server
Possible usage
Implement a daily refresh of a QA environment from
Production Slave script to:
• Lock relevant tables for READ
• Copy tables directly on target or temporary area
• Unlock tables
• Create tables on Target
• Detach dummy tablespace OR the one previously used
• Import table space
What about Locks?
1/
What I will do:
• Choose a table with few GB
• Copy from source mysqlt1 to mysqlt3
• Import table while I have inserts/reads running on different Schema/
tables
What about Locks?
On Source let choose a table more consistent:
marco@mysqlt1) [test]>show table status like 'tbtest3'\G
Name: tbtest3
Engine: InnoDB
Data_length: 14676918272 - 13.6GB
On Target (mysqlt3):
• Running Inserts or Select on a different schema
• ALTER IMPORT require “System Lock”
• Kill the process will put your dataset in danger
2/
Check the error log!
The import has different phases and when it start is better:
InnoDB: Discarding tablespace of table "test"."tbtest3": Data structure corruption
InnoDB: Importing tablespace for table 'test/tbtest3' that was exported from host
'mysqlt1'
InnoDB: Phase I - Update all pages
InnoDB: Sync to disk
InnoDB: Sync to disk - done!
InnoDB: Phase III - Flush changes to disk
InnoDB: Phase IV - Flush complete
InnoDB: "test"."tbtest3" autoinc value set to 41727984
Interrupting the process will corrupt the InnoDB dictionary
NO ACTION RUNNING WHILE IMPORTING
How much it costs?
Cost change in relation to the machine power
• On my own PC :
[test_tablespace1]>ALTER TABLE tbtest_10MB IMPORT TABLESPACE; (3.11 sec)
[test_tablespace1]>ALTER TABLE tbtest_100MB IMPORT TABLESPACE;(10.17 sec)
[test_tablespace1]>ALTER TABLE tbtest_1GB IMPORT TABLESPACE; (8 min 53.98 sec)
• On the server:
[test_tablespace1]>ALTER TABLE tbtest_10MB IMPORT TABLESPACE; (1.01 sec)
[test_tablespace1]>ALTER TABLE tbtest_100MB IMPORT TABLESPACE;(3.20 sec)
[test_tablespace1]>ALTER TABLE tbtest_1GB IMPORT TABLESPACE; (1 min 14.31 sec)
[test_tablespace1]>ALTER TABLE tbtest_15GB IMPORT TABLESPACE; (2 min 30.04 sec)
Check Table on 15GB: 55 min 46.35 sec!
Work with Partitions
Use Exchange Partition:
• The table use for the exchange cannot use partitions
• Data must match the partition condition
• No foreign Key or part of Reference
• Any AUTO_INCREMENT get reset in the Exchange
• Privileges: ALTER; INSERT; CREATE; DROP;
Exchange Partition
1/
How to convert a partition to a Table move the
table to another server.
Then load data and move it back.
2/
Exchange Partition
We will use the Partition p020 space ID 89
+----------------+---------+----------+-------+-----------+---------------------+
| PARTITION_NAME | Data MB | Index MB | SPACE | PAGE_SIZE | Tablespace
|
+----------------+---------+----------+-------+-----------+---------------------+
| p001
<snip>
| p020
<snip>
|
0.01 |
0.03 |
70 |
16384 | test/tbtest2#P#p001 |
|
138.73 |
40.18 |
89 |
16384 | test/tbtest2#P#p020 |
| p060
| 176.73 |
51.26 |
129 |
16384 | test/tbtest2#P#p060
|+----------------+---------+----------+-------+-----------+---------------------+
Exchange Partition
Steps are:
• Create external table to exchange (if not existing)
• ALTER TABLE <name> EXCHANGE PARTITION
<Pname> WITH TABLE <T2name>;
• Detach/import if it is require
• Exchange back
• Load data delta back.
3/
Exchange Partition
4/
Check the rows in the table and in the partition:
(root@mysqlt1) [test]>select count(*) from tbtest2;
| count(*) |
| 20863248 |
1 row in set (41.16 sec)
(root@mysqlt1) [test]>select count(*) from tbtest2 PARTITION(p020);
| count(*) |
|
320819 |
1 row in set (1.61 sec)
Exchange Partition
5/
Create the Exchange table then take the space id
| TABLE_NAME | Data MB | Index MB | SPACE | PAGE_SIZE | Tablespace
| tbExchange |
0.01 |
0.03 |
196 |
16384 | test/tbExchange
Alter the table (Exchange) :
ALTER TABLE tbtest2 EXCHANGE PARTITION p020 WITH TABLE tbExchange;
Query OK, 0 rows affected (0.03 sec)
Tablespace ids are now different:
| TABLE_NAME | Data MB | Index MB |SPACE|PAGE_SIZE| Tablespace
| tbExchange | 138.73 |
40.18 |
89|
16384| test/tbExchange
| p020
|
0.01 |
0.03 | 196|
16384| test/tbtest2#P#p020
Moving Partition back
1/
Data in the tbExchange table can be read, insert and
modify. But must keep Partition definition consistency:
>update tbExchange set partitionid="2013-04-21" where autoInc=41683899;
Query OK, 1 row affected (0.04 sec)
Rows matched: 1 Changed: 1 Warnings: 0
>select autoInc,partitionid from tbExchange order by autoInc DESC limit
4;
| autoInc | partitionid |
| 41683901 | 2013-04-20 |
| 41683899 | 2013-04-21 |-------- I change this
| 41683897 | 2013-04-20
| 41683895 | 2013-04-20
|
|
Moving Partition back
2/
I got an error trying to import it back:
>ALTER TABLE tbtest2 EXCHANGE PARTITION p020 WITH TABLE tbExchange;
ERROR 1737 (HY000): Found a row that does not match the partition
We must correct the value or move it to the correct partition
BEFORE Exchanging.
>update tbExchange set partitionid="2013-04-20" where autoInc=41683899;
>ALTER TABLE tbtest2 EXCHANGE PARTITION p020 WITH TABLE tbExchange;
Query OK, 0 rows affected (0.54 sec) ------- Note the time
Exchange an empty table takes 0.03 sec, time increase
with dimension.
Moving Partition back
3/
While our tbExchange was a single table, data was inserted
in the tbtest2 partition p020:
| count(*) |
|
2424 |
We need to move them back:
>insert into tbtest2 select * from tbExchange;
Query OK, 2424 rows affected (0.42 sec)
Records: 2424 Duplicates: 0 Warnings: 0
>select count(*) from tbtest2 PARTITION(p020);
| count(*) |
|
323244 |
Two point to review
• Exchange cost
– Time
– Locks
• Auto_Increment values
– Main table insert
– Exchange table insert
Exchange cost
• Empty Table
– While inserting on different table (0.11 sec)
– While inserting on the same table (0.36 sec)
• Filled table 208M 324860 Rows
– While inserting on different table (0.60 sec)
– While inserting on the same table (1.11 sec)
• Filled table 4.4GB 8447488 Rows
– While inserting on different table (42.40 sec)
– While inserting on the same table (58.32 sec)
If table larger then Bufferpool go out for dinner!
Locks
• The Table is lock with METADATA lock as
expected
| Id
| db
| Command | Time | State
| Info
| 1322 | test | Query
|
28 | verifying data with partition
| ALTER TABLE tbtest2
EXCHANGE PARTITION p020 WITH TABLE tbExchange2
|
| 1345 | test | Query
|
27 | Waiting for table metadata lock | insert INTO tbtest2
| 1346 | test | Query
|
27 | Waiting for table metadata lock | insert INTO tbtest2
Auto Increment
• We start from an empty table and do Exchange
Name:
Engine:
Rows:
Auto_increment:
tbtest2
InnoDB
21395605
44418048
Name: tbExchange1
Engine: InnoDB
Rows: 0
Auto_increment: 1
Name:
Engine:
Rows:
Auto_increment:
tbtest2
InnoDB
19105637
44418048
Name:
Engine:
Rows:
Auto_increment:
tbExchange1
InnoDB
1858477
44415912
Auto Increment… what happened?
When partition get Exchanged Increment value is reset to
the MAX(AUTO_INCREMENT)
tbtest2 (source table)
tbExchange1(external)
>select max(autoinc) from tbtest2;
+--------------+
| max(autoinc) |
+--------------+
|
44418023 |
+--------------+
>select max(autoinc) from tbExchange1;
+--------------+
| max(autoinc) |
+--------------+
|
44415913 |
+--------------+
Auto Increment… what happened?
If we add records on tbExchange?
tbtest2 (source table)
|
|
|
|
|
|
|
|
|
|
partitionid
2013-04-28
2013-04-28
2013-04-28
2013-04-28
2013-04-28
2013-04-28
2013-04-28
2013-04-25
2013-04-25
|
|
|
|
|
|
|
|
|
|
autoinc
44415915
44415917
44415919
44415921
44415923
44415925
44415927
44415929
44415931
|
|
|
|
|
|
|
|
|
|
tbExchange1(external)
NOT GOOD!
|
|
|
|
|
|
|
|
|
|
partitionid
2013-04-20
2013-04-20
2013-04-20
2013-04-20
2013-04-20
2013-04-20
2013-04-20
2013-04-20
2013-04-20
|
|
|
|
|
|
|
|
|
|
autoinc
44415915
44415917
44415919
44415921
44415923
44415925
44415927
44415929
44415931
|
|
|
|
|
|
|
|
|
|
Auto Increment… what happened?
I had no issue because:
• The PK was compose by autoinc and partitionid
• The number of inserts was lower the table
Auto_increment value.
`autoInc` bigint(11) NOT NULL AUTO_INCREMENT,
`partitionid` DATE NOT NULL,
PRIMARY KEY (`autoInc`,`partitionid`),
Conclusions
Discard / Import :
– It is a very invasive operation (system lock)
– You must know what you are doing (not for beginners)
– Useful to perform refresh (but needs scripting)
Exchange:
– Easy to use and not too invasive (metalock but fast)
– Auto Increment could be an issue (plan your PK)
Q&A
Thank you
To contact us
To contact Me
[email protected]
[email protected]
1-877-PYTHIAN
[email protected]
To follow us
To follow me
http://www.pythian.com/blog
http://www.facebook.com/pages/ThePythian-Group/163902527671
@pythian
http://www.linkedin.com/company/pythian
http://www.tusacentral.net/
https://www.facebook.com/marco.tusa.94
@marcotusa
http://it.linkedin.com/in/marcotusa/

Similar documents