MySQL 5.7版本新特性连载(一)

本文将和大家一起分享下5.7的新特性,不过我们要先从即将被删除的特性以及建议不再使用的特性说起。根据这些情况,我们在新版本及以后的版本中,应该不再使用,避免未来产生兼容性问题。

本文是基于MySQL-5.7.7-rc版本,未来可能 还会发生更多变化。

1、即将删除的特性
1.1、InnoDB monitoring features,详见:WL#7377(访问地址:http://dev.mysql.com/worklog/task/?id=7377,下面的其他WL,可以自行替换)
【建议】可以动态修改 innodb_status_output、innodb_status_output_locks 两个参数的值打印相关信息,或者直接查看INFORMATION_SCHEMA下的相关表。

1.2、old-password,4.1之前的就密码认证模式已经禁用,old_passwords参数不可用,WL#8006
【建议】尽快升级旧密码串,同时升级MySQL版本,不要告诉我,你还在用4.1甚至更早的版本。

1.3、部分SQL语法不可用
1.3.1、ALTER TABLE … IGNORE。
1.3.2、INSERT DELAY特性,但保留这个语法。WL#6073
1.3.3、ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, NO_ZERO_IN_DATE SQL MODES 等几个SQL MODE合并到STRICT中。不过可能会导致replication失败,所以还在考虑中。WL#7467
1.3.4、不再支持YEAR(2),建议尽快升级成YEAR(4)。WL#6263
【建议】尽可能使用标准SQL语法,不再使用MySQL特有的,或者不是那么严格要求的语法,避免以后版本升级遇到更多麻烦。

1.4、一些参数不可用
1.4.1、不再支持一些指令的简短写法,必须要求写全了,例如mysqldump –compr表示 mysqldump –compress,以后必须将整个参数写完整。WL#6978
1.4.2、删除timed_mutexes。WL#7436
1.4.3、不能再禁用InnoDB引擎,因为系统表也都改成InnoDB了。WL#7976
1.4.4、性能提升有限,删除innodb_use_sys_malloc、innodb_additional_mem_pool_size。WL#7628
1.4.5、意义不大,删除innodb_mirrored_log_groups。WL#6808
1.4.6、已经有新的系统参数代替了,删除innodb_file_io_threads。WL#7149
1.4.7、删除系统参数storage_engine,改用default_storage_engine。WL#7148
1.4.8、删除mysql_upgrade中的–basedir和–datadir系统参数。WL#7010

1.5、一些客户端工具
mysqlaccess、mysql_convert_table_format、mysql_fix_extensions、mysql_find_rows.sh、mysql_setpermission、msql2mysql、mysqlbug、mysql_zap and mysql_waitpid、mysqlhotcopy将不再使用。
【建议】没什么好说的,顺应潮流跟上新版本吧,该放弃的就放弃,不要抱残守缺了,这些工具也基本上都用不上的。

下一期,我们讲讲5.7中不再建议使用的特性, 也就是未来可能会被删除的特性。

 

 

 

MySQL 5.7版本新特性连载(二)

本文将和大家一起分享下5.7的新特性,不过我们要先从即将被删除的特性以及建议不再使用的特性说起。根据这些情况,我们在新版本及以后的版本中,应该不再使用,避免未来产生兼容性问题。

本文是基于MySQL-5.7.7-rc版本,未来可能 还会发生更多变化。

2、预计取消的特性
2.1、客户端交互协议中,EOF协议包不建议再使用了,建议改成OK协议包。WL#7766
2.2、不建议使用SHOW PROFILE指令,或直接从INFORMATION_SCHEMA.PROFILING中查看,建议利用PERFORMANCE_SCHEMA中的几个视图查看。WL#6802
2.2、基于DES算法的加解密函数不建议使用, 取而代之的是用基于AES的加解密函数。WL#8126
2.4、同上,还不建议使用ENCODE()/DECODE()函数。WL#6984
2.5、采用ALTER USER来为用户修改密码,不建议再使用SET PASSWORD修改密码。WL#6409
2.6、和InnoDB相关的4个系统参数innodb_large_prefix、innodb_file_format、innodb_file_format_check、innodb_file_format_max不再建议使用。WL#7703
2.7、不再建议在EXPLAIN后面加上EXTENDED/PARTITIONS关键字。WL#7027
2.8、不再建议使用collation_database、character_set_database系统参数。WL#2.11
2.9、不再建议使用sync_frm系统参数。WL#8216
2.10、不再建议使用@@session.gtid_executed系统变量。WL#7518

 

 

 

