Linux高级篇--MySQL高可用集群

MySQL集群

MySQL高可用

• MMM: Multi-Master Replication Manager for MySQL，Mysql主主复制管理器是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)
    官网： http://www.mysql-mmm.org
    https://code.google.com/archive/p/mysql-master-master/downloads

• MHA： Master High Availability，对主节点进行监控，可实现自动故障转移至其它从节点；通过提升某一从节点为新的主节点，基于主从复制实现，还需要客户端配合实现，目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，出于机器成本的考虑，淘宝进行了改造，目前淘宝TMHA已经支持一主一从
    官网:https://code.google.com/archive/p/mysql-master-ha/

• Galera Cluster：wsrep(MySQL extended with the Write Set Replication)
  通过wsrep协议在全局实现复制；任何一节点都可读写，不需要主从复制，实现多主读写

• MHA集群架构

• MHA

MHA工作原理

• MHA工作原理
    1 从宕机崩溃的master保存二进制日志事件（binlog events）
    2 识别含有最新更新的slave
    3 应用差异的中继日志（relay log）到其他的slave
    4 应用从master保存的二进制日志事件（binlog events）
    5 提升一个slave为新的master
    6 使其他的slave连接新的master进行复制

MHA

• MHA软件由两部分组成，Manager工具包和Node工具包
• Manager工具包主要包括以下几个工具：
    masterha_check_ssh 检查MHA的SSH配置状况
    masterha_check_repl 检查MySQL复制状况
    masterha_manger 启动MHA
    masterha_check_status 检测当前MHA运行状态
    masterha_master_monitor 检测master是否宕机
    masterha_master_switch 故障转移（自动或手动）
    masterha_conf_host 添加或删除配置的server信息
• Node工具包：这些工具通常由MHA Manager的脚本触发，无需人为操作）主要包括以下几个工具：
    save_binary_logs 保存和复制master的二进制日志
    apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的slave
    filter_mysqlbinlog 去除不必要的ROLLBACK事件（MHA已不再使用此工具）
    purge_relay_logs 清除中继日志（不会阻塞SQL线程）
  注意：为了尽可能的减少主库硬件损坏宕机造成的数据丢失，因此在配置MHA的同时建议配置成MySQL 5.5的半同步复制
• 自定义扩展：
    secondary_check_script： 通过多条网络路由检测master的可用性
    master_ip_ailover_script： 更新Application使用的masterip
    shutdown_script： 强制关闭master节点
    report_script： 发送报告
    init_conf_load_script： 加载初始配置参数
    master_ip_online_change_script：更新master节点ip地址
• 配置文件：
    global配置，为各application提供默认配置
    application配置：为每个主从复制集群

实现MHA

• 在管理节点上安装两个包：
  mha4mysql-manager
  mha4mysql-node
• 在被管理节点安装：
  mha4mysql-node
  注意：软件包需要在互联网下载

示例：

实验环境
需要四台机器：管理节点，一主两从
    管理节点：192.168.32.203
    master主机：192.168.32.200
    slave01主机：192.168.32.201
    slave02：192.168.32.202

初始化环境：
主从服务器停止mariadb服务，删除数据库，启动mariadb服务

关闭selinux，关闭iptables防火墙
时间必须同步

实现免密钥认证
在管理节点192.168.32.203上
    生成密钥文件
        ssh-keygen
        接下来的选项直接确认即可，即连续按三下enter键
    把密钥文件复制到本机
        ssh-copy-id 192.168.32.203
    查看生成的文件
        cd .ssh
        [root@ma .ssh]# ll
        total 16
        -rw-------  1 root root  389 Dec 25 20:48 authorized_keys
        -rw-------  1 root root 1675 Dec 25 20:47 id_rsa
        -rw-r--r--  1 root root  389 Dec 25 20:47 id_rsa.pub
        -rw-r--r--. 1 root root  352 Dec 25 20:48 known_hosts
    把/root/.ssh文件复制给其他三个节点即可实现免密钥认证
        scp -rp /root/.ssh  192.168.32.200:/root/
        scp -rp /root/.ssh  192.168.32.201:/root/
        scp -rp /root/.ssh  192.168.32.202:/root/

