1. 程式人生 > >FAQ系列 | 複製執行緒長時間Opening tables

FAQ系列 | 複製執行緒長時間Opening tables

0、導讀

在slave上,發現SQL thread長時間處於Opening tables狀態

1、問題描述

朋友的資料庫,做了主從replication複製。在slave例項上,SQL thread的長時間處於Opening tables狀態,複製程序異常。

mysql> show processlist;

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

| Id | User        | Host      | db   | Command | Time  | State                                  | Info             |

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

|  1 | system user |           | NULL | Connect |   554 | Queueing master event to the relay log | NULL             |

|  2 | system user |           | NULL | Connect | 59212 | Opening tables                         | NULL             |

整個例項大概20個database,總共300G左右。

master是5.5版本,slave是5.6版本,master上執行xtrabackup全庫備份後搭建的slave。

2、原因分析

我的第一反應是table cache是不是太小了,導致open table比較慢,所以才長時間處於這個狀態。無論如何,先一層層排查吧。

先看下slave status(部分無用資訊我隱掉了):

mysql> show slave status\G

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

               Slave_IO_State: Queueing master event to the relay log

              Master_Log_File: master-bin.000618

          Read_Master_Log_Pos: 614915856

               Relay_Log_File: replicate.000008

                Relay_Log_Pos: 2384117

        Relay_Master_Log_File: master-bin.000617

             Slave_IO_Running: Yes

            Slave_SQL_Running: Yes

              Replicate_Do_DB: 

          Replicate_Ignore_DB: 

           Replicate_Do_Table: 

       Replicate_Ignore_Table: 

      Replicate_Wild_Do_Table: 

  Replicate_Wild_Ignore_Table: 

                   Last_Errno: 0

                   Last_Error: 

                 Skip_Counter: 0

          Exec_Master_Log_Pos: 252048331

              Relay_Log_Space: 1438994074

              Until_Condition: None

               Until_Log_File: 

                Until_Log_Pos: 0

        Seconds_Behind_Master: 59240

Master_SSL_Verify_Server_Cert: No

                Last_IO_Errno: 0

                Last_IO_Error: 

               Last_SQL_Errno: 0

               Last_SQL_Error: 

  Replicate_Ignore_Server_Ids: 

             Master_Server_Id: 1

                  Master_UUID: 

             Master_Info_File: /home/mysql/master.info

                    SQL_Delay: 0

          SQL_Remaining_Delay: NULL

      Slave_SQL_Running_State: Opening tables

           Master_Retry_Count: 86400

      Last_IO_Error_Timestamp: 

     Last_SQL_Error_Timestamp: 

           Master_SSL_Crlpath: 

           Retrieved_Gtid_Set: 

            Executed_Gtid_Set: 

                Auto_Position: 0

看不出來有什麼異常的。

再看下系統負載情況:

[[email protected] mysql]# vmstat -S m 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

 0  2      1  19591    458 230576    0    0    11    20    0    0  0  0 100  0  0

 1  1      1  19587    458 230579    0    0  2032  2528 1645  584  1  1 93  4  0

 1  1      1  19583    458 230582    0    0  1664  2712 1773  461  1  1 93  4  0

 0  2      1  19578    458 230585    0    0  2080  3376 1810  660  1  1 93  4  0

 2  0      1  19576    458 230587    0    0  2224  1804 1634  594  1  1 94  4  0

 3  1      1  19569    458 230590    0    0  1968  3488 1693  566  1  1 93  4  0

 1  1      1  19567    458 230593    0    0  2016  2632 1775  515  1  1 93  4  0

[[email protected] mysql]# sar -d 1

Linux 2.6.32-431.el6.x86_64 (localhost.localdomain)     03/21/2015      _x86_64_        (24 CPU)

03:21:57 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util

03:21:58 PM    dev8-0    185.86   5753.54     64.65     31.30      1.20      6.48      5.08     94.44

03:21:58 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util

03:21:59 PM    dev8-0    197.03   6114.85     95.05     31.52      1.16      5.88      4.48     88.32

03:21:59 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util

03:22:00 PM    dev8-0    188.89   5882.83     88.89     31.61      1.14      6.03      5.09     96.16

03:22:00 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util

03:22:01 PM    dev8-0    166.00   5152.00     80.00     31.52      1.42      8.56      5.58     92.70

也看不出來異常,繼續看看mysql的日誌吧:

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'objects_summary_global_by_type' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Incorrect definition of table performance_schema.rwlock_instances: expected column 'WRITE_LOCKED_BY_THREAD_ID' at position 2 to have type bigint(20), found type int(11).

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'setup_actors' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'setup_objects' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'table_io_waits_summary_by_index_usage' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'table_io_waits_summary_by_table' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'table_lock_waits_summary_by_table' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Column count of mysql.threads is wrong. Expected 14, found 3. Created with MySQL 50524, now running 50623. Please use mysql_upgrade to fix this error.

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'events_stages_current' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'events_stages_history' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'events_stages_history_long' has the wrong structure