MySQL 5.7版本新特性连载(三)

本文是基于MySQL-5.7.7-rc版本,未来可能 还会发生更多变化。本节开始讲5.7版本中的新特性。

1、安全性
a. 用户表 mysql.user 的 plugin字段不允许为空, 默认值是 mysql_native_password,而不是 mysql_old_password,不再支持旧密码格式;
b. 增加密码过期机制,过期后需要修改密码,否则可能会被禁用,或者进入沙箱模式;
c. 使用 mysql_install_db 初始化时,默认会自动生成随机密码,并且不创建除 root@localhost 外的其他账号,也不创建 test 库;

【新特性实践】

执行 mysql_install_db 进行新实例初始化:

[[email protected]]# ./bin/mysql_install_db --user=mysql --datadir=/data/mysql/

2015-06-24 13:55:29 [WARNING] mysql_install_db is deprecated. Please consider switching to mysqld --initialize
2015-06-24 13:55:38 [ERROR]   Child process: /opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/bin/mysqld terminated prematurely with errno= 32
2015-06-24 13:55:38 [ERROR]   Failed to execute /opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/bin/mysqld --bootstrap --datadir=/data/mysql --lc-messages-dir=/usr/share/mysql --lc-messages=en_US
-- server log begin --
mysqld: [Warning] --bootstrap is deprecated. Please consider using --initialize instead
-- server log end --

可以看到提示 mysql_install_db 已经不再推荐使用了,建议改成 mysqld –initialize 完成实例初始化。

改成 mysqld –initialize 后,如果 datadir 指向的目标目录下已经有数据文件,则会有类似提示:

[[email protected]]#./bin/mysqld --user=mysql --basedir=/opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/ --datadir=/data/mysql --initial --initialize-insecure

2015-06-24T06:05:05.533588Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2015-06-24T06:05:05.533627Z 0 [ERROR] Aborting

因此,需要先确保 datadir 目标目录下是空的,避免误操作破坏已有数据。

另外,在初始化时如果加上 –initial-insecure,则会创建空密码的 root@localhost 账号,否则会创建带密码的 root@localhost 账号,密码直接写在 log-error 日志文件中(在5.6版本中是放在 ~/.mysql_secret 文件里,更加隐蔽,不熟悉的话可能会无所适从)

[[email protected]]#./bin/mysqld --user=mysql --basedir=/opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/ --datadir=/data/mysql --initial

2015-06-24T06:14:31.458905Z 0 [Warning] Insecure configuration for --secure-file-priv: Current value does not restrict location of generated files. Consider setting it to a valid, non-empty path.

初始化完毕后,如果没使用新版本的客户端登入,还会报告类似下面的错误:

mysql -uroot -p
Enter password:
ERROR 1862 (HY000): Your password has expired. To log in you must change it using a client that supports expired passwords.

上面的错误提示意思是需要用当前版本的客户端登入,因为新用户登入后需要立刻修改密码,否则无法继续后续的工作:

[([email protected])]>use mysql
ERROR 1820 (HY000): You must SET PASSWORD before executing this statement

[([email protected])]>set password = password('abcd');
Query OK, 0 rows affected, 1 warning (0.00 sec)

修改完密码后,就可以继续使用旧版本的客户端工具了。

 

 

MySQL 5.7版本新特性连载(四)

本文是基于MySQL-5.7.7-rc版本,未来可能 还会发生更多变化。

1、SQL MODE变化
a. 默认启用 STRICT_TRANS_TABLES 模式;
b. 对 ONLY_FULL_GROUP_BY 模式实现了更复杂的特性支持,并且也被默认启用;
c. 其他被默认启用的sql mode还有 NO_ENGINE_SUBSTITUTION;

【iMySQL建议】
对广大MySQL使用者而言,以往不是那么严格的模式还是很方便的,在5.7版本下可能会觉得略为不适,慢慢习惯吧。比如向一个20字符长度的VARCHAR列写入30个字符,在以前会自动截断并给个提示告警,而在5.7版本下,则直接抛出错误了。个人认为这倒是一个好的做法,避免各种奇葩的写法。

【新特性实践】