准备主从复制的配置文件
    主服务器配置文件：
        vim /etc/my.cnf
        [mysqld]
        server_id=1
        innodb_file_per_table
        log_bin
        skip_name_resolve   #注意：该选项必须添加，否则MHA可能会失败
    重启mariadb服务
        systemctl restart mariadb
    创建复制账号
        [root@master ~]# mysql
        MariaDB [(none)]> grant replication slave on *.* to repluser@'192.168.32.%' identified by 'magedu';
    创建管理账号
        MariaDB [(none)]> grant all on *.* to mhauser@'192.168.32.%' identified by 'magedu';

    从服务器192.168.32.201配置文件：
        vim /etc/my.cnf
        [mysqld]
        server_id=2
        innodb_file_per_table
        log_bin      #从节点有可能被提升为主节点，因此必须启用二进制日志
        read_only     #一旦从节点被提升为主节点，将会自动更改只读为可读写状态，因此该选项可以添加到从服务器配置文件中
        relay_log_purge=0    #中继日志
        skip_name_resolve
    重启mariadb服务
        systemctl restart mariadb

    从服务器192.168.32.202配置文件：
        vim /etc/my.cnf
        [mysqld]
        server_id=3
        innodb_file_per_table
        log_bin      #从节点有可能被提升为主节点，因此必须启用二进制日志
        read_only     #一旦从节点被提升为主节点，将会自动更改只读为可读写状态，因此该选项可以添加到从服务器配置文件中
        relay_log_purge=0    #中继日志
        skip_name_resolve
    重启mariadb服务
        systemctl restart mariadb

实验主从复制
    在从服务器192.168.32.201和192.168.32.202上进行以下配置：
        [root@slave02 ssl]# mysql
        MariaDB [(none)]> CHANGE MASTER TO
          MASTER_HOST='192.168.32.200',
          MASTER_USER='repluser',
          MASTER_PASSWORD='magedu',
          MASTER_LOG_FILE='mariadb-bin.000001',
          MASTER_LOG_POS=245;
        #注意：主从复制要从初始点开始复制，要把创建的复制账号信息一并复制给从节点
        MariaDB [(none)]> start slave;
        MariaDB [(none)]> show slave status\G

    测试：能否实现主从同步
    在主服务器上导入测试数据库
        mysql < hellodb_innodb.sql 
    在从服务器查看导入主服务器的测试数据库是否同步到从服务器

配置MHA
    在管理节点上需要安装manager软件包和node软件包
    把下载的软件包复制到管理节点上
        软件包名：
        mha4mysql-manager-0.56-0.el6.noarch.rpm
        mha4mysql-node-0.56-0.el6.noarch.rpm
    在管理节点192.168.32.203主机上
        yum -y install mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm  
        注意：软件包的安装必须启用epel源，解决依赖关系

    在被管理节点上需要安装node软件包
    分别在192.168.32.200、192.168.32.201、192.168.32.202三台主机上安装node软件包
    软件包名为：mha4mysql-node-0.56-0.el6.noarch.rpm
        yum -y install mha4mysql-node-0.56-0.el6.noarch.rpm

创建MHA配置文件
    在管理节点192.168.32.203上
        mkdir /etc/mha
        vim /etc/mha/app1.cnf
        [server default]   #管理节点默认配置
        user=mhauser          #管理主从集群的账号
        password=magedu        #管理账号的密码
        manager_workdir=/data/mha/app1/  #管理节点工作目录
        manager_log=/data/mha/app1/manager.log  #管理节点日志，有助于排错
        remote_workdir=/data/mha/app1/  #被管理节点工作目录
        ssh_user=root         #远程ssh连接用户身份
        repl_user=repluser    #远程复制账号
        repl_password=magedu    #远程复制账号的密码
        ping_interval=1        #监控被管理节点状态，一秒钟探测一次，如果发现故障就提升从服务器为新的主服务器
        #以下为被管理的三个节点
        [server1]              #被管理节点
        hostname=192.168.32.200
        candidate_master=1       #有资格充当master的从服务器
        [server2]              #被管理节点
        hostname=192.168.32.201
        candidate_master=1       #有资格充当master的从服务器
        [server3]              #被管理节点
        hostname=192.168.32.202
    使用脚本进行MHA验证和启动
        masterha_check_ssh --conf=/etc/mha/app1.conf   #验证ssh连接
        masterha_check_repl --conf=/etc/mha/app1.conf  #验证复制账号连接
        masterha_manager --conf=/etc/mha/app1.cnf  #启用MHA
        注意：该启动脚本以前台方式启动，如果中断关闭则MHA将会关闭，可以使用screen或nohup确保连接不能中断