2015-04-21 15:05:17 7f5997fff700 InnoDB: Error: Table "mysql"."innodb_table_stats" not found.

2015-04-21 15:05:17 7f5997fff700 InnoDB: Error: Fetch of persistent statistics requested for table "db_anonymous_info_10"."t_friend_info_3" but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

2015-04-21 15:05:17 7f7beb0cd700 InnoDB: Error: Table "mysql"."innodb_table_stats" not found.

2015-04-21 15:05:17 7f7beb0cd700 InnoDB: Error: Fetch of persistent statistics requested for table "db_user_trade_1"."t_trade_15" but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

可以看到,這個例項中,P_S(performanc_schema)庫的幾個表結構都異常了。另外,mysql.innodb_table_stats表也異常了,導致InnoDB表資料收集異常,然後SQL thread也跟著異常了。

3、問題解決建議

造成上面問題主要原因是,沒有用正確的方式來部署slave例項。從master上用xtrabackup物理備份到slave,啟動例項後,應該再執行 mysql_upgrade 升級相關表結構,確保P_S(performanc_schema)、I_S(information_schema)以及 mysql 等幾個系統庫表結構都升級到最新版本。

關於MySQL的方方面面大家想了解什麼,可以直接留言回覆,我會從中選擇一些熱門話題進行分享。 同時希望大家多多轉發,多一些閱讀量是老葉繼續努力分享的絕佳助力,謝謝大家 :)

最後打個廣告,運維圈人士專屬鐵觀音茶葉微店上線了,訪問:http://yejinrong.com 或掃描下方二維碼即可直達

640?wx_fmt=png

相關推薦

FAQ系列 | 複製執行時間Opening tables

0、導讀 在slave上,發現SQL thread長時間處於Opening tables狀態 1、問題描述 朋友的資料庫,做了主從replication複製。在slave例項上,SQL thread的長時間處於Opening ta

FAQ系列複製執行時間Opening tables

前言:在slave上,發現SQL thread長時間處於Opening tables狀態 1、問題描述 朋友的資料庫,做了主從replication複製。在slave例項上,SQL thread的長時間處於Opening tables狀態,複製程序異常。 整個例項大概20個database,總共3

furtureTask 避免主執行時間阻塞

 某些情況下,你的需求列表中的某一個子任務所花費的時間可能是你不能控制,不能預知的(譬如url獲取請求資料)。有的時候它很快,有的時侯得到結構需要花費你預料以外的很長時間,最終阻塞了你的主執行緒,使得你的主執行緒快慢依賴於這個看起來並不那麼重要的功能。也許你需要給這個子任務

Windbg程式除錯系列3-執行阻塞問題

上一篇博文給大家分享了使用Windbg分析記憶體洩露問題: Windbg程式除錯系列2-記憶體洩露問題 本篇我們繼續跟大家分享,如何分析解決執行緒阻塞問題。 從根本上講,執行緒阻塞屬於程式Hang的一種,其表現主要有: 1. 隨著請求的增加,執行緒數一直增加,可能會把執行緒池打爆

Python 學習系列 -- 多執行

轉載自:https://www.cnblogs.com/yeayee/p/4952022.html 多執行緒和多程序是什麼自行google補腦,廖雪峰官網也有,但是不夠簡潔,有點暈,所以就整個簡單的範例。   對於python 多執行緒的理解,我花了很長時間,搜尋的大部份文章都不夠

[Xcode10 實際操作]八、網路與多執行-(20)時間控制元件Timer定時功能

