亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

MySQL復(fù)制問題的三個參數(shù)分析

 更新時間：2021年04月07日 10:45:39   作者：AsiaYe  
這篇文章主要介紹了MySQL復(fù)制問題的三個參數(shù)分析，幫助大家更好的理解和學(xué)習(xí)使用MySQL數(shù)據(jù)庫，感興趣的朋友可以了解下

    今天星期二，早上居然起晚了，上班遲到了，簡直是。。。廢話不多說，在昨天的文章中，我們提到了三個參數(shù)，分別是：

  • slave_exec_mode參數(shù)；
  • sql_slave_skip_counter=N參數(shù);
  • slave-skip-errors=N參數(shù)。

這三個參數(shù)都可以解決并行復(fù)制中的一些指定的錯誤，例如duplicate key 1062錯誤等，今天我們簡單試驗一下，這三個參數(shù)的區(qū)別：

01 sql_slave_skip_counter參數(shù)

這個參數(shù)的設(shè)置主要是為了跳過某些錯誤的"event",注意這里的用詞是event而不是事務(wù)，是因為它的本質(zhì)是跳過一個一個事件，需要注意的是，這個參數(shù)需要在偏移量復(fù)制模式中使用，如果使用的是gtid的復(fù)制模式，則不可以使用這個參數(shù)。我們來看例子，首先搭建一套復(fù)制關(guān)系：

master   10.30.124.68

slave     10.30.124.128

這倆實例互為主從。我們創(chuàng)建測試表test.yeyz，并插入一些數(shù)據(jù)，其中id為主鍵，具有唯一性，如下：

master上

mysql:(none) 22:25:56>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
+----+------+
4 rows in set (0.00 sec)

slave上

mysql:(none) 22:25:38>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
+----+------+
5 rows in set (0.00 sec)

我們可以發(fā)現(xiàn)，從節(jié)點的數(shù)據(jù)比主節(jié)點多一條，多了id=5的記錄，然后我們在主節(jié)點上插入數(shù)據(jù)：

mysql:(none) 22:26:06>>insert into test.yeyz values (5,5),(6,6);
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

此時觀察從節(jié)點：

mysql:(none) 22:26:34>>show slave status\G
                  Master_Host: 10.30.124.68
                  Master_User: dba_repl
                  Master_Port: 4306
                Connect_Retry: 60
              Master_Log_File: mysqlbin.000002
          Read_Master_Log_Pos: 523
               Relay_Log_File: slave-relay-bin.000002
                Relay_Log_Pos: 319
        Relay_Master_Log_File: mysqlbin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
                   Last_Errno: 1062
                   Last_Error: Coordinator stopped because there were error(s) 
in the worker(s). The most recent failure being:
 Worker 0 failed executing transaction 'ANONYMOUS' at
 master log mysqlbin.000002, end_log_pos 492.
 See error log and/or performance_schema.replication_applier_status_by_worker
 table for more details about this failure or others, if any.
                 Skip_Counter: 0

可以發(fā)現(xiàn)，從節(jié)點已經(jīng)SQL線程斷開了， 這個時候，在主節(jié)點上查詢這個錯誤position 492處的binlog，可以看到：

mysql:(none) 22:30:28>>show binlog events in 'mysqlbin.000002' from 194;  
+-----------------+-----+----------------+-----------+-------------+--------------------------------------------+
| Log_name        | Pos | Event_type     | Server_id | End_log_pos | Info                                       |
+-----------------+-----+----------------+-----------+-------------+--------------------------------------------+
| mysqlbin.000002 | 194 | Anonymous_Gtid |       192 |         259 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'       |
| mysqlbin.000002 | 259 | Query          |       192 |         327 | BEGIN                                      |
| mysqlbin.000002 | 327 | Rows_query     |       192 |         391 | # insert into test.yeyz values (5,5),(6,6) |
| mysqlbin.000002 | 391 | Table_map      |       192 |         439 | table_id: 108 (test.yeyz)                  |
| mysqlbin.000002 | 439 | Write_rows     |       192 |         492 | table_id: 108 flags: STMT_END_F            |
| mysqlbin.000002 | 492 | Xid            |       192 |         523 | COMMIT /* xid=38 */                        |
+-----------------+-----+----------------+-----------+-------------+--------------------------------------------+
6 rows in set (0.00 sec)

