list集合排序

阿新 • • 發佈：2020-12-08

MySQL binlog日誌操作詳解

MySQL的二進位制日誌可以說是MySQL最重要的日誌了，它記錄了所有的DDL和DML(除了資料查詢語句)語句，以事件形式記錄，還包含語句所執行的消耗的時間，MySQL的二進位制日誌是事務安全型的。

binlog日誌的作用

其一：MySQL Replication在Master端開啟binlog，Mster把它的二進位制日誌傳遞給slaves來達到master-slave資料一致的目的。
其二：自然就是資料恢復了，通過使用mysqlbinlog工具來使恢復資料。
MySQL二進位制日誌包括兩類檔案：二進位制日誌索引檔案（檔名字尾為.index）用於記錄所有的二進位制檔案，二進位制日誌檔案（檔名字尾為.00000*）記錄資料庫所有的DDL和DML(除了資料查詢語句)語句事件。

一、開啟binlog日誌

vim /etc/my.cnf
[mysqld]
log_bin = /data/log/mysql/binlog/mysql-bin.log

重啟mysqld服務使配置生效
/etc/init.d/mysqld restart

二、登入mysql伺服器，通過mysql的變數配置表，檢視二進位制日誌是否已開啟.

mysql> show variables like 'log_%';

+----------------------------------------+----------------------------------------+
| Variable_name                          | Value                                  |
+----------------------------------------+----------------------------------------+
| log_bin                                | ON                                     |
| log_bin_basename                       | /data/log/mysql/binlog/mysql-bin       |
| log_bin_index                          | /data/log/mysql/binlog/mysql-bin.index |
| log_bin_trust_function_creators        | OFF                                    |
| log_bin_use_v1_row_events              | OFF                                    |
| log_builtin_as_identified_by_password  | OFF                                    |
| log_error                              | ./mysql-error.log                      |
| log_error_verbosity                    | 2                                      |
| log_output                             | FILE                                   |
| log_queries_not_using_indexes          | ON                                     |
| log_slave_updates                      | ON                                     |
| log_slow_admin_statements              | ON                                     |
| log_slow_slave_statements              | ON                                     |
| log_statements_unsafe_for_binlog       | ON                                     |
| log_syslog                             | OFF                                    |
| log_syslog_facility                    | daemon                                 |
| log_syslog_include_pid                 | ON                                     |
| log_syslog_tag                         |                                        |
| log_throttle_queries_not_using_indexes | 10                                     |
| log_timestamps                         | SYSTEM                                 |
| log_warnings                           | 1                                      |
+----------------------------------------+----------------------------------------+
21 rows in set (0.02 sec)

三、檢視某個binlog日誌內容，常用有兩種方式：

使用mysqlbinlog自帶檢視命令法：
binlog是二進位制檔案，普通檔案檢視器cat more vim 等開啟都是亂碼，必須使用自帶的 mysqlbinlog 命令檢視.

[root@mysql ~]# su - mysql 
[mysql@mysql ~]$ mysqlbinlog /data/log/mysql/binlog/mysql-bin.000005

使用show binlog events 檢視binlog日誌.

mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
選項解析：
               IN 'log_name'   指定要查詢的binlog檔名(不指定就是第一個binlog檔案)
               FROM pos        指定從哪個pos起始點開始查起(不指定就是從整個檔案首個pos點開始算)
               LIMIT [offset,] 偏移量(不指定就是0)
               row_count       查詢總條數(不指定就是所有行)

擷取部分查詢結果：

mysql> show binlog events in 'mysql-bin.000005'\G
*************************** 1. row ***************************
   Log_name: mysql-bin.000005
        Pos: 4
 Event_type: Format_desc
  Server_id: 4294967295
End_log_pos: 123
       Info: Server ver: 5.7.27-log, Binlog ver: 4
*************************** 2. row ***************************
   Log_name: mysql-bin.000005
        Pos: 123
 Event_type: Previous_gtids
  Server_id: 4294967295
End_log_pos: 194
       Info: a775a0a0-37aa-11eb-a07c-000c29292583:1-7