测试：验证MHA是否成功启用
    模拟主节点出现故障：
        1.主节点服务器数据库服务出现故障
        2.主节点物理服务器出现故障宕机    

    在主节点192.168.32.200主机上
        强制关闭mysql服务，查看是否启用从服务器为新的主节点
        killall mysqld
    在管理节点192.168.32.203上
        MHA前台进程自动关闭，该进程是一次性任务，完成任务就会结束，如果想要使用MHA，需要再次启动
    查看日志
      tail -50 /data/mha/app1/manager.log  
      ----- Failover Report -----

      app1: MySQL Master failover 192.168.32.200(192.168.32.200:3306) to 192.168.32.201(192.168.32.201:3306) succeeded

      Master 192.168.32.200(192.168.32.200:3306) is down!

      Check MHA Manager logs at ma:/data/mastermha/app1/manager.log for details.

      Started automated(non-interactive) failover.
      The latest slave 192.168.32.201(192.168.32.201:3306) has all relay logs for recovery.
      Selected 192.168.32.201(192.168.32.201:3306) as a new master.
      192.168.32.201(192.168.32.201:3306): OK: Applying all logs succeeded.
      192.168.32.202(192.168.32.202:3306): This host has the latest relay log events.
      Generating relay diff files from the latest slave succeeded.
      192.168.32.202(192.168.32.202:3306): OK: Applying all logs succeeded. Slave started, replicating from 192.168.32.201(192.168.32.201:3306)
      192.168.32.201(192.168.32.201:3306): Resetting slave info succeeded.
      Master failover to 192.168.32.201(192.168.32.201:3306) completed successfully.
    从日志可以看出192.168.32.201称为新的主服务器，而从服务器192.168.32.202也指向新的主服务器192.168.32.201

    在从服务器192.168.32.202验证
        MariaDB [(none)]> show slave status\G
        *************************** 1. row ***************************
                       Slave_IO_State: Waiting for master to send event
                          Master_Host: 192.168.32.201
                          Master_User: repluser
                          Master_Port: 3306
                        Connect_Retry: 60
                      Master_Log_File: mariadb-bin.000001
                  Read_Master_Log_Pos: 245
                       Relay_Log_File: mariadb-relay-bin.000002
                        Relay_Log_Pos: 531
                Relay_Master_Log_File: mariadb-bin.000001
                     Slave_IO_Running: Yes
                    Slave_SQL_Running: Yes
                      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: 245
                      Relay_Log_Space: 827
                      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: 0
        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: 2
    在配置文件中，从服务器设置为read_only只读状态，现在查看新的主服务器是否为只读状态
        MariaDB [none]> show variables like 'read_only';
        +---------------+-------+
        | Variable_name | Value |
        +---------------+-------+
        | read_only     | OFF   |
        +---------------+-------+       
    可以发现，read_only只读状态自动被关闭
    注意：此时要把配置文件中的read_only选项删除，更改后无需重启服务

    在新的主服务器192.168.32.201上插入数据查看能否同步
        MariaDB [(none)]> use hellodb
        MariaDB [hellodb]> insert teachers values(6,'b',30,'M');
    在从服务器192.168.32.202上查看信息是否同步
        MariaDB [(none)]> select * from hellodb.teachers;
        +-----+---------------+-----+--------+
        | TID | Name          | Age | Gender |
        +-----+---------------+-----+--------+
        |   1 | Song Jiang    |  45 | M      |
        |   2 | Zhang Sanfeng |  94 | M      |
        |   3 | Miejue Shitai |  77 | F      |
        |   4 | Lin Chaoying  |  93 | F      |
        |   5 | a             |  30 | F      |
        |   6 | b             |  30 | M      |
        +-----+---------------+-----+--------+

Galera Cluster