從上面的binlog可以看出來，我們的一個insert操作實際上生成了5個enent，分別對應(yīng)的pos是從259~492，關(guān)于event，待會兒再說。

因為主節(jié)點上插入了id=5的記錄，跟從節(jié)點上的記錄沖突了，查看錯誤日志，可以發(fā)現(xiàn)：

Duplicate entry '5' for key 'PRIMARY',
 Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; 
the event's master log FIRST, 
end_log_pos 492 | 2019-07-16 22:26:25

我們通過sql_slave_skip_counter參數(shù)的設(shè)置來解決這個問題，步驟如下：

mysql:(none) 22:29:32>>stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql:(none) 22:32:45>>set global sql_slave_skip_counter=1;
Query OK, 0 rows affected (0.00 sec)

mysql:(none) 22:33:06>>start slave;

   在昨天的文章中我們說過，sql_slave_skip_counter后面跟的值是event的個數(shù)，所以這里我們相當(dāng)于跳過了一個event，mysql中規(guī)定，如果跳過一個event之后，還在某一個事務(wù)里面，那么會繼續(xù)跳過這個事務(wù)。

   使用這個參數(shù)跳過一個event之后，我們再來看從庫表中的數(shù)據(jù)和復(fù)制情況，可以看到：

slave表：

mysql:(none) 22:33:10>>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.30.124.68
                  Master_User: dba_repl
                  Master_Port: 4306
                Connect_Retry: 60
              Master_Log_File: mysqlbin.000002
          Read_Master_Log_Pos: 523
               Relay_Log_File: slave-relay-bin.000003
                Relay_Log_Pos: 319
        Relay_Master_Log_File: mysqlbin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes


mysql:(none) 22:33:16>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
+----+------+
5 rows in set (0.00 sec)

看看master表：

mysql:(none) 22:33:36>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
+----+------+
6 rows in set (0.00 sec)

   可以發(fā)現(xiàn)，master中數(shù)據(jù)插入成功，而slave中數(shù)據(jù)插入失敗，也就是說：

該參數(shù)跳過錯誤的時候，會導(dǎo)致主從的數(shù)據(jù)不一致。

02 slave_skip_errors參數(shù)

    這個參數(shù)是跳過制定的錯誤，也就是說，需要我們設(shè)置對應(yīng)的error_code，從下面的日志中的內(nèi)容可以看出，error_code的值為1062

Duplicate entry '5' for key 'PRIMARY',
 Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; 
the event's master log FIRST, 
end_log_pos 492 | 2019-07-16 22:26:25

   我們需要手動將這個參數(shù)的值也該為1062，需要注意的是，這個參數(shù)的改動需要重啟mysql服務(wù)，因為這個參數(shù)是一個只讀的參數(shù)。

   修改后的情況如下：

mysql--dba_admin@127.0.0.1:(none) 22:38:55>>show variables like '%errors%';
+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_connect_errors | 1000000 |
| slave_skip_errors  | 1062    |
+--------------------+---------+
2 rows in set (0.01 sec)

   此時我們更新master表和slave表的數(shù)據(jù)，更新后的情況如下：

master：

mysql:(none) 22:39:15>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 ||  2 |    2 |
|  3 |    3 ||  4 |    4 |
|  5 |    5 ||  6 |    6 |
+----+------+
6 rows in set (0.00 sec)

slave上：

mysql:(none) 22:40:15>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
|  7 |    7 |
+----+------+
7 rows in set (0.00 sec)

我們發(fā)現(xiàn)，slave表比master表多一條數(shù)據(jù)，也就是id=7的記錄，此時我們在master上執(zhí)行：

mysql:(none) 22:34:15>>insert into test.yeyz values (7,7),(8,8);
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

查看slave上面的復(fù)制情況和數(shù)據(jù)情況，如下：

mysql:(none) 22:39:05>>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.30.124.68
                  Master_User: dba_repl
                  Master_Port: 4306
                Connect_Retry: 60
              Master_Log_File: mysqlbin.000002
          Read_Master_Log_Pos: 852
               Relay_Log_File: slave-relay-bin.000005
                Relay_Log_Pos: 648
        Relay_Master_Log_File: mysqlbin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 


