mysql的日誌種類有不少,常見的有二進制日誌,通常查詢日誌,滿查詢日誌,中繼日誌,事務日誌等,具體信息能夠經過 mysql> SHOW GLOBAL VARIABLES LIKE '%log%'; 查看,在個人機器上結果以下:mysql
+-----------------------------------------+--------------------------------+ | Variable_name | Value | +-----------------------------------------+--------------------------------+ | back_log | 80 | | binlog_cache_size | 32768 | | binlog_checksum | CRC32 | | binlog_direct_non_transactional_updates | OFF | | binlog_error_action | IGNORE_ERROR | | binlog_format | MIXED | | binlog_gtid_simple_recovery | OFF | | binlog_max_flush_queue_time | 0 | | binlog_order_commits | ON | | binlog_row_image | FULL | | binlog_rows_query_log_events | OFF | | binlog_stmt_cache_size | 32768 | | binlogging_impossible_mode | IGNORE_ERROR | | expire_logs_days | 0 | | general_log | OFF | | general_log_file | /var/lib/mysql/master.log | | innodb_api_enable_binlog | OFF | | innodb_flush_log_at_timeout | 1 | | innodb_flush_log_at_trx_commit | 1 | | innodb_locks_unsafe_for_binlog | OFF | | innodb_log_buffer_size | 8388608 | | innodb_log_compressed_pages | ON | | innodb_log_file_size | 50331648 | | innodb_log_files_in_group | 2 | | innodb_log_group_home_dir | ./ | | innodb_mirrored_log_groups | 1 | | innodb_online_alter_log_max_size | 134217728 | | innodb_undo_logs | 128 | | log_bin | ON | | log_bin_basename | /var/log/mysql/mysql-bin | | log_bin_index | /var/log/mysql/mysql-bin.index | | log_bin_trust_function_creators | OFF | | log_bin_use_v1_row_events | OFF | | log_error | /var/log/mysql/error.log | | log_output | FILE | | log_queries_not_using_indexes | OFF | | log_slave_updates | OFF | | log_slow_admin_statements | OFF | | log_slow_slave_statements | OFF | | log_throttle_queries_not_using_indexes | 0 | | log_warnings | 1 | | max_binlog_cache_size | 18446744073709547520 | | max_binlog_size | 104857600 | | max_binlog_stmt_cache_size | 18446744073709547520 | | max_relay_log_size | 0 | | relay_log | | | relay_log_basename | | | relay_log_index | | | relay_log_info_file | relay-log.info | | relay_log_info_repository | FILE | | relay_log_purge | ON | | relay_log_recovery | OFF | | relay_log_space_limit | 0 | | simplified_binlog_gtid_recovery | OFF | | slow_query_log | OFF | | slow_query_log_file | /var/lib/mysql/master-slow.log | | sql_log_bin | ON | | sql_log_off | OFF | | sync_binlog | 0 | | sync_relay_log | 10000 | | sync_relay_log_info | 10000 | +-----------------------------------------+--------------------------------+ 61 rows in set (0.00 sec)
其中binlog_format字段是指二進制日誌的類型,分爲3種:一、基於語句(statement) 二、基於行(row) 三、混合方式 。基於語句和基於行各有優劣,若是制定的是基於語句,那麼若是sql語句中有相似date的指令,那麼在備份的時候就會產生錯誤。而基於行的會形成日誌文件過大。二進制日誌會記錄任何引發數據庫變化和可能引發數據庫變化的操做。顧名思義二進制日誌的文件類型是二進制的,所以不能用打開ASCII文件的方式打開,用 file mysql-bin.000001 查看二進制日誌的類型是 mysql-bin.000001:MySQL replication log 若是用cat,less等命令打開會是亂碼,必須用 $mysqlbinlog mysql-bin.000001 查看,纔會獲得具體的日誌信息,部分結果以下:linux
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!40019 SET @@session.max_insert_delayed_threads=0*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #160411 8:13:40 server id 1 end_log_pos 120 CRC32 0xd41ad4d6 Start: binlog v 4, server v 5.6.28-1-log created 160411 8:13:40 at startup # Warning: this binlog is either in use or was not closed properly. ROLLBACK/*!*/; BINLOG ' NOwKVw8BAAAAdAAAAHgAAAABAAQANS42LjI4LTEtbG9nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA07ApXEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAdbU GtQ= '/*!*/; # at 120 #160411 9:47:59 server id 1 end_log_pos 221 CRC32 0x26bc23ca Query thread_id=7 exec_time=1 error_code=0 SET TIMESTAMP=1460339279/*!*/; SET @@session.pseudo_thread_id=7/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1073741824/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; drop database article /*!*/; # at 221 #160411 9:49:41 server id 1 end_log_pos 324 CRC32 0x69a849f1 Query thread_id=9 exec_time=0 error_code=0 SET TIMESTAMP=1460339381/*!*/; create database article /*!*/; # at 324 #160411 9:50:10 server id 1 end_log_pos 461 CRC32 0x7b2ad848 Query thread_id=10 exec_time=0 error_code=0 use `article`/*!*/; SET TIMESTAMP=1460339410/*!*/; SET @@session.foreign_key_checks=0, @@session.unique_checks=0/*!*/; SET @@session.sql_mode=524288/*!*/; DROP TABLE IF EXISTS `at_admin` /* generated by server */ /*!*/;
這裏面無非就是記錄的一些sql腳本,可是mysql的二進制日誌對於數據庫的複製和及時點恢復相當重要,在生產環境中必定要將二進制日誌和數據文件存放在兩塊不一樣的硬盤上,一旦數據文件所在的硬盤損壞就能夠經過二進制日誌備份還原,還有一個緣由是二進制日誌和數據庫數據文件都會引發大量IO操做,若是二者放在同一塊磁盤上那麼io量就會變得很是大,引發系統性能降低。除了在終端使用mysqlbinlog查看二進制日誌,還能夠在mysql交互式模式中使用一系列命令查看和二進制日誌相關的信息。sql
mysql>show binary logs; 查看系統當前有哪些二進制日誌文件名
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 423 |
| mysql-bin.000002 | 2811 |
+------------------+-----------+
2 rows in set (0.00 sec)數據庫
mysql> show master status; 查看當前記錄二進制日誌文件的狀態 +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000002 | 2811 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)
mysql> show binlog events in 'mysql-bin.000001'; 查看某個二進制日誌文件的內容 \G可選,可讓結果以垂直的方式顯示 +------------------+-----+-------------+-----------+-------------+---------------------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+-----+-------------+-----------+-------------+---------------------------------------------------------------------+ | mysql-bin.000001 | 4 | Format_desc | 1 | 120 | Server ver: 5.6.28-1-log, Binlog ver: 4 | | mysql-bin.000001 | 120 | Query | 1 | 205 | BEGIN | | mysql-bin.000001 | 205 | Intvar | 1 | 237 | INSERT_ID=6 | | mysql-bin.000001 | 237 | Query | 1 | 369 | use `article`; insert into at_type (typename) values ('pt'),('ll') | | mysql-bin.000001 | 369 | Xid | 1 | 400 | COMMIT /* xid=24 */ | | mysql-bin.000001 | 400 | Stop | 1 | 423 | | +------------------+-----+-------------+-----------+-------------+---------------------------------------------------------------------+ 6 rows in set (0.00 sec)
expire_logs_days是指日誌過時時間,通常要設定爲0,若是設定爲30,那麼30天以後全部日誌將被自動清空,而二進制日誌對於數據庫恢復是很重要的,不能清除。api
general_log字段的值通常設爲OFF關閉,若是開啓普通查詢日誌,則用戶的每一條查詢語句都將被記錄下來,這將產生大量磁盤IO,而凡是產生IO的地方都會影響系統系統。IOPS用來衡量一個IO設備每秒鐘執行IO操做的次數,普通臺式機機械硬盤的iops是100,SCSI硬盤的iops能達到200,而SSD的iops可能會達到500---1000不等,所以在生產環境中一個繁忙的數據庫服務器通常都要使用SSD提升性能。二進制日誌文件頗有可能成爲整個系統的瓶頸,所以最好把數據庫的二進制日誌文件單獨放到一塊SSD上,按期轉移。服務器
innodb_flush_log_at_trx_commit 有3個可選的值,0:每秒同步,並執行磁盤flush操做 1:每事務同步,並執行磁盤flush操做 2:每事務同步,但不執行磁盤flush操做,由操做系統選擇空閒的時間將內存中的數據同步至磁盤。 session
mysql的備份按是否可讀寫,分爲3種,1.熱備份:備份的同時讀寫不受影響. 2.溫備份:備份的同時僅能夠執行讀操做 3.冷備份:也稱離線備份,必須終止一切讀寫操做才能開始備份. 另外一種劃分方式是按照備份文件的類型分爲物理備份和邏輯備份,物理備份都是直接備份數據文件,而邏輯備份會產生一堆sql腳本,速度慢並且可能會丟失浮點數精度,可是很方便採用文本處理工具對其處理.不一樣的數據庫存儲引擎支持的備份方法也不一樣,MyISAM存儲引擎僅支持溫備份,InnoDB引擎支持熱備份和冷備份.less
備份的工具也有不少,mysql自帶的mysqldump能夠進行邏輯備份,percona提供了遵循GPL協議的開源備份工具xtrabackup,功能十分強大,官網有詳細的文檔介紹,percona爲了mysql提供了不少開源的技術支持,發佈了不少mysql管理工具.直接用cp命令也能夠備份,可是這樣只能冷備份了,用邏輯卷lv能夠實現幾乎熱備份的效果
工具
下面介紹一下mysqldump 的使用,詳細的使用方法能夠man一下.在使用mysqldump進行邏輯備份前最好鎖表,操做結束後性能
mysql > flush tables with read lock; mysql > flush logs
msyql > unlock tables;
再釋放鎖,或者直接加上--lock-alltables,--flush-logs執行日誌滾動,--all-databases 備份全部庫,--databases db1, db2,......備份制定的庫,--master-data={0,1,2} ,這裏水平所限,僅介紹mysqldump,xtrabackup這個強大的工具如何使用仍是看官方文檔吧.
一些example:
1. mysqldump -u root -p --lock-all-tables --flush-logs --master-data=2 --all-databases > ~/all.sql
Warning: Using unique option prefix all-tables instead of all-tablespaces is deprecated and will be removed in a future release. Please use the full name instead.
2. mysqldump -u root -p --lock-all-tables --flush-logs --master-data=2 --database article > ~/article.sql
第一步:備份數據庫至~/article.sql,article.sql打開就是一堆sql 腳本,部份內容以下:
$ cat article.sql -- MySQL dump 10.13 Distrib 5.6.28, for debian-linux-gnu (x86_64) -- -- Host: localhost Database: article -- ------------------------------------------------------ -- Server version 5.6.28-1-log /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SET TIME_ZONE='+00:00' */; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */; -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=120; -- -- Current Database: `article` -- CREATE DATABASE /*!32312 IF NOT EXISTS*/ `article` /*!40100 DEFAULT CHARACTER SET latin1 */; USE `article`; -- -- Table structure for table `at_admin` -- DROP TABLE IF EXISTS `at_admin`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `at_admin` ( `id` int(5) NOT NULL AUTO_INCREMENT, `name` varchar(40) DEFAULT NULL, `passwd` varchar(40) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; /*!40101 SET character_set_client = @saved_cs_client */;
第二步:模擬數據庫損壞 mysql> drop databse article
第三部:恢復數據庫:恢復以前必定要在當前會話中關閉數據庫的二進制日誌功能,由於他會把恢復過程記錄進日誌中
myslq > set sql_log_bin=0
mysql > source /home/grid/article.sql
或者
mysql > . /home/grid/article.sql
另外一種恢復數據的方式是直接使用二進制日誌:
#mysqlbinlog mysql-bin.000002 | mysql -u root -p
但這種方式彷佛不能徹底恢復全部的數據