• Galera Cluster：集成了Galera插件的MySQL集群，是一种新型的，数据不共享的，高度冗余的高可用方案，目前Galera Cluster有两个版本，分别是Percona Xtradb Cluster及MariaDB Cluster，Galera本身是具有多主特性的，即采用multi-master的集群架构，是一个既稳健，又在数据一致性、完整性及高性能方面有出色表现的高可用解决方案
• 下图图示：三个节点组成了一个集群，与普通的主从架构不同，它们都可以作为主节点，三个节点是对等的，称为multi-master架构，当有客户端要写入或者读取数据时，连接哪个实例都是一样的，读到的数据是相同的，写入某一个节点之后，集群自己会将新数据同步到其它节点上面，这种架构不共享任何数据，是一种高冗余架构

• Galera Cluster特点
  多主架构：真正的多点读写的集群，在任何时候读写数据，都是最新的
  同步复制：集群不同节点之间数据同步，没有延迟，在数据库挂掉之后，数据不会丢失
  并发复制：从节点APPLY数据时，支持并行执行，更好的性能
  故障切换：在出现数据库故障时，因支持多点写入，切换容易
  热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务时间就会非常少。在节点故障期间，节点本身对集群的影响非常小
  自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不需要人工手动备份提供，Galera Cluster会自动拉取在线节点数据，最终集群会变为一致
  对应用透明：集群的维护，对应用程序是透明的

• Galera Cluster工作过程

• 具体过程如下：
    client端向server端发送dml更新操作请求时，server的native本地进程处理请求，并返回OK准备接收。
    client发送commit更新事务给server，server将replicate writeset复制写数据集发给group（cluster集群），cluster将该数据集对应产生的唯一的GTID（global transaction ID）发送给集群每个server（节点）。
    当前server节点验证通过后，执行commit_cd动作更新本地数据库，并返回OK；若其他节点验证不通过，则执行rollback_cd，回滚刚提交的事务。
    其他server(other server)接收并验证通过后，执行apply_cd和commit_cd动作更新本地数据库；若验证不通过，则丢弃该数据集。

• Galera Cluster官方文档：
  http://galeracluster.com/documentation-webpages/galera-documentation.pdf
  http://galeracluster.com/documentation-webpages/index.html
  https://mariadb.com/kb/en/mariadb/getting-started-with-mariadb-galera-cluster/

• Galera Cluster包括两个组件
    Galera replication library (galera-3)
    WSREP：MySQL extended with the Write Set Replication

• WSREP复制实现：
    percona-cluster
    MariaDB-Cluster
  注意：都至少需要三个节点，不能安装mariadb-server

Galera Cluster实现

• 具体步骤如下：

实验环境
master01主机：192.168.32.200
master02主机：192.168.32.201
master03主机：192.168.32.202

配置Galera Cluster：
    分别在三台主机上安装软件包MariaDB-Galera-server
    配置yum仓库如下：
        vim /etc/yum.repos.d/mysql.repo
        [mysql]
        name=Galera-Cluster.repo
        baseurl=https://mirrors.tuna.tsinghua.edu.cn/mariadb/mariadb-5.5.62/yum/centos7-amd64/
        gpgcheck=0

    安装软件包：
        yum -y install MariaDB-Galera-server  #注意大小写

    在master01主机192.168.32.200上
        vim /etc/my.cnf.d/server.cnf
        [galera]
        # Mandatory settings
        wsrep_provider=/usr/lib64/galera/libgalera_smm.so
        wsrep_cluster_address="gcomm://192.168.32.200,192.168.32.201,192.168.32.202"
        binlog_format=row
        default_storage_engine=InnoDB
        innodb_autoinc_lock_mode=2
        bind-address=0.0.0.0
    配置完成后，把配置文件复制到另外两台主机上
        scp  /etc/my.cnf.d/server.cnf  192.168.32.201:/etc/my.cnf.d/
        scp  /etc/my.cnf.d/server.cnf  192.168.32.202:/etc/my.cnf.d/

    首次启动时，需要初始化集群，在其中一个节点上执行命令
        /etc/init.d/mysql start --wsrep-new-cluster
    而后正常启动其它节点
        service mysql start
    查看集群中相关系统变量和状态变量
        SHOW VARIABLES LIKE 'wsrep_%';
        SHOW STATUS LIKE 'wsrep_%';
        SHOW STATUS LIKE 'wsrep_cluster_size';