mysql:(none) 22:40:15>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
|  7 |    7 |
+----+------+
7 rows in set (0.00 sec)

   可以看到，復(fù)制沒有出現(xiàn)錯誤，即使從庫上已經(jīng)有id=7的記錄。而且發(fā)現(xiàn)，從庫的數(shù)據(jù)跟之前保持一致，也就是說，主庫插入的id=8的記錄沒有被同步過來。

   總結(jié)一下：該參數(shù)在跳過復(fù)制錯誤的時候，需要重啟mysql服務(wù)，然后可能導(dǎo)致主從數(shù)據(jù)不一致。

03 slave-skip-errors=N參數(shù)

  再看最后一個參數(shù)，這個參數(shù)表示的是并行復(fù)制過程中的從庫復(fù)制模式，默認(rèn)值是strict嚴(yán)格模式，和上面一樣，我們先看主庫和從庫的數(shù)據(jù)情況：

master數(shù)據(jù)：

mysql:(none) 22:39:20>>select * from test.yeyz;                 
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
|  7 |    7 |
|  8 |    8 |
+----+------+
8 rows in set (0.00 sec)

slave數(shù)據(jù)：

mysql:(none) 22:42:46>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
|  7 |    7 |
|  8 |    8 |
|  9 |    9 |
+----+------+
9 rows in set (0.00 sec)

   此時我們在從庫上修改參數(shù)如下：

mysql:(none) 22:42:59>>show variables like '%exec%';
+----------------------------------+--------+
| Variable_name                    | Value  |
+----------------------------------+--------+
| gtid_executed_compression_period | 1000   |
| max_execution_time               | 0      |
| rbr_exec_mode                    | STRICT |
| slave_exec_mode                  | STRICT |
+----------------------------------+--------+
4 rows in set (0.00 sec)

mysql:(none) 22:44:05>>set global slave_exec_mode='IDEMPOTENT';
Query OK, 0 rows affected (0.00 sec)

mysql:(none) 22:44:10>>show variables like '%exec%';           
+----------------------------------+------------+
| Variable_name                    | Value      |
+----------------------------------+------------+
| gtid_executed_compression_period | 1000       |
| max_execution_time               | 0          |
| rbr_exec_mode                    | STRICT     |
| slave_exec_mode                  | IDEMPOTENT |
+----------------------------------+------------+
4 rows in set (0.00 sec)

  修改完參數(shù)，我們在主庫上進(jìn)行insert操作：

insert into test.yeyz values (9,9),(10,10);

   查看從庫的復(fù)制狀態(tài)和數(shù)據(jù)情況，如下：

mysql:(none) 22:44:14>>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.30.124.68
                  Master_User: dba_repl
                  Master_Port: 4306
                Connect_Retry: 60
              Master_Log_File: mysqlbin.000002
          Read_Master_Log_Pos: 1183
               Relay_Log_File: slave-relay-bin.000007
                Relay_Log_Pos: 650
        Relay_Master_Log_File: mysqlbin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

1 row in set (0.00 sec)

mysql:(none) 22:44:38>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
|  7 |    7 |
|  8 |    8 |
|  9 |    9 |
| 10 |   10 |
+----+------+
10 rows in set (0.00 sec)

   可以發(fā)現(xiàn)，既沒有出現(xiàn)復(fù)制錯誤，主庫上插入的數(shù)據(jù)也同步過來了。   

總結(jié)一下：

  • slave_exec_mode參數(shù)；
  • sql_slave_skip_counter=N參數(shù);
  • slave-skip-errors=N參數(shù)。

   這三個參數(shù)都能解決復(fù)制過程中的不一致情況，區(qū)別如下：

slave_exec_mode參數(shù)可以保證主從數(shù)據(jù)一致，其他兩個不可以。

slave-skip-errors參數(shù)可以跳過制定的錯誤，但是需要重啟實例，不能保證數(shù)據(jù)一致。

sql_slave_skip_counter參數(shù)需要在偏移量的復(fù)制模式下使用，不能保證數(shù)據(jù)一致。

以上就是MySQL復(fù)制問題的三個參數(shù)分析的詳細(xì)內(nèi)容，更多關(guān)于MySQL復(fù)制問題的資料請關(guān)注腳本之家其它相關(guān)文章！

