MySQL高效能以及高安全性測試

來源:互聯網
上載者:User

標籤:

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);

 

MySQL高效能以及高安全性測試

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.