测试：查看集群能否同步
    在master01上导入测试数据库
        mysql < hellodb_innodb.sql   #导入hellodb数据库
    在其他节点上查看能否自动同步
        MariaDB [(none)]> show databases;
        +--------------------+
        | Database           |
        +--------------------+
        | information_schema |
        | hellodb            |
        | mysql              |
        | performance_schema |
        | test               |
        +--------------------+

测试：主主模型，在加入数据时，会出现id号冲突现象，现在在两个节点同时加入数据查看是否能够解决冲突问题
    在SecureCRT上同时向三个终端窗口发送插入数据的命令
        MariaDB [(none)]> use hellodb
        MariaDB [hellodb]> insert teachers(name,age,gender)values('a',30,'M');
    查看结果，发现自动解决冲突问题
        MariaDB [hellodb]> select * from teachers;
        +-----+---------------+-----+--------+
        | TID | Name          | Age | Gender |
        +-----+---------------+-----+--------+
        |   1 | Song Jiang    |  45 | M      |
        |   2 | Zhang Sanfeng |  94 | M      |
        |   3 | Miejue Shitai |  77 | F      |
        |   4 | Lin Chaoying  |  93 | F      |
        |   6 | a             |  30 | M      |
        |   7 | a             |  30 | M      |
        |   8 | a             |  30 | M      |
        +-----+---------------+-----+--------+

复制的问题和解决方案

• 复制的问题和解决方案：
  (1) 数据损坏或丢失
    Master： MHA + semi repl，即MHA加半同步复制
    Slave： 重新复制
  (2) 混合使用存储引擎，MyISAM即将淘汰，不推荐使用
    MyISAM：不支持事务
    InnoDB： 支持事务
  (3) 不惟一的server id
    重新复制
  (4) 复制延迟
    需要额外的监控工具的辅助
    一从多主:mariadb10版后支持
    多线程复制：对多个数据库复制

性能衡量指标

• 数据库服务衡量指标：
    qps: query per second
    tps: transaction per second
• 压力测试工具：
    mysqlslap
    Sysbench：功能强大
      https://github.com/akopytov/sysbench
    tpcc-mysql
    MySQL Benchmark Suite
    MySQL super-smack
    MyBench

MySQL压力测试

• Mysqlslap：来自于mariadb包，测试的过程默认生成一个mysqlslap的schema,生成测试表t1，查询和插入测试数据，mysqlslap库自动生成，如果已经存在则先删除。用–only-print来打印实际的测试过程，整个测试完成后不会在数据库中留下痕迹
• 使用格式：mysqlslap [options]
• 常用参数 [options] 说明：
    --auto-generate-sql, -a 自动生成测试表和数据，表示用mysqlslap工具自己生成的SQL脚本来测试并发压力
    --auto-generate-sql-load-type=type 测试语句的类型。代表要测试的环境是读操作还是写操作还是两者混合的。取值包括：read，key，write，update和mixed(默认)
    --auto-generate-sql-add-auto-increment 代表对生成的表自动添加auto_increment列，从5.1.18版本开始支持
    --number-char-cols=N, -x N 自动生成的测试表中包含多少个字符类型的列，默认1
    --number-int-cols=N, -y N 自动生成的测试表中包含多少个数字类型的列，默认1
    --number-of-queries=N 总的测试查询次数(并发客户数×每客户查询次数)
    --query=name,-q 使用自定义脚本执行测试，例如可以调用自定义的存储过程或者sql语句来执行测试
    --create-schema 代表自定义的测试库名称，测试的schema
    --commint=N 多少条DML后提交一次
    --compress, -C 如服务器和客户端都支持压缩，则压缩信息
    --concurrency=N, -c N 表示并发量，即模拟多少个客户端同时执行select。可指定多个值，以逗号或者–delimiter参数指定值做为分隔符如：–concurrency=100,200,500
    --engine=engine_name, -e engine_name 代表要测试的引擎，可以有多个，用分隔符隔开。例如：–engines=myisam,innodb
    --iterations=N, -i N 测试执行的迭代次数，代表要在不同并发环境下，各自运行测试多少次
    --only-print 只打印测试语句而不实际执行。
    --detach=N 执行N条语句后断开重连
    --debug-info, -T 打印内存和CPU的相关信息

