高可用的并行MySQL数据同步及分布式

首先聊聊MySQL的数据分布式,目前最为常用的就是Replication(复制)技术。基于此技术外延开来有很多中架构,分类归结为如下:

     1、树状结构(Master,Backup-Master,Slaves)
        
        这种结构是目前Web系统用的最为通用的一种。整个系统有1个写入/更新点,即Master;Master-Backup和Slaves都是Replication的Master从库;多级Slave的原因是为了数据过滤和节省网络资源。

 

     2、环状结构(Master-Master,Slaves)
        
        Dual-Master结构是为了提高写吞吐而提出的,通过提高由原来一台MySQL Master服务器提供写/更新的
单点提高到2个点,从框架结构上来说就能看出此方法的提升。
        Dual-Master需要解决的问题:
        a)ID冲突问题,即对数据库中唯一ID资源的分配必须是一个统一的地方发出。
           解决办法有MySQL自带的auto_increment_increment和auto_increment_offset来实现,通过N个 Master来设置auto_increment_offset=N,每一台Master上的auto_increment_increment采用 1~N中的任意值,但是不能互相重复。如此一来即可。
           id-server: 1
           auto_increment_increment=1
           auto_increment_offset=2
           id-server: 2
           auto_increment_increment=2
           auto_increment_offset=2
           针对id-server1来说,id都是1,3,5这样;id-server2来说,id都是2,4,6这样。如此看似很美好,其实不然。在并发情况 下,id-server1上相同的表和在id-server2上的表auto_increment值是不同的,但是又需要相互同步,也就是说如果写入分布 不均的情况,就可能存在表中id会是1,3,5,7,8,9,11,etc这样的情况,id资源中间空洞太多。
           还有一种解决办法是一个独立的ID发号器。实现ID发号器的办法很多,为了让维护更加的纯粹,我们使用一个MySQL的一张表,Master-slave 这种结构的来作为一个发号器server。这样一来流程就变成了先去id发号器服务器获取id,再写入Dual-Master中去。多了一个中间环节,而 且此中间环节还是个单点,存在风险。但是思路基本这样,可以通过别的服务,基于一定分布式规则的来并行发号器。
        b)更新冲突的问题,一条范围的update语句被两台Master server都给执行了,这个时候数据就和最初设想的不一致了。
        c)死锁问题,这个在N(N>=3)个以上的环路Master中,出现异常断开后的服务器的binlog,在极端情况下会被恢复后的N-1个环路中的数据server反复执行。
    为了解决Multi-Master中的更新冲突和死锁问题,我的办法是多点Insert,但是只有一个点update这样的结构来解决以上b和c的问题。
        
    以上已经将Replication的常用的两种数据分布架构介绍清楚,下来看看另外一种,即MySQL Cluster。MySQL Cluster在一段时间内,我都认为它是相当的鸡肋,生产环境使用它的几乎没有。因为它在跨IDC和数据存储等资源消耗巨大。
    MySQL Cluster依赖的两个核心资源就是网络带宽和内存(share nothing和高一致性)。同IDC内的网络带宽还很容易达到百兆或者更高,但是跨IDC的VPN或者专线,要达到这样的速度还是有些困难。数据全部存 在内存中,这在小数据时感受不明显,但是对于爆炸式的信息增长来说未免很容易产生瓶颈。虽然新版的Cluster支持将数据写到硬盘,实际速度还有待观 察。
    Replication基本能够满足可用的需求,但是MySQL的binlog是一个单线程的,这就会在数据同步方面产生瓶颈。一般的做法是 通过写一个plugin,来提高并发能力;这个plugin既要满足性能,有要高可用。采用以下方式,通过将一些并行的App绑定在MySQL Cluster Queue上来执行,利用MySQL Cluster自身的高一致性,高可用的特点,存储消息。
    

 

 如此可以既能满足数据分布式,又能满足并行数据同步。
   
2013 年 9 月 4 日Permalink Leave a comment

mysql配置文件my.cnf详解[部分]

mysql配置文件my.cnf详解[部分]

basedir = path 使用给定目录作为根目录(安装目录)。
character-sets-dir = path 给出存放着字符集的目录。
datadir = path 从给定目录读取数据库文件。
pid-file = filename 为mysqld程序指定一个存放进程ID的文件(仅适用于UNIX/Linux系统); Init-V脚本需要使用这个文件里的进程ID结束mysqld进程。
socket = filename 为MySQL客户程序与服务器之间的本地通信指定一个套接字文件(仅适用于 UNIX/Linux系统; 默认设置一般是/var/lib/mysql/mysql.sock文件)。在Windows环境下,如果MySQL客户与服务器是通过命名管道进行通信 的,–sock选项给出的将是该命名管道的名字(默认设置是MySQL)。
lower_case_table_name = 1/0 新目录和数据表的名字是否只允许使用小写字母; 这个选项在Windows环境下的默认设置是1(只允许使用小写字母)。

 

