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

創(chuàng)新互聯(lián)建站專注于企業(yè)成都營(yíng)銷網(wǎng)站建設(shè)、網(wǎng)站重做改版、東安網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、HTML5建站、商城網(wǎng)站定制開發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為東安等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

當(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)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。

分享題目：mysql復(fù)制和內(nèi)存引擎的表是怎么樣的
網(wǎng)址分享：http://aaarwkj.com/article42/gjooec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、移動(dòng)網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、電子商務(wù)、域名注冊(cè)、虛擬主機(jī)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)