mysql復(fù)制和內(nèi)存引擎的表是怎么樣的

mysql復(fù)制和內(nèi)存引擎的表是怎么樣的，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

當(dāng)主服務(wù)器關(guān)閉并重新啟動(dòng)時(shí)，其內(nèi)存表將變?yōu)榭?。要將此效果?fù)制到從屬服務(wù)器，在主服務(wù)器啟動(dòng)后第一次使用給定內(nèi)存表時(shí)，它會(huì)記錄一個(gè)事件，通知從屬服務(wù)器必須通過將該表的DELETE語句寫入二進(jìn)制日志來清空該表。

當(dāng)從屬服務(wù)器關(guān)閉并重新啟動(dòng)時(shí)，其內(nèi)存表將變?yōu)榭?。這會(huì)導(dǎo)致從屬設(shè)備與主設(shè)備不同步，并可能導(dǎo)致其他故障或?qū)е聫膶僭O(shè)備停止：

從主機(jī)接收的行格式更新和刪除可能會(huì)失敗，因?yàn)樵凇皟?nèi)存表”中找不到記錄。

語句，例如INSERT INTO。。。從內(nèi)存中選擇\u表可以在主設(shè)備和從設(shè)備上插入一組不同的行。

當(dāng)主庫上使用內(nèi)存引擎的表時(shí)，主庫因?yàn)槟承┰蛑貑⒘?。啟?dòng)好之后，再打開主庫的內(nèi)存引擎表時(shí)，會(huì)先把里面的內(nèi)容清空。所以這個(gè)時(shí)候主從狀態(tài)是正常的。

但當(dāng)從庫被重啟時(shí)，因?yàn)閙emory的內(nèi)容沒有了，所以可能會(huì)出現(xiàn)主從報(bào)錯(cuò)的現(xiàn)象。

實(shí)驗(yàn)：

一 主庫異常關(guān)閉：

在主庫上建表

mysql> show create table b;

+-------+-------------------------------------------------------------------------------------------------------+

| Table | Create Table                                                                                          |

+-------+-------------------------------------------------------------------------------------------------------+

| b     | CREATE TABLE `b` (

  `id` int(11) NOT NULL,

  PRIMARY KEY (`id`)

) ENGINE=MEMORY DEFAULT CHARSET=utf8

主庫：

mysql> insert into b values (10),(20);

Query OK, 2 rows affected (0.00 sec)

Records: 2  Duplicates: 0  Warnings: 0

從庫：

mysql> select * from a.b;

+----+

| id |

+----+

| 10 |

| 20 |

+----+

重啟主庫后：

從庫：

mysql> select * from a.b;

+----+

| id |

+----+

| 10 |

| 20 |

+----+

2 rows in set (0.00 sec)

這時(shí)再去主庫上觀察：

mysql> show master status;

+------------------+----------+--------------+------------------+-------------------------------------------+

| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |

+------------------+----------+--------------+------------------+-------------------------------------------+

| mysql-bin.000012 |      194 |              |                  | 48dfe7f5-3ab5-11e7-b3fa-525400199b09:1-23 |

+------------------+----------+--------------+------------------+-------------------------------------------+

1 row in set (0.00 sec)

mysql> select  *from a.b;

Empty set (0.00 sec)

mysql> show master status;

+------------------+----------+--------------+------------------+-------------------------------------------+

| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |

+------------------+----------+--------------+------------------+-------------------------------------------+

| mysql-bin.000012 |      478 |              |                  | 48dfe7f5-3ab5-11e7-b3fa-525400199b09:1-24 |

+------------------+----------+--------------+------------------+-------------------------------------------+

1 row in set (0.00 sec)

mysql> show binlog  events in 'mysql-bin.000012';

+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+

| Log_name         | Pos | Event_type     | Server_id | End_log_pos | Info                                                               |

+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+

