mysql復制和內存引擎的表是怎么樣的
MySQL復制和內存引擎的表是怎么樣的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
創新互聯建站專注于企業成都營銷網站建設、網站重做改版、東安網站定制設計、自適應品牌網站建設、HTML5建站、商城網站定制開發、集團公司官網建設、外貿網站制作、高端網站制作、響應式網頁設計等建站業務，價格優惠性價比高，為東安等各大城市提供網站開發制作服務。
當主服務器關閉并重新啟動時，其內存表將變為空。要將此效果復制到從屬服務器，在主服務器啟動后第一次使用給定內存表時，它會記錄一個事件，通知從屬服務器必須通過將該表的DELETE語句寫入二進制日志來清空該表。
當從屬服務器關閉并重新啟動時，其內存表將變為空。這會導致從屬設備與主設備不同步，并可能導致其他故障或導致從屬設備停止：
從主機接收的行格式更新和刪除可能會失敗，因為在“內存表”中找不到記錄。
語句，例如INSERT INTO。。。從內存中選擇\u表可以在主設備和從設備上插入一組不同的行。
當主庫上使用內存引擎的表時，主庫因為某些原因重啟了。啟動好之后，再打開主庫的內存引擎表時，會先把里面的內容清空。所以這個時候主從狀態是正常的。
但當從庫被重啟時，因為memory的內容沒有了，所以可能會出現主從報錯的現象。
實驗：
一 主庫異常關閉：
在主庫上建表
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)
這時再去主庫上觀察：
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)
這時主從的狀態也是正常的。
二 從庫啟常重啟：
主庫上：
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表時， mysqlbinlog中會記錄下面的內容：
# 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函數中實現的添加delete
具體是體現在：
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 語句。
對于有memory引擎的表，做主從時可能會有的問題：
1 邏輯備份：會dump出來當時memory表里有的內容，但他不支持事務，所以有可能數據是不一樣的
2 物理備份：memory的表只有frm文件，所以里面的內容一定是空的
所以兩種方式都不能保證可以直接做出來從庫。
最好的方法是：在主從復制中還是不要使用memory引擎的表。真要用的話，需要了解他的影響。
關于mysql復制和內存引擎的表是怎么樣的問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注創新互聯行業資訊頻道了解更多相關知識。
分享題目：mysql復制和內存引擎的表是怎么樣的
網址分享：http://vcdvsql.cn/article42/gjooec.html
成都網站建設公司_創新互聯，為您提供網站改版、移動網站建設、網站設計、電子商務、域名注冊、虛擬主機
聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯
- 土特產微信小程序商城解決方案 2022-08-14
- 創新互聯分享如何根據用戶心理特點設計網站及解決方案第二課 2021-05-15
- 優化網站欄目和頁面排名的解決方案 2016-09-29
- 美妝行業微信小程序商城解決方案 2022-08-24
- 誰能做好網上商城包括商城網站建設解決方案? 2022-08-08
- 創新互聯干貨分享|DNS解析錯誤的解決方案 2023-02-07
- 網站建設不得不知的托管解決方案 2022-05-01
- 企業網站建設6大注意事項以及解決方案分享 2022-05-10
- 企業級別電子商務網站建設解決方案【哪家好】? 2022-06-17
- 電子商務aPP解決方案 2021-12-12
- 學校/教育培訓類網站解決方案六 2023-02-22
- Sentry企業級數據安全解決方案-Relay運行模式 2022-10-11