mysqld程序:语言设置

character-sets-server = name 新数据库或数据表的默认字符集。为了与MySQL的早期版本保持兼容,这个字符集也可以用–default-character-set选项给出; 但这个选项已经显得有点过时了。
collation-server = name 新数据库或数据表的默认排序方式。
lanuage = name 用指定的语言显示出错信息。

 

mysqld程序:通信、网络、信息安全

enable-named-pipes 允许Windows 2000/XP环境下的客户和服务器使用命名管道(named pipe)进行通信。这个命名管道的默认名字是MySQL,但可以用–socket选项来改变。
local-infile [=0] 允许/禁止使用LOAD DATA LOCAL语句来处理本地文件。
myisam-recover [=opt1, opt2, ...] 在启动时自动修复所有受损的MyISAM数据表。这个选项的可取值有4种:DEFAULT、BACKUP、QUICK和FORCE; 它们与myisamchk程序的同名选项作用相同。
old-passwords 使用MySQL 3.23和4.0版本中的老算法来加密mysql数据库里的密码(默认使用MySQL 4.1版本开始引入的新加密算法)。
port = n 为MySQL程序指定一个TCP/IP通信端口(通常是3306端口)。
safe-user-create 只有在mysql.user数据库表上拥有INSERT权限的用户才能使用GRANT命令; 这是一种双保险机制(此用户还必须具备GRANT权限才能执行GRANT命令)。
shared-memory 允许使用内存(shared memory)进行通信(仅适用于Windows)。
shared-memory-base-name = name 给共享内存块起一个名字(默认的名字是MySQL)。
skip-grant-tables 不使用mysql数据库里的信息来进行访问控制(警告:这将允许用户任何用户去修改任何数据库)。
skip-host-cache 不使用高速缓存区来存放主机名和IP地址的对应关系。
skip-name-resovle 不把IP地址解析为主机名; 与访问控制(mysql.user数据表)有关的检查全部通过IP地址行进。
skip-networking 只允许通过一个套接字文件(Unix/Linux系统)或通过命名管道(Windows系统)进行本地连接,不允许ICP/IP连接; 这提高了安全性,但阻断了来自网络的外部连接和所有的Java客户程序(Java客户即使在本地连接里也使用TCP/IP)。
user = name mysqld程序在启动后将在给定UNIX/Linux账户下执行; mysqld必须从root账户启动才能在启动后切换到另一个账户下执行; mysqld_safe脚本将默认使用–user=mysql选项来启动mysqld程序。

 

mysqld程序:内存管理、优化、查询缓存区

bulk_insert_buffer_size = n 为一次插入多条新记录的INSERT命令分配的缓存区长度(默认设置是8M)。
key_buffer_size = n 用来存放索引区块的RMA值(默认设置是8M)。
join_buffer_size = n 在参加JOIN操作的数据列没有索引时为JOIN操作分配的缓存区长度(默认设置是128K)。
max_heap_table_size = n HEAP数据表的最大长度(默认设置是16M); 超过这个长度的HEAP数据表将被存入一个临时文件而不是驻留在内存里。
max_connections = n MySQL服务器同时处理的数据库连接的最大数量(默认设置是100)。
query_cache_limit = n 允许临时存放在查询缓存区里的查询结果的最大长度(默认设置是1M)。
query_cache_size = n 查询缓存区的最大长度(默认设置是0,不开辟查询缓存区)。
query_cache_type = 0/1/2 查询缓存区的工作模式:0, 禁用查询缓存区; 1,启用查询缓存区(默认设置); 2,”按需分配”模式,只响应SELECT SQL_CACHE命令。
read_buffer_size = n 为从数据表顺序读取数据的读操作保留的缓存区的长度(默认设置是128KB); 这个选项的设置值在必要时可以用SQL命令SET SESSION read_buffer_size = n命令加以改变。
read_rnd_buffer_size = n 类似于read_buffer_size选项,但针对的是按某种特定顺序(比如使用了ORDER BY子句的查询)输出的查询结果(默认设置是256K)。
sore_buffer = n 为排序操作分配的缓存区的长度(默认设置是2M); 如果这个缓存区太小,则必须创建一个临时文件来进行排序。
table_cache = n 同时打开的数据表的数量(默认设置是64)。
tmp_table_size = n 临时HEAP数据表的最大长度(默认设置是32M); 超过这个长度的临时数据表将被转换为MyISAM数据表并存入一个临时文件。

 