相關(guān)文章

  • wampserver下mysql導(dǎo)入數(shù)據(jù)庫的步驟

    wampserver下mysql導(dǎo)入數(shù)據(jù)庫的步驟

    這篇文章主要介紹了wampserver下mysql導(dǎo)入數(shù)據(jù)庫的步驟,需要的朋友可以參考下
    2016-08-08
  • 詳細(xì)解讀MySQL中的權(quán)限

    詳細(xì)解讀MySQL中的權(quán)限

    這篇文章主要介紹了MySQL中的權(quán)限,包括各個權(quán)限所能操作的事務(wù)以及操作權(quán)限的一些常用命令語句,需要的朋友可以參考下
    2015-05-05
  • MySQL錯誤:Can‘t?connect?to?MySQL?server?on?localhost解決辦法(分多種情況)

    MySQL錯誤:Can‘t?connect?to?MySQL?server?on?localhost解決辦法

    這篇文章主要給大家介紹了關(guān)于MySQL錯誤:Can‘t?connect?to?MySQL?server?on?localhost的解決辦法,文中介紹的方法分多種情況,通過代碼介紹的非常詳細(xì),需要的朋友可以參考下
    2024-05-05
  • 詳解MySQL的慢查詢?nèi)罩竞湾e誤日志

    詳解MySQL的慢查詢?nèi)罩竞湾e誤日志

    這篇文章主要詳細(xì)介紹了MySQL的慢查詢?nèi)罩竞湾e誤日志,文中通過代碼示例講解的非常詳細(xì),對大家學(xué)習(xí)和了解MySQL的慢查詢?nèi)罩竞湾e誤日志有一定的幫助,需要的朋友可以參考下
    2024-04-04
  • MySql各種查詢方式詳解

    MySql各種查詢方式詳解

    如果是做數(shù)據(jù)分析，MySQL里面最重要、最常用的就是數(shù)據(jù)查詢，數(shù)據(jù)查詢不只是簡單查詢數(shù)據(jù)庫中存儲的數(shù)據(jù)，還要根據(jù)需求對數(shù)據(jù)進(jìn)行篩選、聚合，以及確定數(shù)據(jù)以什么樣的格式進(jìn)行顯示。MySQL提供了強大、靈活的語句和函數(shù)來實現(xiàn)查詢的操作
    2022-07-07
  • 關(guān)于SQL語句中的AND和OR執(zhí)行順序遇到的問題

    關(guān)于SQL語句中的AND和OR執(zhí)行順序遇到的問題

    在SQL語句中的AND和OR執(zhí)行順序中我們經(jīng)常會遇到一些問題，下面有簡單的解決方法，小編來和大家一起來看看
    2019-05-05
  • 一個 20 秒 SQL 慢查詢優(yōu)化處理方案

    一個 20 秒 SQL 慢查詢優(yōu)化處理方案

    這篇文章主要分享一個 20 秒 SQL 慢查詢優(yōu)化的經(jīng)歷與處理方案，頁面無法正確獲取數(shù)據(jù)，經(jīng)排查原來是接口調(diào)用超時，而最后發(fā)現(xiàn)是因為SQL查詢長達(dá)到20多秒而導(dǎo)致了問題的發(fā)生，下面來看問題具體介紹吧
    2022-01-01
  • mysql 5.7.18 zip版安裝使用教程

    mysql 5.7.18 zip版安裝使用教程

    這篇文章主要為大家詳細(xì)介紹了mysql 5.7.18 zip版安裝使用教程，具有一定的參考價值，感興趣的小伙伴們可以參考一下
    2019-06-06
  • Ubuntu中更改MySQL數(shù)據(jù)庫文件目錄的方法

    Ubuntu中更改MySQL數(shù)據(jù)庫文件目錄的方法

    這篇文章主要給大家介紹了關(guān)于在Ubuntu中更改MySQL數(shù)據(jù)庫文件目錄的相關(guān)資料，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2018-11-11
  • MySQL分支和循環(huán)結(jié)構(gòu)方式

    MySQL分支和循環(huán)結(jié)構(gòu)方式

    在MySQL中,IF函數(shù)用于根據(jù)條件返回不同的值,類似于Java的三目運算符,CASE語句則提供了兩種形式：簡單CASE函數(shù)和搜索CASE函數(shù),分別類似于Java中的switch-case結(jié)構(gòu)和多重if判斷,這些控制流函數(shù)在數(shù)據(jù)庫查詢和數(shù)據(jù)處理中非常有用,可以實現(xiàn)復(fù)雜的邏輯判斷
    2024-10-10

最新評論