-- 查看默认的 sql_mode
[[email protected]]> select @@sql_mode;
+-----------------------------------------------------------------------------------+
| @@sql_mode |
+-----------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------+

-- 插入50个字符
[[email protected]]> insert into t_char select 0, repeat('x',50);
ERROR 1406 (22001): Data too long for column 'uname' at row 1

-- 修改本 session 的 sql_mode
[[email protected]]> set sql_mode = 'ONLY_FULL_GROUP_BY,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
Query OK, 0 rows affected (0.00 sec)

-- 去掉 STRICT_TRANS_TABLES 模式后
[[email protected]]> select @@sql_mode;
+---------------------------------------------------------------+
| @@sql_mode |
+---------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------------------------------------------------------+

[[email protected]]> insert into t_char select 0, repeat('x',50);
Query OK, 1 row affected, 1 warning (0.00 sec)  -- 提示有告警信息
Records: 1 Duplicates: 0 Warnings: 1

[[email protected]]> show warnings;
+---------+------+--------------------------------------------+
| Level | Code | Message |
+---------+------+--------------------------------------------+
| Warning | 1265 | Data truncated for column 'uname' at row 1 |
+---------+------+--------------------------------------------+

因为 uname 字段的长度为 40 个字符。

2、优化online操作,例如修改buffer pool、修改索引名(非主键)、修改REPLICATION FILTER、修改MASTER而无需关闭SLAVE线程 等众多特性。

可以在线修改buffer pool对DBA来说实在太方便了,实例运行过程中可以动态调整,避免事先分配不合理的情况,不过 innodb_buffer_pool_instances 不能修改,而且在 innodb_buffer_pool_instances 大于 1 时,也不能将 buffer pool 调整到 1GB 以内,需要稍加注意。

如果是加大buffer pool,其过程大致是:

1、以innodb_buffer_pool_chunk_size为单位,分配新的内存pages;
2、扩展buffer pool的AHI(adaptive hash index)链表,将新分配的pages包含进来;
3、将新分配的pages添加到free list中;

如果是缩减buffer pool,其过程则大致是:

1、重整buffer pool,准备回收pages;
2、以innodb_buffer_pool_chunk_size为单位,释放删除这些pages(这个过程会有一点点耗时);
3、调整AHI链表,使用新的内存地址。

实际测试时,发现在线修改 buffer poo 的代价并不大,SQL命令提交完毕后都是瞬间完成,而后台进程的耗时也并不太久。在一个并发128线程跑tpcc压测的环境中,将 buffer pool 从32G扩展到48G,后台线程耗时 3秒,而从 48G 缩减回 32G 则耗时 18秒,期间压测的事务未发生任何锁等待。

-- 演示1:从 1G 扩大到 16G
[[email protected]]> SET GLOBAL innodb_buffer_pool_size = 51539607552; 
Query OK, 0 rows affected (0.00 sec)

-- 看看日志记录
09:21:19.460543Z 0 [Note] InnoDB: Resizing buffer pool from 1073741824 to 17179869184. (unit=134217728)
09:21:19.468069Z 0 [Note] InnoDB: disabled adaptive hash index.
09:21:20.760724Z 0 [Note] InnoDB: buffer pool 0 : 60 chunks (491511 blocks) were added.
09:21:21.922869Z 0 [Note] InnoDB: buffer pool 1 : 60 chunks (491520 blocks) were added.
09:21:21.935114Z 0 [Note] InnoDB: buffer pool 0 : hash tables were resized.
09:21:21.947264Z 0 [Note] InnoDB: buffer pool 1 : hash tables were resized.
09:21:22.203031Z 0 [Note] InnoDB: Resized hash tables at lock_sys, adaptive hash index, dictionary.
09:21:22.203062Z 0 [Note] InnoDB: Completed to resize buffer pool from 1073741824 to 17179869184.
09:21:22.203075Z 0 [Note] InnoDB: Re-enabled adaptive hash index.

-- 演示2:从 16G 缩减到 1G
[[email protected]]> SET GLOBAL innodb_buffer_pool_size = 1073741824;
Query OK, 0 rows affected (0.00 sec)

