Suzf Blog

就地升级是使用服务器中的现有数据来完成。 一般来说，就是停止服务器，安装新的服务器版本并使用之前的数据文件启动它。 虽然它可能不适合于高复杂性的环境，但它们可能适用于许多场景。 以下是5.7系列中相关的改变的总结。 强烈建议您阅读以下指南，因为它们包含可能导致自动升级失败的不兼容更改的信息：

1. Changed in Percona Server 5.7
2. Upgrading MySQL
3. Upgrading from MySQL 5.6 to 5.7

前言 坑无处不有。对各个组件大家都是仁者见仁智者见智。 各个组件的工作原理适用场景就不在一 一阐述。 ...... 待续 ...... 环境准备 Corosync 安装与配置 Pacemaker 安装与配置 DRBD 安装与配置 MySQL 安装与配置 Crm 资源管理

在 Ubuntu 中 使用 apt-get  安装的Mysql. 打算换一下 数据目录，初始化数据的时候却遇到下面错误。数据目录可读可写， mysql 配置文件也已经更新。初始化数据综总是失败。

# cat /etc/mysql/my.cnf | grep datadir
#datadir        = /var/lib/mysql
datadir        = /data/mysql-drbd
# ll /data/| grep mysql
drwxr-xr-x  5 mysql mysql 4096 Jun 28 16:05 mysql-drbd/
#mysql_install_db --user=mysql --datadir=/data/mysql-drbd/
...
160628 15:50:21 [Note] /usr/sbin/mysqld (mysqld 5.5.49-0ubuntu0.14.04.1) starting as process 8813 ...
160628 15:50:21 [Warning] Can't create test file /data/mysql-drbd/eva.lower-test
160628 15:50:21 [Warning] Can't create test file /data/mysql-drbd/eva.lower-test
...

曾经初学的时候 被 selinux 坑了无数回。 默认  Ubuntu selinux 是不安装的。 setenforce 0 临时关闭 因为这里没有 安装 selinux 所以直接略过。

介绍 在日常维护工作当中经常会需要对数据进行导出操作，而mysqldump是导出数据过程中使用非常频繁的一个工具；它自带的功能参数非常多，文章中会列举出一些常用的操作，在文章末尾会将所有的参数详细说明列出来。 语法： 默认不带参数的导出，导出文本内容大概如下：创建数据库判断语句-删除表-创建表-锁表-禁用索引-插入数据-启用索引-解锁表。

Usage: mysqldump [OPTIONS] database [tables]
OR     mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]
OR     mysqldump [OPTIONS] --all-databases [OPTIONS]

背景

在写压力负载比较重的MySQL实例上，InnoDB可能积累了较长的没有被purge掉的transaction history，导致实例性能的衰减，或者空闲空间被耗尽，下面就来看看它是怎么产生的，或者有没有什么方法来减轻，避免这样的问题出现。

InnoDB purge 概要

InnoDB是一个事务引擎，实现了MVCC特性，也就是在存储引擎里对行数据保存了多个版本。在对行数据进行delete或者update更改时，行数据的前映像会保留一段时间，直到可以被删除的时候。

在大部分OLTP负载情况下，前映像会在数据操作完成后的数秒钟内被删除掉，但在一些情况下，假设存在一些持续很长时间的事务需要看到数据的前映像，那么老版本的数据就会被保留相当长一段时间。

虽然MySQL 5.6版本增加了多个purge threads来加快完成老版本数据的清理工作，但在write-intensive workload情况下，不一定完全凑效。

准备工作

Mysql 单机多实例详解 What is the GTID of the replication

实验环境

Os: CentOS 6.X Mysql: 5.6 单机多实例 [3306,3307] Hostname: lab.suzf.net

场景一：新机器 无数据

对于GTID的配置，主要修改配置文件中与GTID特性相关的几个重要参数

GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID，它由服务器ID以及事务ID组合而成。这个全局事务ID不仅仅在原始服务器器上唯一，在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单，以及数据库一致性更可靠。本文主要描述了快速配置一个基于GTID的主从复制架构，供大家参考。

一、GTID的概念

1、全局事务标识：global transaction identifiers。
2、GTID是一个事务一一对应，并且全局唯一ID。
3、一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
4、GTID用来代替传统复制方法，不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。
5、MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。
6、在传统的slave端，binlog是不用开启的，但是在GTID中slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）。

二、GTID的组成

GTID = source_id:transaction_id
source_id，用于鉴别原服务器，即mysql服务器唯一的的server_uuid，由于GTID会传递到slave，所以也可以理解为源ID。
transaction_id，为当前服务器上已提交事务的一个序列号，通常从1开始自增长的序列，一个数值对应一个事务。
示例：
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
前面的一串为服务器的server_uuid，即3E11FA47-71CA-11E1-9E33-C80AA9429562，后面的23为transaction_id

三、GTID的优势

1、更简单的实现failover，不用以前那样在需要找log_file和log_pos。
2、更简单的搭建主从复制。
3、比传统的复制更加安全。
4、GTID是连续的没有空洞的，保证数据的一致性，零丢失。

四、GTID的工作原理

