問(wèn)題

在Django中使用mysql偶爾會(huì)出現(xiàn)數(shù)據(jù)庫(kù)連接丟失的情況，錯(cuò)誤通常有如下兩種

OperationalError: (2006, 'MySQL server has gone away')
OperationalError: (2013, 'Lost connection to MySQL server during query')

查詢mysql全局變量SHOW GLOBAL VARIABLES;可以看到wait_timeout，此變量表示連接空閑時(shí)間。如果客戶端使用一個(gè)連接查詢多次數(shù)據(jù)庫(kù)，如果連續(xù)查詢則沒(méi)有問(wèn)題，如果查詢幾次后停頓超過(guò)wait_timeout后再次查詢就會(huì)出現(xiàn)數(shù)據(jù)庫(kù)連接丟失。

復(fù)現(xiàn)

下面用Django復(fù)現(xiàn)下次問(wèn)題：

將mysql的wait_timeout設(shè)置為10秒，然后進(jìn)入django shell模擬查詢（以下錯(cuò)誤信息只保留了部分）

In[1]：import time
In[2]：from django.contrib.auth.models import User
In[3]：list(User.objects.filter(id=1))
Out[3]：[<User: admin>]
In[4]：time.sleep(15) # 模擬比較慢的代碼（其中沒(méi)有查詢數(shù)據(jù)庫(kù)的代碼），或者空閑什么都不操作一段時(shí)間，此時(shí)間要比`wait_timeout`大一些
list(User.objects.filter(id=1))
Traceback (most recent call last):

  File "<ipython-input-4-3574ae8220ee>", line 1, in <module>
    list(User.objects.filter(id=1))

  File "/usr/lib/python3.6/site-packages/pymysql/connections.py", line 1037, in _read_bytes
    CR.CR_SERVER_LOST, "Lost connection to MySQL server during query")
django.db.utils.OperationalError: (2013, 'Lost connection to MySQL server during query')

尋求

那么以上問(wèn)題就基本說(shuō)明了是空閑時(shí)間過(guò)長(zhǎng)導(dǎo)致的錯(cuò)誤。

django為了減少不必要的數(shù)據(jù)庫(kù)連接、關(guān)閉，復(fù)用了數(shù)據(jù)庫(kù)連接，當(dāng)開始一個(gè)請(qǐng)求后建立一個(gè)連接池存放連接，之后此次請(qǐng)求都復(fù)用一個(gè)連接。那猜測(cè)就是django保存連接的比wait_timeout長(zhǎng)了，如果保存時(shí)間短一些就可以重新建立連接避免此錯(cuò)誤了。 沒(méi)錯(cuò)，官方文檔也已經(jīng)說(shuō)明了此問(wèn)題，設(shè)置數(shù)據(jù)庫(kù) CONN_MAX_AGE參數(shù)，示例：

DATABASES = {
 "default": {
 'ENGINE': 'django.db.backends.mysql',
 'NAME': '',
 'USER': '',
 'PASSWORD': '',
 'HOST': '',
 'CONN_MAX_AGE': 9 # 比wait_timeout小一些
 }
}

當(dāng)我們測(cè)試后卻發(fā)現(xiàn)，事情并非想想中那么簡(jiǎn)單。為何錯(cuò)誤依舊出現(xiàn)？這一切的背后， 是人性的扭曲還是道德的淪喪?敬請(qǐng)收看下節(jié)《突破》。

突破

對(duì)django源碼中CONN_MAX_AGE進(jìn)行了一番搜索，順藤摸瓜發(fā)現(xiàn)了django關(guān)閉失效連接的方法django.db.close_old_connections()：

# Register an event to reset transaction state and close connections past
# their lifetime.
def close_old_connections(**kwargs):
 for conn in connections.all():
  conn.close_if_unusable_or_obsolete()

signals.request_started.connect(close_old_connections)
signals.request_finished.connect(close_old_connections)

重點(diǎn)在最后兩行，通過(guò)signal實(shí)現(xiàn)特定事件時(shí)執(zhí)行此方法，兩個(gè)特定事件顧名思義是請(qǐng)求開始和請(qǐng)求結(jié)束。而我們報(bào)錯(cuò)的是在一次請(qǐng)求中，所以此法通常無(wú)效，僅僅是實(shí)現(xiàn)每個(gè)請(qǐng)求關(guān)閉并重新建立連接。

解決

復(fù)現(xiàn)問(wèn)題的django shell不要關(guān)閉，繼續(xù)執(zhí)行如下代碼：

In[5]：from django.db import close_old_connections
In[6]：close_old_connections()
In[7]：list(User.objects.filter(id=1))
Out[7]: [<User: admin>]

調(diào)用django.db.close_old_connections后再次查詢就沒(méi)有錯(cuò)誤了。 那么我們要避免此錯(cuò)誤就要執(zhí)行每個(gè)數(shù)據(jù)庫(kù)查詢前調(diào)用django.db.close_old_connections方法。

一般情況不會(huì)出現(xiàn)此類問(wèn)題，因?yàn)橐粋€(gè)請(qǐng)求中不間斷進(jìn)行數(shù)據(jù)庫(kù)查詢，無(wú)需每個(gè)請(qǐng)求調(diào)用此方法，杞人憂天。

有時(shí)候一個(gè)請(qǐng)求中數(shù)據(jù)量較大，會(huì)查詢數(shù)據(jù)庫(kù)后進(jìn)行一段時(shí)間其他（不涉及數(shù)據(jù)庫(kù)）處理，比如先查詢一些數(shù)據(jù)，然后將數(shù)據(jù)處理、生成excel、保存文件并生成url。已知此過(guò)長(zhǎng)需要非常長(zhǎng)時(shí)間，那么最終url保存數(shù)據(jù)庫(kù)就最好先調(diào)用django.db.close_old_connections防止連接丟失

題外話 實(shí)際上②所述情況最好從根本上解決處理慢的問(wèn)題，也可以換作異步處理，從根本上解決問(wèn)題。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論