-- 看看日志记录
09:22:55.591669Z 0 [Note] InnoDB: Resizing buffer pool from 17179869184 to 1073741824. (unit=134217728)
09:22:55.680836Z 0 [Note] InnoDB: disabled adaptive hash index.
09:22:55.680864Z 0 [Note] InnoDB: buffer pool 0 : start to withdraw the last 491511 blocks.
09:22:55.765778Z 0 [Note] InnoDB: buffer pool 0 : withdrew 489812 blocks from free list. Tried to relocate 1698 pages (491510/491511).
09:22:55.774492Z 0 [Note] InnoDB: buffer pool 0 : withdrew 0 blocks from free list. Tried to relocate 1 pages (491511/491511).
09:22:55.782745Z 0 [Note] InnoDB: buffer pool 0 : withdrawn target 491511 blocks.
09:22:55.782786Z 0 [Note] InnoDB: buffer pool 1 : start to withdraw the last 491520 blocks.
09:22:55.892068Z 0 [Note] InnoDB: buffer pool 1 : withdrew 489350 blocks from free list. Tried to relocate 2166 pages (491517/491520).
09:22:55.900743Z 0 [Note] InnoDB: buffer pool 1 : withdrew 0 blocks from free list. Tried to relocate 2 pages (491519/491520).
09:22:55.908257Z 0 [Note] InnoDB: buffer pool 1 : withdrew 0 blocks from free list. Tried to relocate 0 pages (491519/491520).
09:22:55.915778Z 0 [Note] InnoDB: buffer pool 1 : withdrew 0 blocks from free list. Tried to relocate 1 pages (491520/491520).
09:22:55.923836Z 0 [Note] InnoDB: buffer pool 1 : withdrawn target 491520 blocks.
09:22:56.149172Z 0 [Note] InnoDB: buffer pool 0 : 60 chunks (491511 blocks) were freed.
09:22:56.308997Z 0 [Note] InnoDB: buffer pool 1 : 60 chunks (491520 blocks) were freed.
09:22:56.316258Z 0 [Note] InnoDB: buffer pool 0 : hash tables were resized.
09:22:56.324027Z 0 [Note] InnoDB: buffer pool 1 : hash tables were resized.
09:22:56.393589Z 0 [Note] InnoDB: Resized hash tables at lock_sys, adaptive hash index, dictionary.
09:22:56.393616Z 0 [Note] InnoDB: Completed to resize buffer pool from 17179869184 to 1073741824.
09:22:56.393628Z 0 [Note] InnoDB: Re-enabled adaptive hash index.

 

再来看下在线修改非主键索引名,直接用 ALTER TABLE RENAME INDEX 语法即可。

【新特性实践】

例如下面的SQL语法:

[[email protected]]> ALTER TABLE orders RENAME INDEX idx1 TO idxxx1; 

Query OK, 0 rows affected (0.11 sec)
Records: 0 Duplicates: 0 Warnings: 0

可以看到,几乎瞬间完成,尽管我在执行这个SQL时正跑着64个并发tpcc压测。

 

 

 

MySQL 5.7版本新特性连载(五)

本文是基于MySQL-5.7.7-rc版本,未来可能 还会发生更多变化。

1、支持多源复制(Multi-source replication),这对采用分库分表的同学绝对是个超级重磅福音。可以把多个MASTER的数据归并到一个实例上, 有助于提高SLAVE服务器的利用率。不过如果是同一个表的话,会存在主键和唯一索引冲突的风险,需要提前做好规划。

【新特性实践】
MySQL 5.7的多源复制采用多通道的模式,例如用以下方法可以创建多个复制通道,将多个MASTER上的数据复制到同一个SLAVE节点中去:

-- 需要先把 MASTER_INFO_REPOSITORY 和 RELAY_LOG_INFO_REPOSITORY 改成 TABLE 模式
[[email protected]]> SET GLOBAL MASTER_INFO_REPOSITORY = "TABLE";
Query OK, 0 rows affected (0.00 sec)

[[email protected]]> SET GLOBAL RELAY_LOG_INFO_REPOSITORY = "TABLE";
Query OK, 0 rows affected (0.00 sec)

-- 创建第一个复制通道
[[email protected]]> CHANGE MASTER TO MASTER_HOST='1.2.3.4', MASTER_USER='user', MASTER_PASSWORD='repl' FOR CHANNEL 'MASTER-01';
Query OK, 0 rows affected, 2 warnings (0.00 sec)

