时间戳

首页 > 技术文章 > Percona博客学习总结

Percona博客学习总结

ivictor 2016-05-06 12:54 原文

1. Upgrading to MySQL 5.7, focusing on temporal types

    在MySQL 5.6.4中，对TIME, TIMESTAMP and DATETIME三种时间类型进行了扩充，支持了微秒，并且DATETIME的存储由之前的8个字节缩小到5个字节。

MySQL 5.6.4在Server层新增三种时间类型MYSQL_TYPE_TIME2，MYSQL_TYPE_DATETIME2，MYSQL_TYPE_TIMESTAMP2，并在InnoDB层以二进制的格式存储，用这种方式来实现时间类型支持小数精度并优化存储节省空间。

    如果从MySQL 5.5升级到5.6，使用mysql_upgrade，mysql_upgrade并不会显示的将之前的类型转换成新类型，只是新建的表会使用新类型。

    但如果是升级到5.7，则mysql_upgrade会将旧类型转换为新类型，而这可能导致升级的过程比较漫长。

    对于上述情况，如果避免呢？

    1. mysql_upgrade支持upgrade-system-tables选项，在升级时可指该参数，只升级系统表，而不升级普通表

    2. 升级完毕后，再使用alter table或者pt-online-schema-schange修改表的数据类型。

    可通过以下命令查看升级完毕后，各表中上述三个字段的新旧情况。   

SELECT CASE isc.mtype
           WHEN '6' THEN 'OLD'
           WHEN '3' THEN 'NEW'
       END FORMAT,
       t.schema_name,
       t.table_name
FROM information_schema.tables AS t
INNER JOIN information_schema.columns AS c ON c.table_schema = t.table_schema
AND c.table_name = t.table_name
LEFT OUTER JOIN information_schema.innodb_sys_tables AS ist ON ist.name = concat(t.table_schema,'/',t.table_name)
LEFT OUTER JOIN information_schema.innodb_sys_columns AS isc ON isc.table_id = ist.table_id
AND isc.name = c.column_name
WHERE c.column_type IN ('time','timestamp','datetime')
    AND t.table_schema NOT IN ('mysql','information_schema','performance_schema')
    AND t.table_type = 'base table'
    AND (t.engine = 'innodb');

      注意：5.6中t.shema_name应为t.TABLE_SCHEMA。

      具体可参考：https://www.percona.com/blog/2016/04/27/upgrading-to-mysql-5-7-focusing-on-temporal-types/

2. Best Practices for Configuring Optimal MySQL Memory Usage

    1> The first rule of configuring MySQL memory usage is you never want your MySQL to cause the operating system to swap.Even minor swapping activity can dramatically reduce MySQL performance.

        并不是有了swap就一定是坏事，有可能这些swap是在MySQL启动之前产生的。重点需要关注的是MySQL运行过程中的SWAP情况。

        这个可以很容易根据vmstat命令中的si和so列看出来。

    2> MySQL的内存分配很复杂，There are global buffers, per-connection buffers (which depend on the workload), and some uncontrolled memory allocations (i.e., inside Stored Procedures), all contributing to difficulties in computing how much memory MySQL will really use for your workload.

        比较合理的是查看MySQL使用的virtual memory size (VSZ)，这个可通过top命令或者ps aux | grep mysqld查看，单位是KB。

$ ps aux |grep mysqld
bdp      16569  0.0  0.0 103240   868 pts/0    S+   14:35   0:00 grep mysqld
bdp      25883  0.0  0.0 106220  1360 ?        S    Mar25   0:00 /bin/sh ./bin/mysqld_safe
bdp      26716 12.7  2.4 16884956 9652760 ?    Sl   Mar25 7684:17 /home/bdp/mysql/bin/mysqld --basedir=/home/bdp/mysql/ --datadir=/home/bdp/mysql/data/ --plugin-dir=/home/bdp/mysql//lib/plugin --log-error=/home/bdp/mysql/logs/mysqld.log --pid-file=/home/bdp/mysql/run/mysqld/mysqld.pid --socket=/home/bdp/mysql/tmp/mysql.sock
-bash-4.1$ bash

       上图中，VSZ16884956，大概16.1G    

       VSZ可能会随着时间发生变化，所以要及时监控这一项，Don’t allow the mysqld process VSZ exceed 90% of the system memory，如果服务器上还运行了其它的进程，阀值更小，一旦超过这个阀值，要及时发出告警（这点，可通过脚本实现）。

    3> 在大多数情况下，你不能将90%的内存分配给MySQL。有以下几点需要考虑：

        1. 有其它的重要进程运行在同一服务器上，无论是长期的还是周期性的，或者批量任务。

        2. 对于Innodb，推荐innodb_flush_method=O_DIRECT，这样就不会使用Operating System File Cache。但是对于MyISAM或者TokuDB，需要操作系统缓存来缓存数据。

        3. 对于MyISAM on disk temporary tables, sort files, some other temporary files，操作系统缓存还是必需的。

    4> 对于一个16G内存的服务器，innodb_buffer_pool_size分配多少比较合适呢？

        Let’s do some math for a specific example. Assume you have a system (physical or virtual) with 16GB of memory. We are only running MySQL on this system, with an InnoDB storage engine and use innodb_flush_method=O_DIRECT, so we can allocate 90% (or 14.4GB) of memory to MySQL. For our workload, we assume connection handling and other MySQL connection-based overhead will take up 1GB (leaving 13.4GB). 0.4GB is likely to be consumed by various other global buffers (innodb_log_buffer_size, Table Caches, other miscellaneous needs, etc.), which now leaves 13GB. Considering the 5-7% overhead that the InnodB Buffer Pool has, a sensible setting is innodb_buffer_pool_size=12G – what we very commonly see working well for systems with 16GB of memory.

    5> 配置完MySQL内存，下面来看看操作系统层面的配置。

        主要涉及以下几个方面：

        1. SWAP需要开启么？

            需要开启，争取最小4G，但不能超过服务器内存的25%。有以下两点原因：

            1> 操作系统可以将内存中没有使用的部分通过swap方式释放出去，而不是强制它们放到内存中。

            2> 如果你的MySQL配置出现错误，或者某些进程的内存消耗超过预期，会导致MySQL因内存溢出（OOM）直接被kill掉，如果有swap，最多是性能下降。

            可通过设置echo 1 >  /proc/sys/vm/swappiness降低系统对swap的使用，从而避免不必要的swap对性能造成的影响。这个参数定义了系统对swap的使用倾向，默认值为60，值越大表示越倾向于使用swap。

         2. 配置Out Of Memory killer

            echo '-800' > /proc/$(pidof mysqld)/oom_score_adj

            通过设置此值，可使Linux内核优先kill其它进程而不是MySQL。

         3. 在多核服务器中，关于NUMA的设置。

            在5.7.9中，引入了一个新的系统参数，innodb_numa_interleave，将其设置为1，Enables the NUMA interleave memory policy for allocation of the InnoDB buffer pool

            在之前，可通过numactl --interleave=all进行设置。

            具体可参考：https://www.percona.com/blog/2016/05/03/best-practices-for-configuring-optimal-mysql-memory-usage/

 

推荐阅读