mysqld程序:日志

log [= file] 把所有的连接以及所有的SQL命令记入日志(通用查询日志); 如果没有给出file参数,MySQL将在数据库目录里创建一个hostname.log文件作为这种日志文件(hostname是服务器的主机名)。
log-slow-queries [= file] 把执行用时超过long_query_time变量值的查询命令记入日志(慢查询日志); 如果没有给出file参数,MySQL将在数据库目录里创建一个hostname-slow.log文件作为这种日志文件(hostname是服务器主机 名)。
long_query_time = n 慢查询的执行用时上限(默认设置是10s)。
long_queries_not_using_indexs 把慢查询以及执行时没有使用索引的查询命令全都记入日志(其余同–log-slow-queries选项)。
log-bin [= filename] 把对数据进行修改的所有SQL命令(也就是INSERT、UPDATE和 DELETE命令)以二进制格式记入日志(二进制变更日志,binary update log)。这种日志的文件名是filename.n或默认的hostname.n,其中n是一个6位数字的整数(日志文件按顺序编号)。
log-bin-index = filename 二进制日志功能的索引文件名。在默认情况下,这个索引文件与二进制日志文件的名字相同,但后缀名是.index而不是.nnnnnn。
max_binlog_size = n 二进制日志文件的最大长度(默认设置是1GB)。在前一个二进制日志文件里的信息量超过这个最大长度之前,MySQL服务器会自动提供一个新的二进制日志文件接续上。
binlog-do-db = dbname 只把给定数 据库里的变化情况记入二进制日志文件,其他数据库里的变化情况不记载。如果需要记载多个数据库里的变化情况,就必须在配置文件使用多个本选项来设置,每个数据库一行。
binlog-ignore-db = dbname 不把给定数据库里的变化情况记入二进制日志文件。
sync_binlog = n 每经过n次日志写操作就把日志文件写入硬盘一次(对日志信息进行一次同步)。n=1是最安全的做法,但效率最低。默认设置是n=0,意思是由操作系统来负责二进制日志文件的同步工作。
log-update [= file] 记载出错情况的日志文件名(出错日志)。这种日志功能无法禁用。如果没有给出file参数,MySQL会使用hostname.err作为种日志文件的名字。

 

mysqld程序:镜像(主控镜像服务器)

server-id = n 给服务器分配一个独一无二的ID编号; n的取值范围是1~2的32次方启用二进制日志功能。
log-bin = name 启用二进制日志功能。这种日志的文件名是filename.n或默认的hostname.n,其中的n是一个6位数字的整数(日志文件顺序编号)。
binlog-do/ignore-db = dbname 只把给定数据库里的变化情况记入二进制日志文件/不把给定的数据库里的变化记入二进制日志文件。

 

mysqld程序:镜像(从属镜像服务器)