-- 创建第二个复制通道
[[email protected]]> CHANGE MASTER TO MASTER_HOST='2.3.4.5', MASTER_USER='user', MASTER_PASSWORD='repl' FOR CHANNEL 'MASTER-02';
Query OK, 0 rows affected, 2 warnings (0.00 sec)

-- 查看第二个复制通道的状态
[[email protected]]> SHOW SLAVE STATUS FOR CHANNEL 'MASTER-02';
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 2.3.4.5
                  Master_User: user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: 
          Read_Master_Log_Pos: 4
               Relay_Log_File: [email protected]
                Relay_Log_Pos: 4
        Relay_Master_Log_File: 
             Slave_IO_Running: No
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 0
              Relay_Log_Space: 154
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 0
                  Master_UUID: 
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: 
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: f0df162a-1a39-11e5-883a-782bcb65f419:1-11025782
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: master-02
1 row in set (0.00 sec)

其他和复制相关的SQL指令和以往也基本一样,只需在加上 FOR CHANNEL ‘CHANNEL-NAME’ 子句即可。

此外,还支持在线修改replication filter规则,不过不是太建议使用filter规则,因此不重点介绍了。执行下面的SQL命令可以完成filter规则修改:

[[email protected]]> CHANGE REPLICATION FILTER
 REPLICATE_DO_DB = (d1), REPLICATE_IGNORE_DB = (d2);

 

2、支持多线程复制(Multi-Threaded Slaves, 简称MTS),在5.6版本中实现了SCHEMA级别的并行复制,不过意义不大,因为我们线上大部分实例的读写压力基本集中在某几个数据表,基本无助于缓解复制延迟问题。倒是MariaDB的多线程并行复制大放异彩,有不少人因为这个特性选择MariaDB(比如我也是其一,呵呵)。

MySQL 5.7 MTS支持两种模式,一种是和5.6一样,另一种则是基于binlog group commit实现的多线程复制,也就是MASTER上同时提交的binlog在SLAVE端也可以同时被apply,实现并行复制。关于MTS的更多详细介绍可以查看姜承尧的分享 MySQL 5.7 并行复制实现原理与调优,我这里就不重复说了。

值得一提的是,经过对比测试,5.7采用新的并行复制后,仍然会存在一定程度的延迟,只不过相比5.6版本减少了86%,相比MariaDB的并行复制延迟也小不少。

 

 

MySQL 5.7版本新特性连载(六)

发表回复

本文是基于MySQL-5.7.7-rc版本,未来可能 还会发生更多变化。

  1. 自动判断底层I/O设备是否可以支持原子IO(AIO),检测到的话,会自动关闭 double write buffer,进一步提升性能。

  2. 支持 innodb_page_cleaners 选项可设置多个page cleaner线程提高脏页刷新效率。

  3. 可通过设置 innodb_undo_log_truncate 等选项自动删除不用的 undo log。

  4. 加强InnoDB read-only模式的性能。

  5. 支持一个表上有多个触发器,这样一来,原先已有触发器表也可以支持用 pt-osc 了。

  6. 新增 log_syslog 选项,可将MySQL日志打印到系统日志文件中。

  7. InnoDB和MyISAM引擎的分区表也支持ICP特性。

  8. 支持对在线某个连接直接查看执行计划,比如 EXPLAIN FOR CONNECTION 1024。

  9. 支持在线(INPLACE)增加 VARCHAR 列的长度。不过 0-255 长度是一个区间,256 以上是另一个区间,不能跨越255这个坎,比如把长度从 100 扩展成 1000(因为 255 长度以内额外用1个字节表示,大于 255 长度则需要额外2个字节表示)。另外还不支持在线缩小 VARCHAR 的长度。

  10. 以及更多关于性能上的改善提升,包括客户端连接效率提升、批量数据加载效率提升、sort buffer中存储的非排序字段是压缩模式的(提高内存利用率)、UNION ALL不再产生临时表、解析器重构、查询优化器进一步完善(比如增加可控CBO规则)等等。

 

 

 以上内容出自http://imysql.com,感觉叶老师的分享!

相关的参考资料:http://mp.weixin.qq.com/s?__biz=MjM5MjIxNDA4NA==&mid=205236417&idx=1&sn=15281c834348911cea106478aa819175&3rd=MzA3MDU4NTYzMw==&scene=6#rd

                      http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html#mysql-nutshell-removals