1、当一个事务在主库端执行并提交时，产生GTID，一同记录到binlog日志中。
2、binlog传输到slave,并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。
3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID。
4、如果有记录，说明该GTID的事务已经执行，slave会忽略。
5、如果没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog，
在读取执行事务前会先检查其他session持有该GTID，确保不被重复执行。
6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

节选自： 乐沙弥的世界

 

前几天又有同事掉进了给 SQL 的 IN 条件传参的坑，就像 SELECT col1, col2 FROM table1 WHERE id IN (1, 2, 3) 这类 SQL，如果是一个可变的列表作为 IN 的参数，那这个参数应该怎么传呢？

我见过至少这么几种：

id_list = [1, 2, 3]
cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)', id_list)

这种方式是语法错误的，原因是 MySQLdb 做字符串格式化时占位符和参数个数不匹配。

id_list = [1, 2, 3]
cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)', (id_list,))

这种方式语法是正确的，但语义是错误的，因为生成的 SQL 是 SELECT col1, col2 FROM table1 WHERE id IN ((‘1’, ‘2’, ‘3’))

id_list = [1, 2, 3]
id_list = ','.join([str(i) for i in id_list])
cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)', id_list)

这种方式语义也是错误的，因为生成的 SQL 是 SELECT col1, col2 FROM table1 WHERE id IN (‘1,2,3’)

这三种是第一次使用 MySQLdb 给 IN 传参时犯的最多的错误，大多数人遇到第一种错和掉进后两个坑之后，转而采用了下面的方式：

id_list = [1, 2, 3]
id_list = ','.join([str(i) for i in id_list])
cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)' % id_list)

这个方式对于可信的参数(比如自己生成的列表：range(1, 10, 2))来说可以用，但由于参数未经 escape，对于从用户端接受的不可信参数来说，存在 SQL 注入的风险。

严防 SQL 注入的问题时刻都不能松懈，于是就有了这样的改进版本：

id_list = [1, 2, 3]
id_list = ','.join([str(cursor.connection.literal(i)) for i in id_list])
cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)' % id_list)

这个方式控制了 SQL 注入问题的滋生，但由于 cursor.connection.literal 是内部接口，并不推荐从外部使用。

然后就有了这样的方式：

id_list = [1, 2, 3]
arg_list = ','.join(['%s'] * len(id_list))
cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)' % arg_list, id_list)

这个方式是先生成与参数个数相同的 %s 占位，拼出 ‘SELECT col1, col2 FROM table1 WHERE id IN (%s,%s,%s)’ 这样的 SQL，然后使用安全的方式来传参。

就是想传一个参数而已，怎么会这么麻烦呢？触令丧惨！

更正：以下划线内容为未经充分测试的错误结论，仅做记录：

一直以为 MySQLdb 是不支持给 IN 传参的，直到这次又有同事掉坑我才读了 MySQLdb escape 部分的代码，然后发现，MySQLdb 是在很多类型的 Python object 和 SQL 支持的类型之间做自动转换的，比如 MySQLdb 会对 list 和 tuple 内的元素逐个进行 escape，生成一个 tuple，因此这才是正确的给 IN 传参的方式：

id_list = [1, 2, 3]
cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN %s', (id_list,))

可以把 MySQLdb 处理参数的过程简化描述为：

1. 对参数 (id_list,) 做 escape 得到 ((‘1’, ‘2’, ‘3’),)
2. 用 escape 过的参数对 SQL 进行格式化：’SELECT col1, col2 FROM table1 WHERE id IN %s’ % ((‘1’, ‘2’, ‘3’),)，得到完整 SQL：’SELECT col1, col2 FROM table1 WHERE id IN (‘1’, ‘2’, ‘3’)

整理一下口诀：IN 的参数和其他参数一样，是一个整体，就要不要对属于参数一部分的 () 念念不忘了……

总结一下评论中对这个方法提出的问题：

1. 如果参数列表只有一个元素，比如 cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN %s', ([1],))，生成的 SQL 是 SELECT col1, col2 FROM table1 WHERE id IN ('1',)，是语法错误的
2. 对列表内元素做 esacpe 时增加的引号会被留下，如果列表元素是字符串，结果会是错误的，比如 cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN %s', (["1", "2"],)) 生成的 SQL 是 SELECT col1, col2 FROM table1 WHERE id IN ("'1'", "'2'")，而对于数字参数恰好能正确工作的原因是，在执行 SQL 时如果列定义是 int 而传参为字符串，MySQL 会做隐式类型转换（Type Conversion in Expression Evaluation）。

MySQLdb 支持对各种类型的 Python object 进行转换和 escape，感兴趣的同学可以看看 MySQLdb.converters 和 _mysql.c 中 *_escape* 系列的函数，另外 MySQLdb 也支持自定义转换规则，参见 MySQLdb.connect 的 conv 参数。

来源:  互联网

 

在 Mysql 5.6 中，里面有许多新的特性；我个人认为其中最有用的是在复制中支持 全局事务ID(Global Transaction ID)。
这篇文章不是用来介绍什么是GTID，关于它的工作原理这里有很多文章介绍：
http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-concepts.html

这里值得一提的是，如果你想GTID支持log_slave_updates，需要启用从服务器和考虑到性能的影响。

还有，这篇文章更趋向于实用，我们将要看到如何使用 GTID 创建/恢复 新的slaves 从 master上。