*************************** 3. row ***************************
   Log_name: mysql-bin.000005
        Pos: 194
 Event_type: Gtid
  Server_id: 4294967295
End_log_pos: 259
       Info: SET @@SESSION.GTID_NEXT= 'a775a0a0-37aa-11eb-a07c-000c29292583:8'
*************************** 4. row ***************************
   Log_name: mysql-bin.000005                                         ----> 查詢的binlog日誌檔名
        Pos: 259                                                       ----> pos起始點:
 Event_type: Query                                                     ---->  事件型別
  Server_id: 4294967295                                               ----> 標識是由哪臺伺服器執行的
End_log_pos: 376                                                       ----> pos結束點:120(即：下行的pos起始點)
       Info: use `test`; create table test (id int,name varchar(10))   ---> 執行的sql語句

這條語句可以將指定的binlog日誌檔案，分成有效事件行的方式返回，並可使用limit指定pos點的起始偏移，查詢條數；

查詢第一個(即mysql-bin.000001)binlog日誌：
mysql> show binlog events\G
指定查詢 mysql-bin.00005 這個檔案:
mysql> show binlog events in 'mysql-bin.000005'\G
指定查詢 mysql-bin.000005 這個檔案，從pos點:666開始查起：
mysql> show binlog events in 'mysql-bin.000005' from 666\G
指定查詢 mysql-bin.000005 這個檔案，從pos點:376開始查起，查詢10條
mysql> show binlog events in 'mysql-bin.000005' from 376 limit 10\G
指定查詢 mysql-bin.000005 這個檔案，從pos點:376開始查起，偏移2行，查詢10條
mysql> show binlog events in 'mysql-bin.000005' from 376 limit 2,10\G

四、通過全備和binlog日誌恢復資料例項：

假設現在是凌晨1:00，我的計劃任務開始執行一次完整的資料庫備份：
將test資料庫備份到 /tmp/bak_test.sql 檔案中：

[mysql@mysql ~]$ mysqldump -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -lF --log-error=/tmp/myDump.err -B test > /tmp/bak_test.sql

大約過若干分鐘，全備份就完成了，我不用擔心資料丟失了，因為我有備份了，嘎嘎~~~
由於我使用了-F選項，當備份工作剛開始時系統會重新整理log日誌，產生新的binlog日誌來記錄備份之後的資料庫“增刪改”操作，檢視一下：

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+------------------+----------+--------------+------------------+-------------------------------------------+
| mysql-bin.000006 |      194 |              |                  | a775a0a0-37aa-11eb-a07c-000c29292583:1-14 |
+------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)

也就是說， mysql-bin.000006 是用來記錄1:00之後對資料庫的所有“增刪改”操作

早9:30上班了，業務的需求會對資料庫進行各種“增刪改”操作
比如：建立一個tb1表並插入、修改了資料等等:

