MySQL 分区表的binlog记录信息

MySQL的表分区是指根据一定规则，将数据库中的一张表分解成多个更小的，容易管理的部分。从逻辑上看，只有一张表，但是底层却是由多个物理分区组成。在MySQL内部实现中，分区表中的每个分区都有一个数字形式的标识符partition_id。它还有一个与之关联的文本形式partition_name。当分区表数据更改时，binlog中分区表的partition_id信息。

binlog记录信息

1）分区表插入数据

mysql> CREATE TABLE trb1 (id INT, name VARCHAR(50), purchased DATE)
PARTITION BY RANGE(id)
(
PARTITION p0 VALUES LESS THAN (3),
PARTITION p1 VALUES LESS THAN (7),
PARTITION p2 VALUES LESS THAN (9),
PARTITION p3 VALUES LESS THAN (11)
);
mysql> INSERT INTO trb1 VALUES (1, 'desk organiser', '2003-10-15'),(2, 'CD player', '1993-11-05'),
(3, 'TV set', '1996-03-10'),(4, 'bookcase', '1982-01-10'), (5, 'exercise bike', '2004-05-09'),
(6, 'sofa', '1987-06-05'),(7, 'popcorn maker', '2001-11-22'),(8, 'aquarium', '1992-08-04'),
(9, 'study desk', '1984-09-16'),(10, 'lava lamp', '1998-12-25');


解析binlog内容，多出partitioning: partition信息。

### Extra row info for partitioning: partition: 0
### INSERT INTO `book`.`trb1`
### SET
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
### @2='desk organiser' /* VARSTRING(200) meta=200 nullable=1 is_null=0 */
### @3='2003:10:15' /* DATE meta=0 nullable=1 is_null=0 */
### INSERT INTO `book`.`trb1`
### SET
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### @2='CD player' /* VARSTRING(200) meta=200 nullable=1 is_null=0 */
### @3='1993:11:05' /* DATE meta=0 nullable=1 is_null=0 */
### Extra row info for partitioning: partition: 1
### INSERT INTO `book`.`trb1`
### SET
### @1=3 /* INT meta=0 nullable=1 is_null=0 */
### @2='TV set' /* VARSTRING(200) meta=200 nullable=1 is_null=0 */
### @3='1996:03:10' /* DATE meta=0 nullable=1 is_null=0 */


2）分区表更新操作

mysql>UPDATE trb1 SET name='badminton' WHERE id=4;
UPDATE trb1 SET name='Music' WHERE id=5;
UPDATE trb1 SET name='song' WHERE id=6;
UPDATE trb1 SET name='soccer' WHERE id=9;
UPDATE trb1 SET name='volleyball' WHERE id=10;


分析binlog内容，会多出source_partition和target_partition信息

### Extra row info for partitioning: source_partition: 1 target_partition: 1
### UPDATE `demo`.`trb1`
### WHERE
### @1=4 /* INT meta=0 nullable=1 is_null=0 */
### @2='bookcase' /* VARSTRING(200) meta=200 nullable=1 is_null=0 */
### @3='1982:01:10' /* DATE meta=0 nullable=1 is_null=0 */
### SET
### @1=4 /* INT meta=0 nullable=1 is_null=0 */
### @2='badminton' /* VARSTRING(200) meta=200 nullable=1 is_null=0 */
### @3='1982:01:10' /* DATE meta=0 nullable=1 is_null=0 */


partition_id

在源码libbinlogevents\include\rows_event.h事件处理代码介绍：
从说明上来看，source_partition_id仅在Update_event的情况下使用。以记录源分区的partition_id。partition_id是通过byte计算得到的。

source_partition_id is used only in the case of Update_event
to log the partition_id of the source partition.
+-----------+--------------+---------------------+
| type_code | partition_info |
+-----------+--------------+---------------------+
| PART | partition_id | source_partition_id |
| (1 byte) | 2 byte | 2 byte |
+-----------+--------------+---------------------+
986: int get_source_partition_id() const { return m_source_partition_id; }
987: void set_source_partition_id(int source_partition_id) {
988: BAPI_ASSERT(source_partition_id tree
.
├── trb1#p#p0.ibd
├── trb1#p#p1.ibd
├── trb1#p#p2.ibd
└── trb1#p#p3.ibd
shell > ibd2sdi trb1#p#p0.ibd
"partitions": [
{
"name": "p0",
"parent_partition_id": 18446744073709551615,
"number": 0,
"se_private_id": 7019
},
{
"name": "p1",
"parent_partition_id": 18446744073709551615,
"number": 1,
"se_private_id": 7020,
},
{
"name": "p2",
"parent_partition_id": 18446744073709551615,
"number": 2,
"se_private_id": 7021,
},
{
"name": "p3",
"parent_partition_id": 18446744073709551615,
"number": 3,
"se_private_id": 7022,
}
]


通过解析分区表文件，number和parent_partition_id和对于trb1表对应的partion_id如下:

分区表名	分区表ID
p0	0
p1	1
p2	2
p3	3

在复制环节中，虽然binlog记录的target_partition跟从节点的partition编号不一样。但分发过去的binlog能正常回放。在复制回放中，可以从而以更优化的方式处理分区的更改。例如，可以构建一些并行化方案来处理不同分区上的数据，从而有效地加快数据回放。如果一个Row事件修改了跨越’N’个分区的数据，那么这个特定的Row事件将被分割成’N’行事件，并依次作为’N’行事件记录到binlog中。之前偶遇一次，在MySQL5.7版本中，出现过target_partition不一致复制失败的情况。

总结

MySQL复制是基于binlog逻辑回放。对于分区表复制方面有很多优化的空间。