| mysql-bin.000012 |   4 | Format_desc    | 169454186 |         123 | Server ver: 5.7.16.k1-ucloudrel1-log, Binlog ver: 4                |

| mysql-bin.000012 | 123 | Previous_gtids | 169454186 |         194 | 48dfe7f5-3ab5-11e7-b3fa-525400199b09:1-23                          |

| mysql-bin.000012 | 194 | Gtid           | 169454186 |         259 | SET @@SESSION.GTID_NEXT= '48dfe7f5-3ab5-11e7-b3fa-525400199b09:24' |

| mysql-bin.000012 | 259 | Query          | 169454186 |         327 | BEGIN                                                              |

| mysql-bin.000012 | 327 | Query          | 169454186 |         409 | DELETE FROM `a`.`b`                                                |

| mysql-bin.000012 | 409 | Query          | 169454186 |         478 | COMMIT                                                             |

+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+

6 rows in set (0.00 sec)

再次去從庫觀察：

mysql> select * from a.b;

Empty set (0.00 sec)

這時(shí)主從的狀態(tài)也是正常的。

二 從庫啟常重啟：

主庫上：

mysql> insert into a.b values (10),(20);

Query OK, 2 rows affected (0.00 sec)

Records: 2  Duplicates: 0  Warnings: 0

從庫：

mysql> select * from a.b;

+----+

| id |

+----+

| 10 |

| 20 |

+----+

2 rows in set (0.00 sec)

重啟從庫后：

mysql> select  *from a.b;

Empty set (10.00 sec)

主庫：

mysql> delete from a.b where id=10;

Query OK, 1 row affected (0.00 sec)

從庫：

mysql> show slave status \G

*************************** 1. row ***************************

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 10.25.170.106

                  Master_User: ucloudbackup

                  Master_Port: 3306

                Connect_Retry: 60

              Master_Log_File: mysql-bin.000012

          Read_Master_Log_Pos: 1049

               Relay_Log_File: mysql-relay.000024

                Relay_Log_Pos: 360

        Relay_Master_Log_File: mysql-bin.000012

             Slave_IO_Running: Yes

            Slave_SQL_Running: No

              Replicate_Do_DB:

          Replicate_Ignore_DB:

           Replicate_Do_Table:

       Replicate_Ignore_Table:

      Replicate_Wild_Do_Table:

  Replicate_Wild_Ignore_Table:

                   Last_Errno: 1032

                   Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 0 failed executing transaction '48dfe7f5-3ab5-11e7-b3fa-525400199b09:26' at master log mysql-bin.000012, end_log_pos 980. 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

分析：

重啟主庫，并且訪問a.b表時(shí)， mysqlbinlog中會(huì)記錄下面的內(nèi)容：

# at 327

#170518 19:16:07 server id 10  end_log_pos 410 CRC32 0xc908da54  Query thread_id=5 exec_time=499 error_code=0

SET TIMESTAMP=1495106167/*!*/;

DELETE FROM `a`.`b`

/*!*/;

通過跟蹤可知：

#0  open_table_entry_fini (thd=0x7f3f1c000d80, share=0x7f3f14045b50, entry=0x7f3f1c00eef0) at /data/mysql-5.7.17/sql/sql_base.cc:4325

#1  0x00000000014968ac in open_table (thd=0x7f3f1c000d80, table_list=0x7f3f1c006580, ot_ctx=0x7f3f40092370) at /data/mysql-5.7.17/sql/sql_base.cc:3551

#2  0x000000000149912c in open_and_process_table (thd=0x7f3f1c000d80, lex=0x7f3f1c003078, tables=0x7f3f1c006580, counter=0x7f3f1c003138, flags=0, prelocking_strategy=0x7f3f40092470,

    has_prelocking_list=false, ot_ctx=0x7f3f40092370) at /data/mysql-5.7.17/sql/sql_base.cc:5108