本文將演示時間控制元件Timer定時功能的使用。 在專案導航區,開啟檢視控制器的程式碼檔案【ViewController.swift】 1 import UIKit 2 3 class ViewController: UIViewController { 4 5 ove

Java多執行系列--“JUC執行池”01之 執行池架構

概要 前面分別介紹了”Java多執行緒基礎”、”JUC原子類”和”JUC鎖”。本章介紹JUC的最後一部分的內容——執行緒池。內容包括: 執行緒池架構圖 執行緒池示例 執行緒池架構圖 執行緒池的架構圖如下: 1、Executor

併發系列(五)-----執行詳解

一 簡介 執行緒這個話題,不管是在面試中還是在工作中會經常的遇見。而併發程式設計的目的就是為了在儘量不影響程式的執行效率的情況下保證資料的安全性和正確性。要想理解執行緒首先要明白一些概念性的東西。 程序:具有一定獨立功能的程式關於某個資料集合上的一次執行活動,程序是系統進行資源分配和排程

Java多執行系列--“JUC執行池”05之 執行池原理(四)

概要 本章介紹執行緒池的拒絕策略。內容包括: 拒絕策略介紹 拒絕策略對比和示例 拒絕策略介紹 執行緒池的拒絕策略,是指當任務新增到執行緒池中被拒絕,而採取的處理措施。 當任務新增到執行緒池中之所以被拒絕,可能是由於:第一,執行緒池異常關閉。第二,任務數量

學習筆記-python守護執行時間延遲

python守護執行緒和時間延遲 也許我們存在這種需求,有些執行緒是處於監聽功能的執行緒,希望其一直執行下去,直到關機,那麼對於一個程式而言,在啟動之後一個程序裡面可以存在很多個執行緒,其他執行緒先執行完成,如果存在某個執行緒需要一直執行,那麼這個程式就無法退出,此時就需要守護執行緒這種

C1X 系列 : 多執行 (N1494)

感謝林永聽投遞本文。  校對:方騰飛 1. 關於 C1X 標準 C1X 是 C 語言的下一個標準,用於取代現有的 C99 標準。 C1X 是一個非正式名字,該標準仍在制訂中,最新的工作草案是 N1494 ,釋出於 2010 年 6 月。與 C99 相比, C1X 在語言和庫上有顯著的變化,本文

【原創】技術系列執行(一)

作者:CppExplore 網址:http://www.cppblog.com/CppExplore/廢話不多說,詳細介紹使用執行緒的優點好處請參考baidu、google。一、執行緒使用場景。使用執行緒的方式大致有兩種:(1)流水線方式。根據業務特點,將一個流程的處理分割成多個執行緒,形成流水線的處

Java 多執行設定執行超時時間之 Callable介面和Future介面 超時控制

Callable介面和Future介面介紹         在Java中,如果需要設定程式碼執行的最長時間,即超時,可以用Java執行緒池ExecutorService類配合Future介面來實現。 Future介面是Java標準API的一部分,在java.uti

Linux下從訊號量看執行排程時間

前幾天寫了一篇文章關於Linux下程序排程時間的,本意是想測試下實時效能的,包括中斷響應時間等等,這個可能需要藉助於硬體發出終端來測試, 那片文章是講的是通過傳送訊號給另一個程序,然後測量傳送訊號到進入訊號處理程式之間的時間 訊號只是針對程序來說的,今天

Java 多執行設定執行超時時間之 Callable介面和Future介面

Callable介面和Future介面介紹         在Java中,如果需要設定程式碼執行的最長時間,即超時,可以用Java執行緒池ExecutorService類配合Future介面來實現。 Future介面是Java標準API的一部分,在java.util.co

C#基礎系列——多執行的常見用法詳解

前言:前面幾節分別介紹了下C#基礎技術中的反射、特性、泛型、序列化、擴充套件方法、Linq to Xml等,這篇跟著來介紹下C#的另一基礎技術的使用。最近專案有點緊張,所以準備也不是特別充分。此篇就主要從博主使用過的幾種多執行緒的用法從應用層面大概介紹下。文中觀點都是博主個人的理解,如果有不對的地方望大家指正

IOS執行程式時間誤動作時自動退出

概述 先講講原理。我建立了一個 UIApplication 的子類ELCUIApplication。目的是為了覆蓋 sendEvent: 方法。這個方法在每次觸控時都會呼叫。觸控可能來自於按鈕、文字框以至視窗內的任何東西。 在 sendEvent 方法中,首先呼叫 super 的方法(確保事件能被傳遞

Java併發程式設計系列(一)-執行的基本使用

最近在學習java併發程式設計基礎.一切從簡,以能理解概念為主. 併發程式設計肯定繞不過執行緒.這是最基礎的. 那麼就從在java中,如何使用執行緒開始. 繼承Thread類 繼承Thread類,重寫run方法,new出物件,呼叫start方法. 在新啟的執行緒裡執行的就是重寫的run方法. 1 /**

java併發包學習系列執行複用之執行

什麼是執行緒池 頻繁使用new Thread來建立執行緒的方式並不太好。因為每次new Thread新建和銷燬物件效能較差,執行緒缺乏統一管理。好在Java提供了執行緒池,它能夠有效的管理、排程執行緒,避免過多的資源消耗。優點如下: 重用存在的執行緒,減少物

GetThreadTimes獲取其它執行cpu時間

http://www.cnblogs.com/eaglet/archive/2009/03/11/1408809.html 鄙視下上面的垃圾博文,純粹忽悠人 參考文章: http://blog.kalmbachnet.de/?postid=28 這是一個德國人寫的部落格,我