淘宝内部分享:怎么跳出MySQL的10个大坑

2015-1-19 11:00| 发布者: joejoe0332| 查看: 7465| 评论: 0|原作者: 淘宝丁奇|来自: CSDN

摘要: 淘宝自从2010开始规模使用MySQL，替换了之前商品、交易、用户等原基于IOE方案的核心数据库，目前已部署数千台规模。本文涉及以下几个方向：单机，提升单机数据库的性能；集群，提供扩展可靠性；IO存储体系等。 ...

MySQL · 优化改进· 复制性能改进过程

前言

与oracle 不同，MySQL 的主库与备库的同步是通过 binlog 实现的，而redo日志只做为MySQL 实例的crash recovery使用。MySQL在4.x 的时候放弃redo 的同步策略而引入 binlog的同步，一个重要原因是为了兼容其它非事务存储引擎，否则主备同步是没有办法进行的。

redo 日志同步属于物理同步方法，简单直接，将修改的物理部分传送到备库执行，主备共用一致的 LSN，只要保证 LSN 相同即可，同一时刻，只能主库或备库一方接受写请求； binlog的同步方法属于逻辑复制，分为statement 或 row 模式，其中statement记录的是SQL语句，Row 模式记录的是修改之前的记录与修改之后的记录，即前镜像与后镜像；备库通过binlog dump 协议拉取binlog,然后在备库执行。如果拉取的binlog是SQL语句，备库会走和主库相同的逻辑，如果是row 格式，则会调用存储引擎来执行相应的修改。

本文简单说明5.5到5.7的主备复制性能改进过程。

replication improvement (from 5.5 to 5.7)

(1) 5.5 中，binlog的同步是由两个线程执行的

io_thread: 根据binlog dump协议从主库拉取binlog, 并将binlog转存到本地的relaylog；

sql_thread: 读取relaylog，根据位点的先后顺序执行binlog event，进而将主库的修改同步到备库，达到主备一致的效果；由于在主库的更新是由多个客户端执行的，所以当压力达到一定的程度时，备库单线程执行主库的binlog跟不上主库执行的速度，进而会产生延迟造成备库不可用，这也是分库的原因之一，其SQL线程的执行堆栈如下：

sql_thread:
exec_relay_log_event
    apply_event_and_update_pos
         apply_event
             rows_log_event::apply_event
                 storage_engine operation
         update_pos

(2) 5.6 中，引入了多线程模式，在多线程模式下，其线程结构如下

io_thread: 同5.5

Coordinator_thread: 负责读取 relay log，将读取的binlog event以事务为单位分发到各个 worker thread 进行执行，并在必要时执行binlog event（Description_format_log_event， Rotate_log_event 等）。

worker_thread: 执行分配到的binlog event，各个线程之间互不影响；

多线程原理

sql_thread 的分发原理是依据当前事务所操作的数据库名称来进行分发，如果事务是跨数据库行为的，则需要等待已分配的该数据库的事务全部执行完毕，才会继续分发，其分配行为的伪码可以简单的描述如下：

get_slave_worker
  if (contains_partition_info(log_event))
     db_name= get_db_name(log_event);
     entry {db_name, worker_thread, usage} = map_db_to_worker(db_name);
     while (entry->usage > 0)
        wait();
    return worker;
  else if (last_assigned_worker)
    return last_assigned_worker;
  else
    push into buffer_array and deliver them until come across a event that have partition info

需要注意的细节

内存的分配与释放。relay thread 每读取一个log_event, 则需要 malloc 一定的内存，在work线程执行完后，则需要free掉；
数据库名与 worker 线程的绑定信息在一个hash表中进行维护，hash表以entry为单位，entry中记录当前entry所代表的数据库名，有多少个事务相关的已被分发，执行这些事务的worker thread等信息；
维护一个绑定信息的array , 在分发事务的时候，更新绑定信息，增加相应 entry->usage, 在执行完一个事务的时候，则需要减少相应的entry->usage；
slave worker 信息的维护，即每个 worker thread执行了哪些事务，执行到的位点是在哪，延迟是如何计算的，如果执行出错，mts_recovery_group 又是如何恢复的；
分配线程是以数据库名进行分发的，当一个实例中只有一个数据库的时候，不会对性能有提高，相反，由于增加额外的操作，性能还会有一点回退；
临时表的处理，临时表是和entry绑定在一起的，在执行的时候将entry的临时表挂在执行线程thd下面，但没有固化，如果在临时表操作期间，备库crash，则重启后备库会有错误；