#3  0x000000000149a1ce in open_tables (thd=0x7f3f1c000d80, start=0x7f3f40092430, counter=0x7f3f1c003138, flags=0, prelocking_strategy=0x7f3f40092470) at /data/mysql-5.7.17/sql/sql_base.cc:5719

#4  0x000000000149b4fb in open_tables_for_query (thd=0x7f3f1c000d80, tables=0x7f3f1c006580, flags=0) at /data/mysql-5.7.17/sql/sql_base.cc:6494

#5  0x00000000015208fe in execute_sqlcom_select (thd=0x7f3f1c000d80, all_tables=0x7f3f1c006580) at /data/mysql-5.7.17/sql/sql_parse.cc:5166

#6  0x000000000151a193 in mysql_execute_command (thd=0x7f3f1c000d80, first_level=true) at /data/mysql-5.7.17/sql/sql_parse.cc:2794

#7  0x00000000015218f6 in mysql_parse (thd=0x7f3f1c000d80, parser_state=0x7f3f40093690) at /data/mysql-5.7.17/sql/sql_parse.cc:5611

#8  0x000000000151709c in dispatch_command (thd=0x7f3f1c000d80, com_data=0x7f3f40093df0, command=COM_QUERY) at /data/mysql-5.7.17/sql/sql_parse.cc:1461

#9  0x0000000001515f8e in do_command (thd=0x7f3f1c000d80) at /data/mysql-5.7.17/sql/sql_parse.cc:999

#10 0x0000000001645460 in handle_connection (arg=0x43de0e0) at /data/mysql-5.7.17/sql/conn_handler/connection_handler_per_thread.cc:300

#11 0x0000000001cbe494 in pfs_spawn_thread (arg=0x4474250) at /data/mysql-5.7.17/storage/perfschema/pfs.cc:2188

#12 0x00007f3f4e629dc5 in start_thread () from /lib64/libpthread.so.0

#13 0x00007f3f4d4f473d in clone () from /lib64/libc.so.6

是在sql/sql_base.cc:open_table_entry_fini函數(shù)中實(shí)現(xiàn)的添加delete

具體是體現(xiàn)在：

 4345     if (mysql_bin_log.is_open())

 4346     {

 4347       bool error= false;

 4348       String temp_buf;

 4349       error= temp_buf.append("DELETE FROM ");

 4350       append_identifier(thd, &temp_buf, share->db.str, strlen(share->db.str));

 4351       error= temp_buf.append(".");

 4352       append_identifier(thd, &temp_buf, share->table_name.str,

 4353                         strlen(share->table_name.str));

 4354       if (mysql_bin_log.write_dml_directly(thd, temp_buf.c_ptr_safe(),

 4355                                            temp_buf.length()))

 4356         return TRUE;

 4357       if (error)

 4358       {

 4359         /*

 4360           As replication is maybe going to be corrupted, we need to warn the

 4361           DBA on top of warning the client (which will automatically be done

 4362           because of MYF(MY_WME) in my_malloc() above).

 4363         */

 4364         sql_print_error("When opening HEAP table, could not allocate memory "

 4365                         "to write 'DELETE FROM `%s`.`%s`' to the binary log",

 4366                         share->db.str, share->table_name.str);

 4367         delete entry->triggers;

 4368         return TRUE;

 4369       }

直接在mysqlbinlog中寫了delete 語句。

對(duì)于有memory引擎的表，做主從時(shí)可能會(huì)有的問題：

1 邏輯備份：會(huì)dump出來當(dāng)時(shí)memory表里有的內(nèi)容，但他不支持事務(wù)，所以有可能數(shù)據(jù)是不一樣的

2 物理備份：memory的表只有frm文件，所以里面的內(nèi)容一定是空的

所以兩種方式都不能保證可以直接做出來從庫。

最好的方法是：在主從復(fù)制中還是不要使用memory引擎的表。真要用的話，需要了解他的影響。

關(guān)于mysql復(fù)制和內(nèi)存引擎的表是怎么樣的問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。