mysqlslap示例：

单线程测试
mysqlslap -a -uroot -pmagedu
多线程测试。使用–concurrency来模拟并发连接
mysqlslap -a -c 100 -uroot -pmagedu
迭代测试。用于需要多次执行测试得到平均值
mysqlslap -a -i 10 -uroot -pmagedu
mysqlslap ---auto-generate-sql-add-autoincrement -a
mysqlslap -a --auto-generate-sql-load-type=read
mysqlslap -a --auto-generate-secondary-indexes=3
mysqlslap -a --auto-generate-sql-write-number=1000
mysqlslap --create-schema world -q "select count(*) from City”
mysqlslap -a -e innodb -uroot -pmagedu
mysqlslap -a --number-of-queries=10 -uroot -pmagedu
测试同时不同的存储引擎的性能进行对比
mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --iterations=5 --engine=myisam,innodb --debug-info -uroot -pmagedu
执行一次测试，分别50和100个并发，执行1000次总查询
mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --debug-info -uroot -pmagedu
50和100个并发分别得到一次测试结果(Benchmark)，并发数越多，执行完所有查询的时间越长。为了准确起见，可以多迭代测试几次
mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --iterations=5 --debug-info -uroot -pmagedu

生产环境my.cnf配置示例：

硬件：内存32G

innodb_file_per_table = 1
打开独立表空间
max_connections = 8000
#MySQL 服务所允许的同时会话数的上限，经常出现Too Many Connections的错误提示，则需要增大此值
back_log = 300
#back_log 是操作系统在监听队列中所能保持的连接数
max_connect_errors = 1000
#每个客户端连接最大的错误允许数量，当超过该次数，MYSQL服务器将禁止此主机的连接请求，直到MYSQL服务器重启或通过flush hosts命令清空此主机的相关信息
open_files_limit = 10240
#所有线程所打开表的数量
max_allowed_packet = 32M
#每个连接传输数据大小.最大1G，须是1024的倍数，一般设为最大的BLOB的值
wait_timeout = 10
#指定一个请求的最大连接时间
sort_buffer_size = 16M
# 排序缓冲被用来处理类似ORDER BY以及GROUP BY队列所引起的排序
join_buffer_size = 16M
#不带索引的全表扫描.使用的buffer的最小值
query_cache_size = 128M
#查询缓冲大小
query_cache_limit = 4M
#指定单个查询能够使用的缓冲区大小，缺省为1M
transaction_isolation = REPEATABLE-READ
# 设定默认的事务隔离级别
thread_stack = 512K
# 线程使用的堆大小. 此值限制内存中能处理的存储过程的递归深度和SQL语句复杂性，此容量的内存在每次连接时被预留.
log-bin
# 二进制日志功能
binlog_format=row
#二进制日志格式
innodb_buffer_pool_size = 24G
#InnoDB使用一个缓冲池来保存索引和原始数据, 可设置这个变量到服务器物理内存大小的80%
innodb_file_io_threads = 4
#用来同步IO操作的IO线程的数量
innodb_thread_concurrency = 16
#在InnoDb核心内的允许线程数量，建议的设置是CPU数量加上磁盘数量的两倍
innodb_log_buffer_size = 16M
# 用来缓冲日志数据的缓冲区的大小
innodb_log_file_size = 512M
在日志组中每个日志文件的大小
innodb_log_files_in_group = 3
# 在日志组中的文件总数
innodb_lock_wait_timeout = 120
# SQL语句在被回滚前,InnoDB事务等待InnoDB行锁的时间
long_query_time = 2
#慢查询时长
log-queries-not-using-indexes
#将没有使用索引的查询也记录下来

MySQL配置最佳实践

• 高并发大数据的互联网业务，架构设计思路是“解放数据库CPU，将计算转移到服务层”，并发量大的情况下，这些功能很可能将数据库拖死，业务逻辑放到服务层具备更好的扩展性，能够轻易实现“增机器就加性能”
• 参考：
    阿里巴巴Java开发手册
    58到家数据库30条军规解读
    http://zhuanlan.51cto.com/art/201702/531364.html