本文目錄一覽：
MYSQL數據庫 更新表數據
mysql 數據庫，更新字段語句：
一、UPDATE：
UPDATE的功能是更新表中的數據。這的語法和INSERT的第二種用法相似。必須提供表名以及SET表達式，在後面可以加WHERE以限制更新的記錄範圍。
UPDATE table_anem SET column_name1 = value1, column_name2 = value2, …
WHERE … 。
如下面的語句將users表中id等於123的記錄的age改為24。
UPDATE users SET age = 24 WHERE id = 123。
mysql更新問題
UPDATE categories
SET dingdan = CASE id
WHEN 1 THEN 3
WHEN 2 THEN 4
WHEN 3 THEN 5
END,
title = CASE id
WHEN 1 THEN ‘New Title 1’
WHEN 2 THEN ‘New Title 2’
WHEN 3 THEN ‘New Title 3’
END
WHERE id IN (1,2,3)
更新dingdan 字段，如果id=1 則dingdan 的值為3，如果id=2 則dingdan 的值為4…
更新title 字段，如果id=1 則title 的值為’New Title 1’，如果id=2 則title 的值為’New Title 2′
詳情參考網頁鏈接
MYSQL數據庫更新問題!!
url=,
===================
這個地方有錯.忘記加單引號.url字段肯定是字符串類型的.所以要用引號括上.
url=”,
如何處理mysql數據庫並發更新問題
現象
Sysbench對MySQL進行壓測, 並發數過大(5k)時, Sysbench建立連接的步驟會超時.
猜想
猜想: 直覺上這很簡單, Sysbench每建立一個連接, 都要消耗一個線程, 資源消耗過大導致超時.
驗證: 修改Sysbench源碼, 調大超時時間, 仍然會發生超時.
檢查環境
猜想失敗, 回到常規的環境檢查:
MySQL error log 未見異常.
syslog 未見異常.
tcpdump 觀察網絡包未見異常, 連接能完成正常的三次握手; 只觀察到在出問題的連接中, 有一部分的TCP握手的第一個SYN包發生了重傳, 另一部分沒有發生重傳.
自己寫一個簡單的並發發生器, 替換sysbench, 可重現場景. 排除sysbench的影響
猜想2
懷疑 MySQL 在應用層因為某種原因, 沒有發送握手包, 比如卡在某一個流程上:
檢查MySQL堆棧未見異常, 彷彿MySQL在應用層沒有看到新連接進入.
通過strace檢查MySQL, 發現 accept() 調用確實沒有感知到新連接.
懷疑是OS的原因, Google之, 得到參考文檔: A TCP “stuck” connection mystery【】
分析
參考文檔中的現象跟目前的狀況很類似, 簡述如下:
正常的TCP連接流程:
Client 向 Server 發起連接請求, 發送SYN.
Server 預留連接資源, 向 Client 回復SYN-ACK.
Client 向 Server 回復ACK.
Server 收到 ACK, 連接建立.
在業務層上, Client和Server間進行通訊.
當發生類似SYN-flood的現象時, TCP連接的流程會使用SYN-cookie, 變為:
Client 向 Server 發起連接請求, 發送SYN.
Server 不預留連接資源, 向 Client 回復SYN-ACK, 包中附帶有簽名A.
Client 向 Server 回復ACK, 附帶 f(簽名A) (對簽名進行運算的結果).
Server 驗證簽名, 分配連接資源, 連接建立.
在業務層上, Client和Server間進行通訊.
當啟用SYN-cookie時, 第3步的ACK包因為 某種原因 丟失, 那麼:
從Client的視角, 連接已經建立.
從Server的視角, 連接並不存在, 既沒有建立, 也沒有”即將建立” (若不啟用SYN-cookie, Server會知道某個連接”即將建立”)
發生這種情況時:
若業務層的第一個包應是從 Client 發往 Server, 則會進行重發或拋出連接錯誤
若業務層的第一個包應是從 Server 發往 Client的, Server不會發出第一個包. MySQL的故障就屬於這種情況.
TCP握手的第三步ACK包為什麼丟失
參考文檔中, 對於TCP握手的第三步ACK包的丟失原因, 描述為:
Some of these packets get lost because some buffer somewhere overflows.
我們可以通過Systemtap進一步探究原因. 通過一個簡單的腳本:
probe kernel.function(“cookie_v4_check”).return
{
source_port = @cast($skb-head + $skb-transport_header, “struct tcphdr”)-source
printf(“source=%d, return=%d\n”,readable_port(source_port), $return)
}
function readable_port(port) {
return (port ((19)-1)) 8 | (port 8)
}
觀察結果, 可以確認cookie_v4_check (syn cookie機制進行包簽名檢查的函數)會返回 NULL(0). 即驗證是由於syn cookie驗證不通過, 導致TCP握手的第三步ACK包不被接受.
之後就是對其中不同條件進行觀察, 看看是哪個條件不通過. 最終原因是accept隊列滿(sk_acceptq_is_full):
static inline bool sk_acceptq_is_full(const struct sock *sk){ return sk-sk_ack_backlog sk- sk_max_ack_backlog;}
恢復故障與日誌的正關聯
在故障處理的一開始, 我們就檢查了syslog, 結論是未見異常.
當整個故障分析完成, 得知了故障與syn cookie有關, 回頭看syslog, 裡面是有相關的信息, 只是和故障發生的時間不匹配, 沒有正關聯, 因此被忽略.
檢查Linux源碼:
if (!queue-synflood_warned
sysctl_tcp_syncookies != 2
xchg(queue-synflood_warned, 1) == 0)
pr_info(“%s: Possible SYN flooding on port %d. %s.
Check SNMP counters.\n”,
proto, ntohs(tcp_hdr(skb)-dest), msg);
可以看到日誌受到了抑制, 因此日誌與故障的正關聯被破壞.
粗看源碼, 每個listen socket只會發送一次告警日誌, 要獲得日誌與故障的正關聯, 必須每次測試重啟MySQL.
解決方案
這種故障一旦形成, 難以檢測; 系統日誌中只會出現一次, 在下次重啟MySQL之前就不會再出現了; Client如果沒有合適的超時機制, 萬劫不復.
解決方案:
1. 修改MySQL的協議, 讓Client先發握手包. 顯然不現實.
2. 關閉syn_cookie. 有安全的人又要跳出來了.
3. 或者調高syn_cookie的觸發條件 (syn backlog長度). 降低系統對syn flood的敏感度, 使之可以容忍業務的syn波動.
有多個系統參數混合影響syn backlog長度, 參看【】
下圖為精華總結
請點擊輸入圖片描述
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/250875.html
微信掃一掃 
支付寶掃一掃 