mysql>use test;
mysql>CREATE TABLE IF NOT EXISTS `yjh1` (
      `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
      `name` varchar(16) NOT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

匯入資料:

mysql> insert into test.yjh1(name) values('DBA'),('CBA'),('NBA'),('UFO');

檢視資料

mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
|  1 | DBA  |
|  2 | CBA  |
|  3 | NBA  |
|  4 | UFO  |
+----+------+
4 rows in set (0.00 sec)

中午時分又執行了修改資料操作

mysql> update test.yjh1 set name='BBA' where id=4;

修改後的結果：

mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
|  1 | DBA  |
|  2 | CBA  |
|  3 | NBA  |
|  4 | BBA  |
+----+------+
4 rows in set (0.00 sec)

假設此時是下午，腦子一熱莫名地執行了一條悲催的SQL語句，整個資料庫都沒了：
mysql> drop database test;
然後，就沒然後了，凌亂一會，開始恢復吧！！
先仔細檢視最後一個binlog日誌，並記錄下關鍵的pos點，到底是哪個pos點的操作導致了資料庫的破壞(通常在最後幾步)；
備份一下最後一個binlog日誌檔案：
cp -v /data/log/mysql/binlog/mysql-bin.000006 /tmp/

此時執行一次重新整理日誌索引操作，重新開始新的binlog日誌記錄檔案，理論說 mysql-bin.000007 這個檔案不會再有後續寫入了(便於我們分析原因及查詢pos點)，以後所有資料庫操作都會寫入到下一個日誌檔案；

mysql> flush logs;
Query OK, 0 rows affected (0.08 sec)

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+------------------+----------+--------------+------------------+-------------------------------------------+
| mysql-bin.000007 |      194 |              |                  | a775a0a0-37aa-11eb-a07c-000c29292583:1-18 |
+------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)

讀取binlog日誌，分析問題

方式一：使用mysqlbinlog讀取binlog日誌：
mysqlbinlog /data/log/mysql/binlog/mysql-bin.000006

方式二：登入伺服器，並檢視(推薦)：
以下為末尾片段：

mysql> show binlog events in 'mysql-bin.000006'\G
...前面行數很多，省略。
*************************** 17. row ***************************
   Log_name: mysql-bin.000006
        Pos: 1238
 Event_type: Gtid
  Server_id: 4294967295
End_log_pos: 1303
       Info: SET @@SESSION.GTID_NEXT= 'a775a0a0-37aa-11eb-a07c-000c29292583:18'
*************************** 18. row ***************************
   Log_name: mysql-bin.000006
        Pos: 1303
 Event_type: Query
  Server_id: 4294967295
End_log_pos: 1395
       Info: drop database test
*************************** 19. row ***************************
   Log_name: mysql-bin.000006
        Pos: 1395
 Event_type: Rotate
  Server_id: 4294967295
End_log_pos: 1442
       Info: mysql-bin.000007;pos=4
19 rows in set (0.00 sec)

通過分析，造成資料庫破壞的pos點區間是介於 1303--1395 之間，只要恢復到1395前就可。

現在先把凌晨備份的資料恢復:
mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v < /tmp/bak_test.sql
注: 至此截至當日凌晨(1:00)前的備份資料都恢復了。
但今天一整天(1:00--現在)的資料腫麼辦呢？就得從前文提到的 mysql-bin.000007 新日誌做文章了......
從binlog日誌恢復資料

恢復語法格式：
# mysqlbinlog mysql-bin.0000xx | mysql -u使用者名稱 -p密碼 資料庫名
常用選項：
        --start-position=953                    起始pos點
        --stop-position=1437                    結束pos點
        --start-datetime="2017-6-20 13:18:54"   起始時間點
        --stop-datetime="2017-6-20 13:21:53"    結束時間點
        --database=test                       指定只恢復test資料庫(一臺主機上往往有多個數據庫，只限本地log日誌)

不常用選項：   
        -u --user=name              Connect to the remote server as username.連線到遠端主機的使用者名稱
        -p --password[=name]        Password to connect to remote server.連線到遠端主機的密碼
        -h --host=name              Get the binlog from server.從遠端主機上獲取binlog日誌
        --read-from-remote-server   Read binary logs from a MySQL server.從某個MySQL伺服器上讀取binlog日誌

小結：實際是將讀出的binlog日誌內容，通過管道符傳遞給mysql命令。這些命令、檔案儘量寫成絕對路徑；

方法1：通過binlog日誌mysql-bin.000007直接恢復.
使用-d引數表示從binlog中只匯出test庫的資料.

mysqlbinlog mysql-bin.000007 -d test > mysql-bin.sql
然後vim mysql-bin.sql檔案，找到誤操作的mysql語句，一定要刪除.我們這裡誤操作的sql為drop database test，找到並刪除即可.

然後匯入/tmp/mysql-bin.sql檔案. 
mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v < /tmp/mysql-bin.sql

另一種指定位置點匯出sql的方法(-r和重定向是一個作用.)：
mysqlbinlog mysqlbin.000020 --start-position=365 --stop-postition=456 -r pos.sql
方法2：指定pos點恢復資料(部分恢復):

A.指定pos結束點恢復某段時間的資料

@ --stop-position=759 pos結束點
  注：此pos結束點介於“匯入實驗資料”與更新 name='UFO'之間，這樣可以恢復到更改name='BBA'之前的“匯入測試資料”

mysqlbinlog --stop-position=759 --database=test mysql-bin.000007 | mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v test

在另一終端登入檢視結果(成功恢復了)：

mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
|  1 | DBA  |
|  2 | CBA  |
|  3 | NBA  |
|  4 | UFO  |
+----+------+
4 rows in set (0.00 sec)

B.指定Pos點區間恢復(部分恢復)：

更新name='BBA'這條資料, Info: use `test`; update test.yjh1 set name='BBA' where id=4

mysqlbinlog --start-position=759 --stop-position=880 --database=test mysql-bin.000007 | mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 test

在另一終端登入檢視結果(成功恢復了)：

mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
|  1 | DBA  |
|  2 | CBA  |
|  3 | NBA  |
|  4 | BBA  |
+----+------+
4 rows in set (0.00 sec)

事務區間：INFO資訊為兩個BEGIN 之間的為按事務區間分如：Pos: 469 End_log_pos: 759
日誌區間：日誌區間為Pos: 759 到 End_log_pos: 880
除了用Pos點的辦法進行資料恢復，也可以通過指定時間區間進行恢復，按時間恢復需要用mysqlbinlog命令讀取binlog日誌內容，找時間節點。
例如：
@ --start-datetime="2017-6-20 13:18:54" 起始時間點
@ --stop-datetime="2013-16-20 14:21:53" 結束時間點
通過起始時間段則可以這樣恢復資料
mysqlbinlog --start-datetime="2017-6-20 13:18:54" --stop-datetime="2013-16-20 14:21:53" --database=test mysql-bin.000007 | mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v test

總結：所謂恢復，就是讓MySQL將儲存在binlog日誌中指定段落區間的sql語句逐個重新執行一次而已。

--master-data引數解釋：
--master-data
該選項將binlog的位置和檔名追加到輸出檔案中。

如果為1，將會輸出CHANGE MASTER 命令；
如果為2，輸出的CHANGE MASTER命令前添加註釋資訊。
該選項將開啟--lock-all-tables選項，除非--single-transaction也被指定（在這種情況下，全域性讀鎖在開始匯出時獲得很短的時間；其他內容參考下面的--single-transaction選項）。
該選項自動關閉--lock-tables選項。

--master-data=1
從庫: 告訴從庫，從主庫的那個位置開始同步.

--master-data=2
註釋中記錄了需要獲取的binlog檔案和位置點

myisam備份場景:

myisam備份是要鎖表，不然資料可能會不一致.
mysqldump -uroot -p123456 -A -B --master-data=2 -x|gzip >/opt/all.sql.gz

innodb備份場景:

mysqldump -uroot -p123456 -A -B --master-data=2 --single-transaction|gzip >/opt/all.sql.gz

innoDB備份示例:

mysqldump --user=root --all-databases --flush-privileges --single-transaction --master-data=1 --flush-logs --triggers --routines --events --hex-blob > /tmp/full_dump.sql

五、常用binlog日誌操作命令

檢視所有binlog日誌列表
mysql> show master logs;
檢視master狀態，即最後(最新)一個binlog日誌的編號名稱，及其最後一個操作事件pos結束點(Position)值
mysql> show master status;
重新整理log日誌，自此刻開始產生一個新編號的binlog日誌檔案

mysql> flush logs;
      注：每當mysqld服務重啟時，會自動執行此命令，重新整理binlog日誌；在mysqldump備份資料時加 -F 選項也會重新整理binlog日誌；

binlog日誌的刪除
binlog的刪除可以手工刪除或自動刪除
自動刪除binlog
通過binlog引數（expire_logs_days）來實現mysql自動刪除binlog

mysql> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       167 |
| mysql-bin.000002 | 531688179 |
| mysql-bin.000003 |      1091 |
| mysql-bin.000004 | 360363501 |
| mysql-bin.000005 |      1798 |
| mysql-bin.000006 |       577 |
| mysql-bin.000007 |      1056 |
| mysql-bin.000008 | 720729027 |
| mysql-bin.000009 |      3010 |
+------------------+-----------+
9 rows in set (0.00 sec)

mysql> show variables like 'expire_logs_days';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 0     |
+------------------+-------+
1 row in set (0.00 sec)

mysql> set global expire_logs_days=14;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'expire_logs_days';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 14    |
+------------------+-------+
1 row in set (0.01 sec)

手工刪除binlog

mysql> reset master;     //清空所有的binlog日誌
mysql> reset slave;      //清空slave的中繼日誌
mysql> purge master logs before '2017-03-30 00:20:00';    //刪除指定日期以前的日誌索引中binlog日誌檔案
mysql> purge master logs to 'mysql-bin.000009';           //刪除指定日誌檔案的日誌索引之前的日誌檔案
或者直接用作業系統命令直接刪除

顯示當前註冊的slave的列表。不以--report-host=slave_name選項為開頭的slave不會顯示在本列表中
mysql> show slave hosts;

MySQLbinlog的三種日誌模式：

1.Statement Level模式：
每一條會修改資料的sql都會記錄到master的bin-log中,slave在賦值的時候sql程序會解析成和master端執行過的相同的sql來再次執行.

日誌量小,節約IO，提高效能

2.Row Level模式:
日誌中會記錄成每一行資料被修改的形式,然後在slave端再對相同的資料進行修改

記錄下每一行資料修改的細節，解決函式、儲存過程等的複製問題.

日誌量大.

3.Mixed(混合)模式:
實際就是前兩種模式的結合,在Mixed模式下，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式,
也就是在Statement和Row之間選擇一種.

修改日誌模式的方式：
在配置檔案中修改：

log-bin=mysql-bin
binlog_format='STATEMENT'
binlog_format='ROW'
binlog_format='MIXED'

線上修改立即生效方法：
SET SESSION binlog_format = 'STATEMENT';
SET SESSION binlog_format = 'ROW';
SET SESSION binlog_format = 'MIXED';

全域性生效：
SET GLOBAL binlog_format = 'STATEMENT';
SET GLOBAL binlog_format = 'ROW';
SET GLOBAL binlog_format = 'MIXED';

list集合排序

MySQL binlog日誌操作詳解

一、開啟binlog日誌

二、登入mysql伺服器，通過mysql的變數配置表，檢視二進位制日誌是否已開啟.

三、檢視某個binlog日誌內容，常用有兩種方式：

四、通過全備和binlog日誌恢復資料例項：

五、常用binlog日誌操作命令

Java List集合排序實現方法解析

java list集合排序按某一屬性排序操作

list集合排序

Java-List集合排序之Comparable與Comparator的使用

Java使用Collections工具類對List集合進行排序

Android List(集合)中的物件以某一個欄位排序案例

Java8 使用 stream().sorted()對List集合進行排序的操作

Java 使用Collections.reverse對list集合進行降序排序

Java List集合實體類按漢字拼音排序

Java8對list集合進行排序、過濾、分組、去重、轉map、遍歷賦值等操作

對List集合中的物件按某個屬性進行排序

對List集合進行排序

C# 中的List.Sort()--集合排序方法全面解析

java中list集合按物件屬性進行排序

jdk1.7和jdk1.8對list集合根據物件的屬性進行排序

list集合按照某個元素排序（steam流）-- 實測可行

JAVA集合基礎03---List集合，資料結構，Set集合雜湊值，排序器

Linq兩個List集合取交集的實現

Java sort集合排序的兩種方式解析

python list多級排序知識點總結

list集合排序

MySQL binlog日誌操作詳解

一、開啟binlog日誌

二、登入mysql伺服器，通過mysql的變數配置表，檢視二進位制日誌是否已開啟.

三、檢視某個binlog日誌內容，常用有兩種方式：

四、 通過全備和binlog日誌恢復資料例項：

五、常用binlog日誌操作命令

相關推薦

四、通過全備和binlog日誌恢復資料例項：