server-id = n 给服务器分配一个唯一的ID编号
log-slave-updates 启用从属服务器上的日志功能,使这台计算机可以用来构成一个镜像链(A->B->C)。
master-host = hostname 主控服务器的主机名或IP地址。如果从属服务器上存在mater.info文件(镜像关系定义文件),它将忽略此选项。
master-user = replicusername 从属服务器用来连接主控服务器的用户名。如果从属服务器上存在mater.info文件,它将忽略此选项。
master-password = passwd 从属服务器用来连接主控服务器的密码。如果从属服务器上存在mater.info文件,它将忽略此选项。
master-port = n 从属服务器用来连接主控服务器的TCP/IP端口(默认设置是3306端口)。
master-connect-retry = n 如果与主控服务器的连接没有成功,则等待n秒(s)后再进行管理方式(默认设置是60s)。如果从属服务器存在mater.info文件,它将忽略此选项。
master-ssl-xxx = xxx 对主、从服务器之间的SSL通信进行配置。
read-only = 0/1 0: 允许从属服务器独立地执行SQL命令(默认设置); 1: 从属服务器只能执行来自主控服务器的SQL命令。
read-log-purge = 0/1 1: 把处理完的SQL命令立刻从中继日志文件里删除(默认设置); 0: 不把处理完的SQL命令立刻从中继日志文件里删除。
replicate-do-table = dbname.tablename 与–replicate-do-table选项的含义和用法相同,但数据库和数据库表名字里允许出现通配符”%” (例如: test%.%–对名字以”test”开头的所有数据库里的所以数据库表进行镜像处理)。 
replicate-do-db = name 只对这个数据库进行镜像处理。
replicate-ignore-table = dbname.tablename 不对这个数据表进行镜像处理。
replicate-wild-ignore-table = dbn.tablen 不对这些数据表进行镜像处理。
replicate-ignore-db = dbname 不对这个数据库进行镜像处理。
replicate-rewrite-db = db1name > db2name 把主控数据库上的db1name数据库镜像处理为从属服务器上的db2name数据库。
report-host = hostname 从属服务器的主机名; 这项信息只与SHOW SLAVE HOSTS命令有关–主控服务器可以用这条命令生成一份从属服务器的名单。
slave-compressed-protocol = 1 主、从服务器使用压缩格式进行通信–如果它们都支持这么做的话。
slave-skip-errors = n1, n2, …或all 即使发生出错代码为n1、n2等的错误,镜像处理工作也继续进行(即不管发生什 么错误,镜像处理工作也继续进行)。如果配置得当,从属服务器不应 该在执行 SQL命令时发生错误(在主控服务器上执行出错的SQL命令不会被发送到从属服务器上做镜像处理); 如果不使用slave-skip-errors选项,从属服务器上的镜像工作就可能因为发生错误而中断,中断后需要有人工参与才能继续进行。

 

mysqld–InnoDB:基本设置、表空间文件

skip-innodb 不加载InnoDB数据表驱动程序–如果用不着InnoDB数据表,可以用这个选项节省一些内存。
innodb-file-per-table 为每一个新数据表创建一个表空间文件而不是把数据表都集中保存在中央表空间里(后者是默认设置)。该选项始见于MySQL 4.1。
innodb-open-file = n InnoDB数据表驱动程序最多可以同时打开的文件数(默认设置是300)。如果使用了innodb-file-per-table选项并且需要同时打开很多数据表的话,这个数字很可能需要加大。
innodb_data_home_dir = p InnoDB主目录,所有与InnoDB数据表有关的目录或文件路径都相对于这个路径。在默认的情况下,这个主目录就是MySQL的数据目录。
innodb_data_file_path = ts 用来容纳InnoDB为数据表的表空间: 可能涉及一个以上的文件; 每一个表空间文件的最大长度都必须以字节(B)、兆字节(MB)或千兆字节(GB)为单位给出; 表空间文件的名字必须以分号隔开; 最后一个表空间文件还可以带一个autoextend属性和一个最大长度(max:n)。例如,ibdata1:1G; ibdata2:1G:autoextend:max:2G的意思是: 表空间文件ibdata1的最大长度是1GB,ibdata2的最大长度也是1G,但允许它扩充到2GB。除文件名外,还可以用硬盘分区的设置名来定义表 空间,此时必须给表空间的最大初始长度值加上newraw关键字做后缀,给表空间的最大扩充长度值加上raw关键字做后缀(例如/dev/hdb1: 20Gnewraw或/dev/hdb1:20Graw); MySQL 4.0及更高版本的默认设置是ibdata1:10M:autoextend。
innodb_autoextend_increment = n 带有autoextend属性的表空间文件每次加大多少兆字节(默认设置是8MB)。这个属性不涉及具体的数据表文件,那些文件的增大速度相对是比较小的。
innodb_lock_wait_timeout = n 如果某个事务在等待n秒(s)后还没有获得所需要的资源,就使用ROLLBACK命令放弃这个事务。这项设置对于发现和处理未能被InnoDB数据表驱动 程序识别出来的死锁条件有着重要的意义。这个选项的默认设置是50s。
innodb_fast_shutdown 0/1 是否以最快的速度关闭InnoDB,默认设置是1,意思是不把缓存在 INSERT缓存区的数据写入数据表,那些数据将在MySQL服务器下次启动 时再写入 (这么做没有什么风险,因为INSERT缓存区是表空间的一个组成部分,数据不会丢失)。把这个选项设置为0反面危险,因为在计算机关闭时,InnoDB 驱动程序很可能没有足够的时间完成它的数据同步工作,操作系统也许会在它完成数据同步工作之前强行结束InnoDB,而这会导致数据不完整。

 

mysqld程序:InnoDB–日志

innodb_log_group_home_dir = p 用来存放InnoDB日志文件的目录路径(如ib_logfile0、ib_logfile1等)。在默认的情况下,InnoDB驱动程序将使用 MySQL数据目录作为自己保存日志文件的位置。
innodb_log_files_in_group = n 使用多少个日志文件(默认设置是2)。InnoDB数据表驱动程序将以轮转方式依次填写这些文件; 当所有的日志文件都写满以后,之后的日志信息将写入第一个日志文件的最大长度(默认设置是5MB)。这个长度必须以MB(兆字节)或GB(千兆字节)为单 位进行设置。
innodb_flush_log_at_trx_commit = 0/1/2 这个选项决定着什么时候把日志信息写入日志文件以及什么时候把这些文件物理地写 (术语称为”同步”)到硬盘上。设置值0的意思是每隔一秒写一次日 志并进行 同步,这可以减少硬盘写操作次数,但可能造成数据丢失; 设置值1(设置设置)的意思是在每执行完一条COMMIT命令就写一次日志并进行同步,这可以防止数据丢失,但硬盘写操作可能会很频繁; 设置值2是一般折衷的办法,即每执行完一条COMMIT命令写一次日志,每隔一秒进行一次同步。
innodb_flush_method = x InnoDB日志文件的同步办法(仅适用于UNIX/Linux系统)。这个选项的可取值有两种: fdatasync,用fsync()函数进行同步; O_DSYNC,用O_SYNC()函数进行同步。
innodb_log_archive = 1 启用InnoDB驱动程序的archive(档案)日志功能,把日志信息写入ib_arch_log_n文件。启用这种日志功能在InnoDB与 MySQL一起使用时没有多大意义(启用MySQL服务器的二进制日志功能就足够用了)。

 

mysqld程序–InnoDB:缓存区的设置和优化

innodb_log_buffer_pool_size = n 为InnoDB数据表及其索引而保留的RAM内存量(默认设置是8MB)。这个参数对速度有着相当大的影响,如果计算机上只运行有 MySQL/InnoDB数据库服务器,就应该把全部内存的80%用于这个用途。 
innodb_log_buffer_size = n 事务日志文件写操作缓存区的最大长度(默认设置是1MB)。
innodb_additional_men_pool_size = n 为用于内部管理的各种数据结构分配的缓存区最大长度(默认设置是1MB)。
innodb_file_io_threads = n I/O操作(硬盘写操作)的最大线程个数(默认设置是4)。
innodb_thread_concurrency = n InnoDB驱动程序能够同时使用的最大线程个数(默认设置是8)。

 

mysqld程序:其它选项

bind-address = ipaddr MySQL服务器的IP地址。如果MySQL服务器所在的计算机有多个IP地址,这个选项将非常重要。
default-storage-engine = type 新数据表的默认数据表类型(默认设置是MyISAM)。这项设置还可以通过–default-table-type选项来设置。
default-timezone = name 为MySQL服务器设置一个地理时区(如果它与本地计算机的地理时区不一样)。
ft_min_word_len = n 全文索引的最小单词长度工。这个选项的默认设置是4,意思是在创建全文索引时不考虑那些由3个或更少的字符构建单词。
Max-allowed-packet = n 客户与服务器之间交换的数据包的最大长度,这个数字至少应该大于客户程序将要处理的最大BLOB块的长度。这个选项的默认设置是1MB。
Sql-mode = model1, mode2, … MySQL将运行在哪一种SQL模式下。这个选项的作用是让MySQL与其他的数据库系统保持最大程度的兼容。这个选项的可取值包括ansi、db2、 oracle、no_zero_date、pipes_as_concat。

 

注意:如果在配置文件里给出的某个选项是mysqld无法识别的,MySQL服务器将不启动。

2013 年 9 月 4 日Permalink Leave a comment

mysql日志设置优化

前言

在安装完MySQL之后,肯定是需要对MySQL的各种参数选项进行一些优化调整的。虽然MySQL系统的伸缩性很强,既可以在有很充足的硬件资源 环境下高效的运行,也可以在极少资源环境下很好的运行,但不管怎样,尽可能充足的硬件资源对MySQL的性能提升总是有帮助的。在这一节我们主要分析一下 MySQL的日志(主要是Binlog)对系统性能的影响,并根据日志的相关特性得出相应的优化思路。

 

日志产生的性能影响

由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。

在之前介绍MySQL物理架构的章节中,我们已经了解到了MySQL的日志包括错误日志(ErrorLog),更新日志(UpdateLog),二 进制日志(Binlog),查询日志(QueryLog),慢查询日志(SlowQueryLog)等。当然,更新日志是老版本的MySQL才有的,目前 已经被二进制日志替代。

在默认情况下,系统仅仅打开错误日志,关闭了其他所有日志,以达到尽可能减少IO损耗提高系统性能的目的。但是在一般稍微重要一点的实际应用场景 中,都至少需要打开二进制日志,因为这是MySQL很多存储引擎进行增量备份的基础,也是MySQL实现复制的基本条件。有时候为了进一步的性能优化,定 位执行较慢的SQL语句,很多系统也会打开慢查询日志来记录执行时间超过特定数值(由我们自行设置)的SQL语句。

一般情况下,在生产系统中很少有系统会打开查询日志。因为查询日志打开之后会将MySQL中执行的每一条Query都记录到日志中,会该系统带来比 较大的IO负担,而带来的实际效益却并不是非常大。一般只有在开发测试环境中,为了定位某些功能具体使用了哪些SQL语句的时候,才会在短时间段内打开该 日志来做相应的分析。所以,在MySQL系统中,会对性能产生影响的MySQL日志(不包括各存储引擎自己的日志)主要就是Binlog了。

 

Binlog 相关参数及优化策略

我们首先看看Binlog的相关参数,通过执行如下命令可以获得关于Binlog的相关参数。当然,其中也显示出了“innodb_locks_unsafe_for_binlog”这个Innodb存储引擎特有的与Binlog相关的参数:

复制代码
mysql> show variables like '%binlog%'; 
+--------------------------------+------------+ | Variable_name | Value | +--------------------------------+------------+ 
| binlog_cache_size | 1048576 | 
| innodb_locks_unsafe_for_binlog | OFF |
| max_binlog_cache_size| 4294967295 |
| max_binlog_size| 1073741824 |
| sync_binlog| 0|
+--------------------------------+------------+
复制代码

 

“binlog_cache_size”:在事务过程中容纳二进制日志SQL语句的缓存大小。二进制日志缓存是服务器支持事务存储引擎并且服务器启 用了二进制日志(—log-bin选项)的前提下为每个客户端分配的内存,注意,是每个Client都可以分配设置大小的binlogcache空间。如 果读者朋友的系统中经常会出现多语句事务的华,可以尝试增加该值的大小,以获得更有的性能。当然,我们可以通过MySQL的以下两个状态变量来判断当前的 binlog_cache_size的状况:Binlog_cache_use和Binlog_cache_disk_use。

“max_binlog_cache_size”:和”binlog_cache_size”相对应,但是所代表的是binlog能够使用的最大 cache内存大小。当我们执行多语句事务的时候,max_binlog_cache_size如果不够大的话,系统可能会报出“Multi- statementtransactionrequiredmorethan’max_binlog_cache_size’bytesofstorage” 的错误。

“max_binlog_size”:Binlog日志最大值,一般来说设置为512M或者1G,但不能超过1G。该大小并不能非常严格控制 Binlog大小,尤其是当到达Binlog比较靠近尾部而又遇到一个较大事务的时候,系统为了保证事务的完整性,不可能做切换日志的动作,只能将该事务 的所有SQL都记录进入当前日志,直到该事务结束。这一点和Oracle的Redo日志有点不一样,因为Oracle的Redo日志所记录的是数据文件的 物理位置的变化,而且里面同时记录了Redo和Undo相关的信息,所以同一个事务是否在一个日志中对Oracle来说并不关键。而MySQL在 Binlog中所记录的是数据库逻辑变化信息,MySQL称之为Event,实际上就是带来数据库变化的DML之类的Query语句。

“sync_binlog”:这个参数是对于MySQL系统来说是至关重要的,他不仅影响到Binlog对MySQL所带来的性能损耗,而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下:

sync_binlog=0,当事务提交之后,MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘,而让Filesystem自行决定什么时候来做同步,或者cache满了之后才同步到磁盘。

sync_binlog=n,当每进行n次事务提交之后,MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

在MySQL中系统默认的设置是sync_binlog=0,也就是不做任何强制性的磁盘刷新指令,这时候的性能是最好的,但是风险也是最大的。因 为一旦系统Crash,在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候,是最安全但是性能损耗最大的设置。因为 当设置为1的时候,即使系统Crash,也最多丢失binlog_cache中未完成的一个事务,对实际数据没有任何实质性影响。从以往经验和相关测试来 看,对于高并发事务的系统来说,“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

 

大家都知道,MySQL的复制(Replication),实际上就是通过将Master端的Binlog通过利用IO线程通过网络复制到 Slave端,然后再通过SQL线程解析Binlog中的日志再应用到数据库中来实现的。所以,Binlog量的大小对IO线程以及Msater和 Slave端之间的网络都会产生直接的影响。

MySQL中Binlog的产生量是没办法改变的,只要我们的Query改变了数据库中的数据,那么就必须将该Query所对应的Event记录到 Binlog中。那我们是不是就没有办法优化复制了呢?当然不是,在MySQL复制环境中,实际上是是有8个参数可以让我们控制需要复制或者需要忽略而不 进行复制的DB或者Table的,分别为:

Binlog_Do_DB:设定哪些数据库(Schema)需要记录Binlog;

Binlog_Ignore_DB:设定哪些数据库(Schema)不要记录Binlog;

Replicate_Do_DB:设定需要复制的数据库(Schema),多个DB用逗号(“,”)分隔;

Replicate_Ignore_DB:设定可以忽略的数据库(Schema);

Replicate_Do_Table:设定需要复制的Table;

Replicate_Ignore_Table:设定可以忽略的Table;

Replicate_Wild_Do_Table:功能同Replicate_Do_Table,但可以带通配符来进行设置;

Replicate_Wild_Ignore_Table:功能同Replicate_Ignore_Table,可带通配符设置;

 

通过上面这八个参数,我们就可以非常方便按照实际需求,控制从Master端到Slave端的Binlog量尽可能的少,从而减小Master端到 Slave端的网络流量,减少IO线程的IO量,还能减少SQL线程的解析与应用SQL的数量,最终达到改善Slave上的数据延时问题。

实际上,上面这八个参数中的前面两个是设置在Master端的,而后面六个参数则是设置在Slave端的。虽然前面两个参数和后面六个参数在功能上 并没有非常直接的关系,但是对于优化MySQL的Replication来说都可以启到相似的功能。当然也有一定的区别,其主要区别如下:

如果在Master端设置前面两个参数,不仅仅会让Master端的Binlog记录所带来的IO量减少,还会让Master端的IO线程就可以减 少Binlog的读取量,传递给Slave端的IO线程的Binlog量自然就会较少。这样做的好处是可以减少网络IO,减少Slave端IO线程的IO 量,减少Slave端的SQL线程的工作量,从而最大幅度的优化复制性能。当然,在Master端设置也存在一定的弊端,因为MySQL的判断是否需要复 制某个Event不是根据产生该Event的Query所更改的数据

 

所在的DB,而是根据执行Query时刻所在的默认Schema,也就是我们登录时候指定的DB或者运行“USEDATABASE”中所指定的 DB。只有当前默认DB和配置中所设定的DB完全吻合的时候IO线程才会将该Event读取给Slave的IO线程。所以如果在系统中出现在默认DB和设 定需要复制的DB不一样的情况下改变了需要复制的DB中某个Table的数据的时候,该Event是不会被复制到Slave中去的,这样就会造成 Slave端的数据和Master的数据不一致的情况出现。同样,如果在默认Schema下更改了不需要复制的Schema中的数据,则会被复制到 Slave端,当Slave端并没有该Schema的时候,则会造成复制出错而停止。

而如果是在Slave端设置后面的六个参数,在性能优化方面可能比在Master端要稍微逊色一点,因为不管是需要还是不需要复制的Event都被 会被IO线程读取到Slave端,这样不仅仅增加了网络IO量,也给Slave端的IO线程增加了RelayLog的写入量。但是仍然可以减少Slave 的SQL线程在Slave端的日志应用量。虽然性能方面稍有逊色,但是在Slave端设置复制过滤机制,可以保证不会出现因为默认Schema的问题而造 成Slave和Master数据不一致或者复制出错的问题。

 

Slow Query Log 相关参数及使用建议

再来看看SlowQueryLog的相关参数配置。有些时候,我们为了定位系统中效率比较地下的Query语句,则需要打开慢查询日志,也就是SlowQueryLog。我们可以如下查看系统慢查询日志的相关设置:

复制代码
mysql> show variables like 'log_slow%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| log_slow_queries | ON |
+------------------+-------+
1 row in set (0.00 sec)

mysql> show variables like 'long_query%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| long_query_time | 1 |
+-----------------+-------+
1 row in set (0.01 sec)
复制代码

 

“log_slow_queries”参数显示了系统是否已经打开SlowQueryLog功能,而“long_query_time”参数则告诉 我们当前系统设置的SlowQuery记录执行时间超过多长的Query。在MySQLAB发行的MySQL版本中SlowQueryLog可以设置的最 短慢查询时间为1秒,这在有些时候可能没办法完全满足我们的要求,如果希望能够进一步缩短慢查询的时间限制,可以使用Percona提供的 microslow-patch(件成为mslPatch)来突破该限制。mslpatch不仅仅能将慢查询时间减小到毫秒级别,同时还能通过一些特定的 规则来过滤记录的SQL,如仅记录涉及到某个表的SlowQuery等等附加功能。考虑到篇幅问题,这里就不介绍mslpatch给我们带来的更为详细的 功能和使用,大家请参考官方介绍(http://www.mysqlperformanceblog.com/2008/04/20/updated- msl-microslow-patch-installation-walk-through/)

打开SlowQueryLog功能对系统性能的整体影响没有Binlog那么大,毕竟SlowQueryLog的数据量比较小,带来的IO损耗也就 较小,但是,系统需要计算每一条Query的执行时间,所以消耗总是会有一些的,主要是CPU方面的消耗。如果大家的系统在CPU资源足够丰富的时候,可 以不必在乎这一点点损耗,毕竟他可能会给我们带来更大性能优化的收获。但如果我们的CPU资源也比较紧张的时候,也完全可以在大部分时候关闭该功能,而只 需要间断性的打开SlowQueryLog功能来定位可能存在的慢查询。

MySQL的其他日志由于使用很少(QueryLog)或者性能影响很少,我们就不在此过多分析了,至于各个存储引擎相关的日志,我们留在后面“常用存储引擎优化”部分再做相应的分析。

 

转自 《MySQL性能调优与架构设计》

2013 年 9 月 4 日Permalink Leave a comment

泡茶

刚才在办公室烧开水喝,茶叶泡完了问一女同事:美女,有啥可以冲着喝的没?妹纸从抽屉拿出一个粉红色的小袋:你运气真好,最后一袋了。边称谢一边拿过来就 撕开包装,正要往杯子里倒时一看名称觉得不对:月月舒痛经宝颗粒,月月舒,舒……回头一看,那女同事和一众围观的2货们都笑趴在桌子上乐……

2012 年 10 月 30 日Permalink Leave a comment

内急时的走与跑

一天,小李在逛街时,突然感到内急,便捂着肚子去找公厕。找了好一会儿,终于远远地看见一个,于是小李就一路小跑冲了过去。小李见负责收费的大爷坐在门口,便问道:“大爷,多少钱?”大爷回答说:“1块。”小李不解地问:“刚才那人怎么交了5毛钱就进去了?”大爷答道:“因为那人是走着过来的,你是跑着过来的。”

2012 年 9 月 29 日Permalink Leave a comment

长得像陈坤的经理

公司新调来一经理,长的特像陈坤,今天第一天上班,我们一块上电梯,本着和领导套近乎,就想赞扬他一把. 我:哎呀经理,你长的太像那个明星了,叫叫什么来着(确实想不起来了),对了就是演画皮的那个?叫什么来?看我急的那样, 他笑着说:陈坤。我来了一句:对对对,就是那个SB!

2012 年 8 月 24 日Permalink Leave a comment

Firefox 浏览器假死或崩溃问题解决

最近在新版本Firefox浏览器使用过程中会出现卡死或崩溃的现象,所有按键无效,页面卡住不动,进程中出现多个plugin-container进程,只有强制关闭这些进程浏览器才能继续使用。因plugin-container是插件进程,经排查,发现是因为升级flash插件到11.3版本导致的,flash 11.3目前与Firefox是冲突的,只要打开含有flash的网页浏览器就会出现假死或崩溃的现象,重新安装11.2版本的flash 插件便可解决该问题。

2012 年 8 月 22 日Permalink Leave a comment

城管买早餐

早市上卖早点的看见带有“行政执法”的车开了过来,大家马上四散跑开。车停了,车上下来两个人,无奈的互相看了一眼,其中一个说:“我说不开车吧!你非要开,看看,又没买到早餐!”

2012 年 8 月 16 日Permalink Leave a comment

人质

妻子外出讨债,几个月后却空手而归。老公骂道:“你真无能!”妻子不服地说:“我虽然没有要到钱,但老板的孩子被我当了人质!”老公大喜,问道:“人呢?”妻子一拍肚子,说:“关在里面了”

2012 年 8 月 9 日Permalink Leave a comment