您好,登錄后才能下訂單哦!
模擬場景:
1.表中無主鍵,全表進行更新:
master:
表結構:
CREATE TABLE `dmpush_message_temp` (
`clientid` varchar(36) DEFAULT NULL,
`infoid` bigint(10) DEFAULT NULL,
`endtime` varchar(14) DEFAULT NULL,
`stat` varchar(8) DEFAULT NULL
) ENGINE=innodb DEFAULT CHARSET=utf8;
mysql> update dmpush_message_temp set stat=1 ;
Query OK, 226651 rows affected (1.69 sec)
Rows matched: 226651 Changed: 226651 Warnings: 0
mysqlbinlog -vvv /home/mysql/data3006/mysql/mysql-bin.000007 >/tmp/test.log
mysql> select 2521492/11;—-11為一個update事務條目占用的行數
+————-+
| 2521492/11 |
+————-+
| 229226.5455 |
+————-+
mysql> use qianyi
Database changed
mysql> select count(*) from dmpush_message_temp;
+———-+
| count(*) |
+———-+
| 226651 |
+———-+
可以看到,binlog的條目數和該表的數據量查不多是一致,也就是在全表更新的時候(在row模式下)更新多少行,就有多少事務的事務條目;
為dmpush_message_temp表添加主鍵:
mysql> alter table dmpush_message_temp add column id int not null auto_increment,add PRIMARY Key(id);
Query OK, 226651 rows affected (1.09 sec)
Records: 226651 Duplicates: 0 Warnings: 0
mysql> update dmpush_message_temp set stat=0 ;
Query OK, 226651 rows affected (1.69 sec)
Rows matched: 226651 Changed: 226651 Warnings: 0
解析binlog中的事務條目:
root@xxxxxxxxx # mysqlbinlog -vvv /home/mysql/data3006/mysql/mysql-bin.000008 >/tmp/test1.log
### UPDATE qianyi.dmpush_message_temp
### WHERE
### @1=’fb5c72c9-0ac2-4800-93b2-b94dc9e1dd54′ /* VARSTRING(108) meta=108 nullable=1 is_null=0 */
### @2=133 /* LONGINT meta=0 nullable=1 is_null=0 */
### @3=’20121012220000′ /* VARSTRING(42) meta=42 nullable=1 is_null=0 */
### @4=’1′ /* VARSTRING(24) meta=24 nullable=1 is_null=0 */
### @5=1 /* INT meta=0 nullable=0 is_null=0 */
### UPDATE qianyi.dmpush_message_temp
### WHERE
### @1=’fb5bdc4f-da8a-4f03-aa5e-27677d7c8ac3′ /* VARSTRING(108) meta=108 nullable=1 is_null=0 */
### @2=133 /* LONGINT meta=0 nullable=1 is_null=0 */
### @3=’20121012220000′ /* VARSTRING(42) meta=42 nullable=1 is_null=0 */
### @4=’1′ /* VARSTRING(24) meta=24 nullable=1 is_null=0 */
### @5=2 /* INT meta=0 nullable=0 is_null=0 */
可以看到這里的事務條目中由于已經有了主鍵,也就是@5(第一個事務條目更新和第二個事務條目更新的@5是遞增的,即主鍵),這樣事務日志就會根據主鍵來更新,備庫執行則不會卡住;
2.這個時候,發現slave已經卡住,無法進行任何操作,這個時候只有強行kill掉mysql進程
root@xxxxxxxx.com # ps -ef|grep 3006
root 4456 1 0 Oct11 ? 00:00:00 /bin/sh /usr/bin/mysqld_safe –defaults-file=/etc/my3006.cnf
mysql 6828 4456 0 Oct11 ? 00:39:27 /usr/sbin/mysqld –defaults-file=/etc/my3006.cnf –basedir=/ –datadir=/home/mysql/data3006/dbs3006 –user=mysql –log-error=/home/mysql/data3006/mysql/master-error.log –open-files-limit=8192 –pid-file=/home/mysql/data3006/dbs3006/xxxxxxxx.com.pid –socket=/home/mysql/data3006/tmp/mysql.sock –port=3006
kill -9 4456 6828
由于我們的slave復制是在mysqld啟動的時候自動啟動,所以這里我們需要將其關閉:
vi /etc/my3006.cnf中加入:skip-slave-start,在用mysqld_safe啟動;
a。slave上執行以下命令:
slave:清空備庫上有問題的表
set sql_log_bin=off;
truncate table qianyi.dmpush_message_temp;
start slave;
跳過該表上的錯誤:
sh /tmp/skip.sh 3006 dmpush_message_temp
b.等備庫追上主庫后,執行以下命令:
master:
lock tables qianyi.dmpush_message_temp read;
create table a2 like qianyi.dmpush_message_temp ;
lock tables a2 write, qianyi.dmpush_message_temp read;
insert into a2 select * from qianyi.dmpush_message_temp ;
slave:
set sql_log_bin=off;
drop table qianyi.dmpush_message_temp;
create table qianyi.dmpush_message_temp like a2;
insert into qianyi.dmpush_message_temp select * from a2;
c.最后讓應用改造,添加上主鍵:
mysql> alter table dmpush_message_temp add column id int not null auto_increment,add PRIMARY Key(id);
3.當slave卡住的時候,可以通過解析binlog來看看,slave到底卡住在那里,是那個事務,下面是一個簡單的方法,來看當前salve打開的表:
mysql> show open tables;
+———-+———————+——–+————-+
| Database | Table | In_use | Name_locked |
+———-+———————+——–+————-+
| qianyi | dmpush_message_temp | 1 | 0 |
| qianyi | test | 0 | 0 |
| qianyi | anson | 0 | 0 |
| mysql | db | 0 | 0 |
| mysql | slow_log | 0 | 0 |
| mysql | event | 0 | 0 |
+———-+———————+——–+————-+
可以看到這里dmpush_message_temp一直處于打開狀態,這里就可以直接定位問題的根源了;
總結:主鍵對于innodb來說,是非常重要的,每張表的設計的時候,都應該把主鍵默認的加上,不管你需不需要他,而且主鍵的設計最好選擇自增型的主鍵,這里也可以略提一下自增主鍵的好處:
a.自增型主鍵以利于插入性能的提高;
b.自增型主鍵設計(int,bigint)可以降低二級索引的空間,提升二級索引的內存命中率;
c.自增型的主鍵可以減小page的碎片,提升空間和內存的使用。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。