总体上说，5.6 的并行复制打破了5.5 单线程的复制的行为，只是在单库下用处不大，并且5.6的并行复制的改动引入了一些重量级的bug

MySQL slave sql thread memory leak (http://bugs.MySQL.com/bug.php?id=71197)
Relay log without xid_log_event may case parallel replication hang (http://bugs.MySQL.com/bug.php?id=72794)
Transaction lost when relay_log_info_repository=FILE and crashed (http://bugs.MySQL.com/bug.php?id=73482)

(3) 5.7中，并行复制的实现添加了另外一种并行的方式，即主库在 ordered_commit中的第二阶段的时候，将同一批commit的 binlog 打上一个相同的seqno标签，同一时间戳的事务在备库是可以同时执行的，因此大大简化了并行复制的逻辑，并打破了相同 DB 不能并行执行的限制。备库在执行时，具有同一seqno的事务在备库可以并行的执行，互不干扰，也不需要绑定信息，后一批seqno的事务需要等待前一批相同seqno的事务执行完后才可以执行。

详细实现可参考： http://bazaar.launchpad.net/~MySQL/MySQL-server/5.7/revision/6256 。

reference： http://geek.rohitkalhans.com/2013/09/enhancedMTS-deepdive.html

MySQL · 谈古论今· key分区算法演变分析

本文说明一个物理升级导致的 "数据丢失"。

现象

在MySQL 5.1下新建key分表，可以正确查询数据。

drop table t1;

create table t1 (c1 int , c2 int) 
PARTITION BY KEY (c2) partitions 5; 
insert into t1  values(1,1785089517),(2,null); 
MySQL> select * from t1 where c2=1785089517;
+------+------------+
| c1   | c2         |
+------+------------+
|    1 | 1785089517 |
+------+------------+
1 row in set (0.00 sec)
MySQL> select * from t1 where c2 is null;
+------+------+
| c1   | c2   |
+------+------+
|    2 | NULL |
+------+------+
1 row in set (0.00 sec)

而直接用MySQL5.5或MySQL5.6启动上面的5.1实例，发现(1,1785089517)这行数据不能正确查询出来。

alter table t1 PARTITION BY KEY ALGORITHM = 1 (c2)  partitions 5;
MySQL> select * from t1 where c2 is null;
+------+------+
| c1   | c2   |
+------+------+
|    2 | NULL |
+------+------+
1 row in set (0.00 sec)
MySQL> select * from t1 where c2=1785089517;
Empty set (0.00 sec)

原因分析

跟踪代码发现，5.1 与5.5,5.6 key hash算法是有区别的。

5.1 对于非空值的处理算法如下

void my_hash_sort_bin(const CHARSET_INFO *cs __attribute__((unused)),
                     const uchar *key, size_t len,ulong *nr1, ulong *nr2)
{
  const uchar *pos = key; 
                         
  key+= len;
 
  for (; pos < (uchar*) key&nbsp;; pos++)
  {
    nr1[0]^=(ulong) ((((uint) nr1[0] & 63)+nr2[0]) * 
             ((uint)*pos)) + (nr1[0] << 8);
    nr2[0]+=3;
  }
}

通过此算法算出数据(1,1785089517)在第3个分区

5.5和5.6非空值的处理算法如下

void my_hash_sort_simple(const CHARSET_INFO *cs,
                         const uchar *key, size_t len,
                         ulong *nr1, ulong *nr2)
{
  register uchar *sort_order=cs->sort_order;
  const uchar *end;
 
  /* 
    Remove end space. We have to do this to be able to compare
    'A ' and 'A' as identical
  */        
  end= skip_trailing_space(key, len);
 
  for (; key < (uchar*) end&nbsp;; key++)
  {
    nr1[0]^=(ulong) ((((uint) nr1[0] & 63)+nr2[0]) * 
            ((uint) sort_order[(uint) *key])) + (nr1[0] << 8);
    nr2[0]+=3;
  }
}

通过此算法算出数据(1,1785089517)在第5个分区，因此，5.5,5.6查询不能查询出此行数据。

5.1,5.5,5.6对于空值的算法还是一致的,如下

if (field->is_null())
{
  nr1^= (nr1 << 1) | 1;
  continue;
}

都能正确算出数据(2, null)在第3个分区。因此，空值可以正确查询出来。

那么是什么导致非空值的hash算法走了不同路径呢？在5.1下，计算字段key hash固定字符集就是my_charset_bin，对应的hash 函数就是前面的my_hash_sort_simple。而在5.5，5.6下，计算字段key hash的字符集是随字段变化的，字段c2类型为int对应my_charset_numeric，与之对应的hash函数为my_hash_sort_simple。具体可以参考函数Field::hash

那么问题又来了，5.5后为什么算法会变化呢？原因在于官方关于字符集策略的调整，详见WL#2649 。

兼容处理

前面讲到，由于hash 算法变化，用5.5，5.6启动5.1的实例，导致不能正确查询数据。那么5.1升级5.5,5.6就必须兼容这个问题.MySQL 5.5.31以后，提供了专门的语法 ALTER TABLE ... PARTITION BY ALGORITHM=1 [LINEAR] KEY ... 用于兼容此问题。对于上面的例子，用5.5或5.6启动5.1的实例后执行

MySQL> alter table t1 PARTITION BY KEY ALGORITHM = 1 (c2) partitions 5;
Query OK, 2 rows affected (0.02 sec)
Records: 2  Duplicates: 0  Warnings: 0

MySQL> select * from t1 where c2=1785089517;
+------+------------+
| c1   | c2         |
+------+------------+
|    1 | 1785089517 |
+------+------------+
1 row in set (0.00 sec)

数据可以正确查询出来了。

而实际上5.5,5.6的MySQL_upgrade升级程序已经提供了兼容方法。MySQL_upgrade 执行check table xxx for upgrade 会检查key分区表是否用了老的算法。如果使用了老的算法，会返回

MySQL> CHECK TABLE t1  FOR UPGRADE\G
*************************** 1. row ***************************
   Table: test.t1
      Op: check
Msg_type: error
Msg_text: KEY () partitioning changed, please run:
ALTER TABLE `test`.`t1` PARTITION BY KEY /*!50611 ALGORITHM = 1 */ (c2)
PARTITIONS 5
*************************** 2. row ***************************
   Table: test.t1
      Op: check
Msg_type: status
Msg_text: Operation failed
2 rows in set (0.00 sec)

检查到错误信息后会自动执行以下语句进行兼容。

ALTER TABLE `test`.`t1` PARTITION BY KEY /*!50611 ALGORITHM = 1 */ (c2) PARTITIONS 5。

MySQL · 捉虫动态· MySQL client crash一例

背景

客户使用MySQLdump导出一张表，然后使用MySQL -e 'source test.dmp'的过程中client进程crash，爆出内存的segment fault错误，导致无法导入数据。

问题定位

test.dmp文件大概50G左右，查看了一下文件的前几行内容，发现：

 A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database If you don't want to restore GTIDs pass set-gtid-purged=OFF. To make a complete dump, pass...
 -- MySQL dump 10.13  Distrib 5.6.16, for Linux (x86_64)
 --
 -- Host: 127.0.0.1    Database: carpath
 -- ------------------------------------------------------
 -- Server version       5.6.16-log
 /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
 /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;

问题定位到第一行出现了不正常warning的信息，是由于客户使用MySQLdump命令的时候，重定向了stderr。即: