MySQL高性能以及高安全测试

1.  参数描述

sync_binlog


Command-Line Format


--sync-binlog=#


Option-File Format


sync_binlog


System Variable Name


sync_binlog


Variable Scope


Global


Dynamic Variable


Yes


Permitted Values


Platform Bit Size


32


Type


numeric


Default


0


Range


0 .. 4294967295


Permitted Values


Platform Bit Size


64


Type


numeric


Default


0


Range


0 .. 18446744073709547520

  1. If the value of this variable is greater than 0, the MySQL server synchronizes its binary log to disk (using fdatasync()) after sync_binlog commit groups are written to the binary log. The default value of sync_binlog is 0, which does no synchronizing to disk—in this case, the server relies on the operating system to flush the binary log‘s contents from time to time as for any other file. A value of 1 is the safest choice because in the event of a crash you lose at most one commit group from the binary log. However, it is also the slowest choice (unless the disk has a battery-backed cache, which makes synchronization very fast).

sync_binlog参数说明:

当sync_binlog是控制事务写入二进制日志的方式。如果设置大于0,则达到sync_binlog设置的值一组事务同步写入到二进制日志;如果设置为0,则每当事务发生,在内存中的事务信息,不是同步刷到磁盘,而是依赖于操作系统时常刷新到磁盘;当设置为1,则是更安全的选项,当宕机后,最多失去1个事务的信息,但是性能确实最慢的。

innodb_flush_log_at_trx_commit


Command-Line Format


--innodb_flush_log_at_trx_commit[=#]


Option-File Format


innodb_flush_log_at_trx_commit


System Variable Name


innodb_flush_log_at_trx_commit


Variable Scope


Global


Dynamic Variable


Yes


Permitted Values


Type


enumeration


Default


1


Valid Values


0


1


2

Controls the balance between strict ACID compliance for commit operations, and higher performance that is possible when commit-related I/O operations are rearranged and done in batches. You can achieve better performance by changing the default value, but then you can lose up to one second worth of transactions in a crash.

  • The default value of 1 is required for full ACID compliance. With this value, the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file.
  • With a value of 0, any mysqld process crash can erase up to a second of transactions. The log buffer is written out to the log file once per second and the flush to disk operation is performed on the log file. No writes from the log buffer to the log file are performed at transaction commit. Once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues.
  • With a value of 2, any mysqld process crash can erase up to a second of transactions. The log buffer is written out to the log file at each commit. The flush to disk operation is performed on the log file once per second. Once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues.
  • As of MySQL 5.6.6, InnoDB log flushing frequency is controlled by innodb_flush_log_at_timeout, which allows you to set log flushing frequency to N seconds (where Nis 1 ... 2700, with a default value of 1). However, any mysqld process crash can erase up to N seconds of transactions.
  • DDL changes and other internal InnoDB activities flush the InnoDB log independent of the innodb_flush_log_at_trx_commit setting.
  • InnoDB‘s crash recovery works regardless of the innodb_flush_log_at_trx_commit setting. Transactions are either applied entirely or erased entirely.

For durability and consistency in a replication setup that uses InnoDB with transactions:

  • If binary logging is enabled, set sync_binlog=1.
  • Always set innodb_flush_log_at_trx_commit=1.

Caution

Many operating systems and some disk hardware fool the flush-to-disk operation. They may tell mysqld that the flush has taken place, even though it has not. Then the durability of transactions is not guaranteed even with the setting 1, and in the worst case a power outage can even corrupt InnoDBdata. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer. You can also try using the Unix command hdparm to disable the caching of disk writes in hardware caches, or use some other command specific to the

innodb_flush_log_at_trx_commit参数说明:

innodb_flush_log_at_trx_commit=1,完全尊周ACID事务的原则,每提交一次,log buffer中的日志刷新到log file的文件缓存,然后在刷新到磁盘。这种的性能最差。当innodb_flush_log_at_trx_commit=0的时候,当mysqld宕掉的时候,会丢失一秒的事务,每1秒log buffer中的日志会先写到log file的文件缓存,然后通过操作系统调度,时常刷新到磁盘。当为innodb_flush_log_at_trx_commit=2,会丢失一秒的事务,每次提交log buffer的日志会写到日志文件缓存,日志文件缓存中的日志刷新到磁盘则是每秒钟发生。

2. 测试信息

2.1高性能


参数



Sync_binlog


100


Innodb_flush_log_at_trx_commit


2


Innodb_buffer_pool_size


3.5G


Innodb_log_file_size


300

此次插入4247160条记录,花了时间大概为244秒。

2.2高安全


参数



Sync_binlog


1


Innodb_flush_log_at_trx_commit


1


Innodb_buffer_pool_size


3.5G


Innodb_log_file_size


300

插入4247160条记录花了290秒。不同的参数配置插入相同数据量,相差了46秒的时间。

2.3     测试脚本

3.  测试信息

3.1 sync_binlog行为

相关的文件以及函数:

源文件:/sql/binlog.cc

相关函数:

std::pair<bool, bool> sync_binlog_file(bool force);

int ordered_commit(THD *thd, bool all, bool skip_commit = false);

时间: 2024-08-26 17:08:47

MySQL高性能以及高安全测试的相关文章

Mysql高性能优化规范建议

原文:Mysql高性能优化规范建议 数据库命令规范 所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库对象名称禁止使用mysql保留关键字(如果表名中包含关键字查询时,需要将其用单引号括起来) 数据库对象的命名要能做到见名识意,并且最后不要超过32个字符 临时库表必须以tmp_为前缀并以日期为后缀,备份表必须以bak_为前缀并以日期(时间戳)为后缀 所有存储相同数据的列名和列类型必须一致(一般作为关联列,如果查询时关联列类型不一致会自动进行数据类型隐式转换,会造成列上的索引失效,导致查

java架构师、高性能、高并发、高可用、高可扩展、性能优化、集群、电商网站架构

15套java架构师.集群.高可用.高可扩展.高性能.高并发.性能优化.Spring boot.Redis.ActiveMQ.Nginx.Mycat.Netty.Jvm大型分布式项目实战视频教程 视频课程内容包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Redis.ActiveMQ.Nginx.Mycat.Spring.MongoDB.ZeroMQ.Git.Nosql.Jvm.Mecached.Netty.Nio.Mina.性能调优.高并发.to

基于NFS共享的Mysql之HA高可用集群实现

192.168.139.8 作为NFS-Server ,192.168.139.2和192.168.13.4用来安装mysql ___________________________________________________________________________________________以下操作在192.168.139.8上操作 [[email protected] ~]# fdisk -l //首先要准备一块磁盘进行分区,用来做lv,再将此lv格式化后挂载并      

基于CentOS 5.4搭建nginx+php+spawn-fcgi+mysql高性能php平台

一.安装准备 1.1平台环境: CentOS 5.4 x86_64 GNU/Linux nginx-0.8.21 php-5.2.9 spawn-fcgi-1.6.3 mysql-5.1.34 .2系统安装及分区:1.2.1操作系统安装:         安装过程中选择最少的包,采用文本模式安装,不安装图形.1.2.3系统分区:         /boot  100M    (大约100左右)          SWAP  4G      物理内存的2倍(如果你的物理内存大于4G,分配4G即可)

MariaDB Galera Cluster环境搭建及高可用测试

一.服务器概况Galera Cluster需要至少三个节点,在此次实验过程中,三个节点IP地址:192.168.56.101192.168.56.102192.168.56.103OS为centos 7.2服务器配置:4G 内存,2核CPU,20G数据磁盘空间. 关闭防火墙: service iptables stop systemctl stop firewalld chkconfig iptables off 关闭SELinux: /etc/selinux/config中的SELINUX=d

高性能、高可用的分布式架构体系(转)

在2B企业服务.云计算.移动互联网领域,专业的云平台服务里,分布式技术为支撑平台正常运作关键性技术.从商业利润和运维成本角度出发,千方百计榨干服务器的每一分性能很大程度上影响着网站的商业价值,因此对性能的追求,成为分布式架构体系中极为重要的考量指标:从用户角度,特别是作为主要收入来源的企业用户的角度出发,保证业务处理的正确性和服务不中断(高可用性)是支撑用户信心的重要来源.高性能,高可用,正确性成为分布式架构体系的关键技术因素. 对于网站产品的的架构体系,可以选择开源或自主研发:如果拥抱开源,则

非常不错的文章,囊括啦高性能、高可用的分布式架构体系所有名词

在2B企业服务.云计算.移动互联网领域,专业的云平台服务里,分布式技术为支撑平台正常运作关键性技术.从商业利润和运维成本角度出发,千方百计榨干服务器的每一分性能很大程度上影响着网站的商业价值,因此对性能的追求,成为分布式架构体系中极为重要的考量指标:从用户角度,特别是作为主要收入来源的企业用户的角度出发,保证业务处理的正确性和服务不中断(高可用性)是支撑用户信心的重要来源.高性能,高可用,正确性成为分布式架构体系的关键技术因素. 对于网站产品的的架构体系,可以选择开源或自主研发:如果拥抱开源,则

MySQL集群(四)之keepalived实现mysql双主高可用

前面大家介绍了主从.主主复制以及他们的中间件mysql-proxy的使用,这一篇给大家介绍的是keepalived的搭建与使用! 一.keepalived简介 1.1.keepalived介绍 Keepalived起初是为LVS设计的,专门用来监控集群系统中各个服务节点的状态,它根据TCP/IP参考模型的第三.第四层.第五层交换机制检测每个服务节点的状态,如果某个服务器节点出现异常, 或者工作出现故障,Keepalived将检测到,并将出现的故障的服务器节点从集群系统中剔除,这些工作全部是自动完

Heartbeat+MySQL+NFS 实现高可用(HA)的MySQL集群

一:试验目的 利用heartbeat心跳机制haresource实现高可用(HA)mysql数据库的搭建. 二:试验拓扑图 三:安装前的环境准备 规划IP为192.168.1.14为node1;IP为192.168.1.2为node2 1)修改各主机名称 修改node1主机名称  vim /etc/sysconfig/network   NETWORKING=yes   HOSTNAME=node1 #修改主机名称为node1  vim /etc/hosts     192.168.1.2 no