FiveM MySQL Server Has Gone Away Error 2006 แก้อย่างไร? ตรวจ Connection หลุด, wait_timeout, max_allowed

FiveM MySQL Server Has Gone Away Error 2006 แก้อย่างไร? ตรวจ Connection หลุด, wait_timeout, max_allowed_packet และ Database Restart

August 17, 2026

ปัญหา FiveM MySQL/MariaDB ขึ้น MySQL server has gone away หรือ Error 2006 หมายความว่า Connection ระหว่าง FiveM Resource กับ Database ที่เคยใช้งานอยู่ ไม่สามารถใช้งานต่อได้แล้ว เช่น Connection ถูก Server ปิด, Database Restart, Connection ถูกปล่อย Idle นานเกิน Timeout หรือเกิดปัญหาระหว่างส่งข้อมูลขนาดใหญ่

MariaDB Documentation แสดงตัวอย่าง Error:


ERROR 2006 (HY000): MySQL server has gone away

และยืนยันว่าการหมดอายุของ Connection/Transaction Timeout สามารถทำให้ Connection ถูกปิดจน Client ได้ Error 2006.

ตัวอย่างที่อาจพบใน FiveM Console:


MySQL server has gone away


Error 2006


ER_SERVER_GONE_ERROR


Database connection lost


Connection closed


Connection terminated unexpectedly

ปัญหานี้อาจเกี่ยวข้องกับ:

MariaDB Restart
Database Server Crash
Connection Idle นาน
wait_timeout
Connection Pool ใช้ Connection เก่าที่ถูกปิด
Query/Packet ใหญ่
max_allowed_packet
Network ระหว่าง FiveM กับ Remote Database
Hosting Restart
Container Restart
Resource Database Wrapper
Transaction ที่เปิดทิ้งไว้นาน

หลักสำคัญคือ:

อย่าเห็น Error 2006 แล้วเพิ่ม max_allowed_packet หรือ wait_timeout ทันที

ต้องหาก่อนว่า Connection หายเพราะอะไร

① FiveM MySQL Server Has Gone Away คืออะไร

หมายถึง Client พยายามใช้ Database Connection แต่ Connection นั้นไม่สามารถใช้งานกับ MariaDB Server ต่อได้แล้ว

MariaDB Documentation แสดงชัดว่าการ Timeout ของ Session/Transaction สามารถทำให้ Query ถัดไปได้รับ:


ERROR 2006 (HY000): MySQL server has gone away

② Error 2006 เป็น SQL Syntax Error หรือไม่

ไม่ใช่

SQL Syntax Error ที่พบทั่วไปคือ Error 1064

ส่วน Error 2006 เกี่ยวกับ Connection/Session ที่หายไป

③ ต่างจาก Too Many Connections 1040 อย่างไร

Error 1040

Database ยังทำงาน แต่ไม่รับ Connection ใหม่เพราะ Connections เต็ม

Error 2006

Connection ที่ Client ต้องการใช้งานไม่สามารถใช้ต่อได้แล้ว

④ ต่างจาก Connection Refused อย่างไร

Connection Refused มักเกิดตอน Client พยายามสร้าง Connection แต่เข้าถึง Service ไม่ได้

ส่วน Server Has Gone Away สามารถเกิดกับ Connection ที่เคยเปิดและใช้งานมาก่อนแล้ว

⑤ ต่างจาก Lost Connection Error 2013 อย่างไร

Error 2006 และ Error 2013 อยู่ในกลุ่มอาการ Connection ระหว่าง Client กับ Server หาย แต่ Context ของ Client/Operation ที่รายงาน Error อาจต่างกัน

ดังนั้นต้องอ่านข้อความเต็มและดู Timeline ไม่ควรแก้จาก Error Number อย่างเดียว

⑥ สาเหตุแรกที่ควรตรวจ — MariaDB Restart

ถ้า MariaDB ถูก Restart:

Connections ที่ FiveM เคยเปิดไว้จะไม่สามารถใช้ Session เดิมต่อได้

⑦ ตัวอย่าง


FiveM
↓
MariaDB connection #20
↓
MariaDB restart
↓
connection #20 หาย
↓
FiveM resource ใช้ connection เดิม
↓
Server has gone away

⑧ ตรวจ MariaDB Uptime

ถ้ามีสิทธิ์ สามารถตรวจ Server Status เพื่อดูว่า Database เพิ่ง Restart หรือไม่ โดย MariaDB มี Status Variables รวมถึง Uptime.

ตัวอย่าง:


SHOW GLOBAL STATUS LIKE 'Uptime';

⑨ ถ้า Uptime ต่ำผิดปกติ

เช่น Serverควรเปิดมาหลายวันแต่ Uptimeเพียงไม่กี่นาที

ควรตรวจ:

MariaDB Restart
Crash
Hosting Restart
Container Restart

ก่อนแก้ FiveM Resource

⑩ Error เกิดพร้อมกันทุก Resource

ถ้า:

Garage
Banking
Inventory
Phone

ขึ้น Database Error พร้อมกันในวินาทีเดียว

ควรสงสัย Database Connection ระดับระบบก่อน

⑪ Error เกิด Resource เดียว

ถ้า Resources อื่น Query ได้ปกติ:

อาจเป็น:

Connection Pool ของ Resourceนั้น
Queryเฉพาะ
Resource Database Clientเฉพาะ

⑫ อย่า Restart FiveM ก่อนเก็บหลักฐาน

ถ้า Restartทันที คุณอาจเสียข้อมูลสำคัญ เช่น:

Error Timeline
Database Uptime
Process State

⑬ สาเหตุสำคัญ — `wait_timeout`

MariaDB มี wait_timeout สำหรับกำหนดระยะเวลาที่ Server รอ Connection ที่ไม่มี Activity ก่อนปิด Connection นั้น.

⑭ Connection Idle คืออะไร

หมายถึง Connection เปิดอยู่แต่ไม่มี Activity ตามช่วงเวลาที่ Serverใช้พิจารณา Timeout

⑮ ตัวอย่าง


connection เปิด
↓
ไม่มี query นาน
↓
wait_timeout หมด
↓
MariaDB ปิด connection
↓
pool ยังพยายาม reuse
↓
Error 2006

⑯ นี่เป็นปัญหาของ Connection Pool ได้

Pool อาจเก็บ Connection ไว้สำหรับ Reuse

ถ้า MariaDB ปิด Connection ไปแล้ว แต่ Client/Pool ไม่ตรวจหรือ Reconnectอย่างเหมาะสม:

Queryถัดไปอาจเจอ Connection Error

⑰ แก้ด้วยเพิ่ม wait_timeout สูงมากได้ไหม

ไม่ควรเริ่มแบบนั้น

เพราะ Pool/Database Wrapper ที่ดีควรจัดการ Lifecycle และ Reconnectionตามที่ Libraryออกแบบ

⑱ ตั้ง wait_timeout หลายวันแก้ทุกอย่างไหม

ไม่

ถ้า Root Causeคือ:

MariaDB Crash
Network
Packetใหญ่
Container Restart

การเพิ่ม Timeoutไม่ได้ช่วย

⑲ ตรวจค่า wait_timeout

ใช้:


SHOW VARIABLES LIKE 'wait_timeout';

หรือ:


SELECT @@wait_timeout;

MariaDB ระบุ wait_timeout เป็นหนึ่งใน Server System Variables ที่เกี่ยวกับ Connection Timeout.

⑳ `interactive_timeout` คืออะไร

MariaDB ยังมี interactive_timeout สำหรับ Interactive Connections โดยเอกสารแยกจาก wait_timeout.

㉑ FiveM ใช้ตัวไหน

ต้องดู Database Client/Connector จริง

อย่าปรับทั้งสองค่าจากการเดา

㉒ Resource Database Wrapper สำคัญมาก

FiveM Serverอาจใช้ Database Wrapper ที่มี:

Pool
Reconnect Logic
Timeout
Queue

อยู่แล้ว

㉓ อย่าเปิด Raw Connection เพิ่มเอง

ถ้า Resource Ecosystem มี Wrapperหลักอยู่แล้ว

เพราะอาจสร้าง Connection Managementสองชั้น

㉔ Errorหลังเปลี่ยน Database Wrapper

ตรวจ:

Connection String
Pool Settings
Reconnect behavior
Resource compatibility

㉕ Errorหลัง Update Wrapper

ถ้า Errorเริ่มทันทีหลัง Update:

ตรวจ Changelogและ Configurationของ Versionนั้น

㉖ Resource เก่าอาจไม่รองรับ Wrapper ใหม่

โดยเฉพาะ Custom Database Calls

㉗ Errorหลัง Database Idle หลายชั่วโมง

นี่เป็น Patternที่ควรตรวจ wait_timeout

เช่น:

Serverไม่มี Playerช่วงกลางคืน

เช้าวันถัดมา Playerคนแรกเข้า

Resourceแรกที่ Query Databaseเจอ:


MySQL server has gone away

㉘ ถ้า Query ครั้งถัดไปกลับมาทำงาน

อาจเป็น Poolตรวจพบ Connectionเก่าแล้วสร้าง Connectionใหม่

แต่ยังควรตรวจว่า Wrapperควร Handleกรณีนี้โดยไม่ปล่อย Errorหรือไม่

㉙ Errorทุกครั้งหลัง Idle

เป็น Patternที่ชัด

ตรวจ:

Server wait_timeout
Pool idle handling
Connection lifetime

㉚ อย่าแก้ด้วย Query `SELECT 1` ทุกวินาทีทันที

Keepaliveที่ถี่เกินอาจเพิ่ม Query Loadโดยไม่จำเป็น

㉛ Pool บางตัวมี Connection Validation

ใช้ Featureตาม Libraryที่ใช้อยู่จริงดีกว่า Custom Ping Loop

㉜ สาเหตุสำคัญอีกตัว — `max_allowed_packet`

MariaDB กำหนด max_allowed_packet เป็นขนาดสูงสุดของ Packet หรือ Generated/Intermediate String ที่ Serverรองรับ.

㉝ Packet คืออะไรแบบง่าย

ข้อมูลที่ Client และ Database ส่งถึงกันมีขนาด

Queryหรือข้อมูลที่ใหญ่มากอาจชน Limitของ Connection Protocol/Server Configuration

㉞ FiveM อะไรทำ Query ใหญ่ได้

ตัวอย่าง:

Character Appearance JSON
Vehicle Properties
Inventory JSON
Housing Furniture
Phone Messages
Metadata
Huge Logs

㉟ Inventory JSON ใหญ่มาก

ถ้า Resource Serialize Inventoryทั้งหมดเป็น JSONหนึ่งก้อน:

ขนาดสามารถเพิ่มตาม Items/Metadata

㊱ Vehicle Properties

Custom Vehicle Resourceอาจเก็บ:

Mods
Colors
Damage
Extras

ใน JSON

แต่โดยทั่วไปข้อมูลรถหนึ่งคันไม่ควรใหญ่ผิดปกติจนรีบเพิ่ม Packet Limitมหาศาลโดยไม่ตรวจ

㊲ Housing Furniture

ถ้า Houseมี Objectsจำนวนมากและ Resourceบันทึกทั้งหมดใน JSONหนึ่ง Field:

Payloadอาจใหญ่ขึ้นมาก

㊳ Phone Data

อย่า Serialize Messagesทั้งหมดของผู้เล่นลง Rowเดียวหาก Resourceไม่ได้ออกแบบเช่นนั้น

ใช้ Schemaตาม Resourceจริง

㊴ Logsใหญ่ผิดปกติ

ถ้า Resourceสร้าง SQL Statementขนาดมหาศาล:

ควรตรวจ Architectureก่อนเพิ่ม Packet Limit

㊵ ตรวจ max_allowed_packet

ใช้:


SHOW VARIABLES LIKE 'max_allowed_packet';

MariaDB Documentation ระบุ Variable นี้เป็นขนาดสูงสุดของ Packet/Intermediate String.

㊶ เพิ่ม max_allowed_packet ได้ไหม

ทำได้เมื่อพิสูจน์แล้วว่า Workloadต้องรองรับ Payloadที่ใหญ่ขึ้นจริง

แต่ไม่ควรใช้เป็น Fixเริ่มต้นของ Error2006ทุกกรณี

㊷ ถ้า Queryเล็กมากแต่ Server Gone Away

Packet Limitมีโอกาสน้อยลง

ให้ตรวจ:

Restart
Timeout
Network

ก่อน

㊸ ถ้า Errorเกิดเฉพาะ Save Characterบางคน

น่าสงสัย Data Sizeเฉพาะ Recordนั้น

㊹ ตัวอย่าง

Character A:


inventory JSON = 20 KB

Character B:


inventory JSON = หลายสิบ MB

ถ้า B Errorคนเดียว:

ตรวจ Dataผิดปกติ

㊺ อย่าเพิ่ม Packet Limitเพื่อรองรับ Inventoryที่โตจาก Dupe/Bug

แก้ Resource/Dataก่อน

㊻ Double Serializationทำ Dataโตได้

ตัวอย่าง:


JSON
↓
encode
↓
เก็บเป็น string
↓
encode stringอีกครั้ง

ทำให้ Payloadไม่เป็น Structureที่คาดและสามารถโตขึ้น

㊼ ตรวจ Recordที่ Error

เปรียบเทียบกับ Recordปกติ

㊽ Errorเฉพาะ Vehicleหนึ่งคัน

ตรวจ Vehicle JSON

㊾ Errorเฉพาะ Houseหนึ่งหลัง

ตรวจ Furniture/Object Data

㊿ Errorเฉพาะ Inventoryหนึ่งคน

ตรวจ:

Metadata
Invalid Item Data
Duplicate Records

51. อย่าลบ Characterทันที

Dataผิดปกติสามารถ Diagnoseได้

52. Backup Recordก่อนแก้

โดยเฉพาะ Player Assets

53. สาเหตุ — MariaDB Crash

ถ้า Database Processหยุด:

Connectionsทั้งหมดหาย

54. FiveMจึงขึ้น Error2006ได้เป็นชุด

หลัง Databaseกลับมา Resourceอาจ Reconnect

55. ต้องหาเหตุผลว่า Databaseหยุดเพราะอะไร

เช่น:

OOM
Server reboot
Manual restart
Crash

ไม่ควรสรุปโดยไม่มี Logs

56. ตรวจ MariaDB Error Log

เป็นแหล่งสำคัญเมื่อสงสัย Database Crash

57. ถ้า Database Restartทุกวันเวลาเดียวกัน

ตรวจ:

Hosting maintenance
Cron
Backup
Automated restart

58. อย่าตั้ง FiveM Auto Restartให้ Restart MariaDBด้วยโดยไม่จำเป็น

สอง Serviceมี Lifecycleต่างกัน

59. Database Container

ถ้าใช้ Docker/Container:

Container Restartทำ Connectionsเดิมหาย

60. ตรวจ Container Restart Count/Logs

ถ้า Environmentรองรับ

61. Pterodactyl Database Remote

หาก FiveMกับMariaDBอยู่คนละ Host:

Network Pathเพิ่มเข้ามาเป็นอีกปัจจัย

62. Network Interruptionทำ Connectionหายได้

เช่น:

Firewall reset
NAT timeout
Router issue
Host network interruption

แต่ต้องดู Network/Server Logsก่อนสรุป

63. Errorเกิดเฉพาะ Remote DB

ถ้า Local MariaDBไม่เคยเกิดแต่ Remoteเกิด:

Network/Infrastructureควรถูกตรวจเพิ่ม

64. Pingปกติไม่ได้แปลว่า Database Connectionไม่เคยหลุด

PingและTCP Database Sessionเป็นคนละ Layer

65. อย่าแก้ด้วยเปลี่ยน DNSทันที

ถ้า Connectionถูกสร้างจาก IPตรงหรือ DNSไม่ได้เป็นต้นเหตุ

66. Firewall Idle Timeout

Infrastructureบางแบบสามารถตัด TCP Sessionที่ Idleนาน

หากอยู่หลัง Proxy/NAT/Firewall

67. จึงต้องดูทั้ง Database TimeoutและNetwork Timeout

กรณี Remote DB

68. Errorหลัง Hosting Migration

ตรวจ:

Database Host
Port
SSL
Connection Pool
Timeouts

69. Connection Stringเก่า

FiveMอาจยังชี้ DBเก่า

แล้ว DBเก่าถูก Shutdownภายหลัง

70. Errorอาจดูเหมือนสุ่ม

แต่จริง ๆ Resourceบางตัวใช้ Connection Stringอีกตัว

71. Search Database Configทั้งหมด

ตรวจว่าไม่ได้มี:

Core DBใหม่
Resourceเก่าชี้ DBเก่า

พร้อมกัน

72. Phone Resourceอาจใช้ Databaseแยก

73. Logs Resourceอาจใช้ Databaseแยก

74. อย่าคิดว่า Resourcesทั้งหมดใช้ DBเดียวกันเสมอ

75. Errorเฉพาะ Resourceเดียวจึงควรตรวจ Connection Configของมัน

76. Errorหลัง Password Change

Connectionใหม่อาจ Authentication Fail

แต่ Existing Connectionsอาจยังทำงานจนหลุด

หลังจากนั้น Reconnectไม่ได้

ในกรณีนั้นอาจเห็น Errorอื่นร่วม เช่น Access Denied

77. อ่าน Errorต่อเนื่อง

อย่าแก้จาก 2006บรรทัดเดียว

78. Errorหลัง Database Restartแล้วตามด้วย1045

แสดงว่า Reconnectพยายามเกิดแล้วแต่ Credentialsมีปัญหาได้

79. Errorหลัง Database Restartแล้วตามด้วย1049

อาจ Database Nameผิด/Databaseหาย

80. Error Chainมีข้อมูลมาก

เก็บ Consoleประมาณช่วงก่อนและหลังปัญหา

81. `Aborted_clients`

MariaDBมี Server Status Variablesเกี่ยวกับ Connectionsที่ถูกยกเลิก/ปิดผิดปกติ ซึ่งสามารถช่วยประกอบการตรวจ Connection Problemsได้.

82. แต่ Counterเดียวไม่บอก Root Causeทั้งหมด

ต้องดูร่วมกับ:

Logs
Timing
Processlist

83. Error2006หลัง Too Many Connections1040

เป็นไปได้ไหม

ได้ในเชิงเหตุการณ์ระบบ เช่น Database Load/Connection Managementมีปัญหาหลายอย่างพร้อมกัน

แต่ 1040ไม่ได้แปลว่าจะสร้าง2006โดยตรงทุกครั้ง

84. ตรวจลำดับเวลา

ถ้าเห็น:


1040
↓
Database restart
↓
2006

อาจ Databaseถูก Restartหลัง Connectionsเต็ม

85. ถ้าเห็น:


2006
↓
1040

อาจ Resources Reconnectจำนวนมากจนชน Connection Limit

86. Reconnect Storm

Databaseกลับมา

Resourcesจำนวนมากพยายาม Reconnectพร้อมกัน

Connectionsพุ่งสูง

87. Poolควรจัด Reconnectอย่างควบคุม

ตาม Designของ Database Library

88. อย่าเพิ่ม Custom Infinite Retry Loop

เช่น:


while connection fails:
    reconnect immediately

ไม่มี Delay/Limit

89. เพราะ Databaseที่กำลัง Recoverจะถูกยิง Connectionsซ้ำ

90. Backoffช่วยได้

แต่ควรใช้ Implementationของ Libraryเมื่อมี

91. Error2006หลัง Queryยาวนาน

อาจ Database/Infrastructure Timeoutระหว่าง Operation

ต้องดู:

Query duration
Server logs
Connection settings

92. ไม่ควรเพิ่มทุก Timeoutพร้อมกัน

เพราะจะไม่รู้ว่าตัวไหนเป็น Root Cause

93. Query Optimizationยังสำคัญ

ถ้า Queryใช้เวลานานผิดปกติ:

แก้ Query/Index/Data Modelก่อนปรับ Timeoutแบบรุนแรง

94. Error2006กับLock Wait

Transactionอาจรอ Lockนาน

แต่ Errorปกติของ Lock Waitคือ1205

หาก Connectionถูกปิดระหว่างรอจากเหตุอื่นจึงอาจเห็น Connection Errorตามมา

95. อย่าปะปน Error Numbers

1205

Lock Wait Timeout

1213

Deadlock

2006

Connectionหาย

96. Error2006กับServer Shutdown

หาก MariaDBถูก Shutdownจริง:

Connectionsจะหาย

นี่เป็น Infrastructure Problem

97. ตรวจ System Logs

ถ้ามีสิทธิ์ Server

ดูเวลาที่ MariaDB:

Started
Stopped
Restarted

98. DirectAdmin/Hosting

หาก Databaseถูก Hostingจัดการ:

อาจต้องใช้ Panelหรือส่ง Logsให้ Provider

99. Resourceอาจทำให้ Database Crashได้ไหม

Query Loadหนักมากสามารถสร้าง Resource Pressure

แต่ไม่ควรกล่าวว่า Resourceหนึ่งทำ MariaDB Crashจนกว่าจะมี Logs/Resource Metricsยืนยัน

100. OOM คืออะไร

Operating Systemอาจมีปัญหา Memoryไม่พอและจัดการ Processตามสภาวะระบบ

ถ้า MariaDBถูกหยุดเพราะ Memory:

Root Fixคือ Capacity/Configuration/Workload

ไม่ใช่ FiveM Cache

101. เพิ่ม max_allowed_packetสูงมากใช้ RAMไหม

Packet/Connection configurationมีผลต่อ Resource Planning จึงไม่ควรตั้งขนาดมหาศาลโดยไม่มีเหตุผล

102. MariaDB Memory Planning

MariaDB Documentationเน้นว่า Memory Usageขึ้นกับ Global/Per-connection Buffersและ Workloadหลายส่วน จึงควร Tuneด้วยภาพรวม ไม่ใช่เพิ่ม Variablesแบบแยกส่วน.

103. Errorเฉพาะตอน Import SQL

SQL Dumpอาจมี Statementใหญ่มาก

104. Bulk INSERTหนึ่ง Statement

เช่น:


INSERT INTO logs VALUES (...), (...), (... thousands ...)

สามารถสร้าง Packetใหญ่

105. Import Toolสามารถแบ่ง Statementsได้ไหม

ขึ้นกับ Tool

แต่ถ้าเป็น Migrationของ Resourceให้ใช้ Methodที่ Developerแนะนำ

106. ไม่ควรเพิ่ม max_allowed_packetเป็นหลาย GBเพียงเพื่อ Import Dumpแปลก ๆ

ตรวจ Dumpก่อน

107. Errorเฉพาะ Database Backup Restore

Large Statementsหรือ Connection Durationอาจเป็นปัจจัย

108. ใช้ Dump Toolที่เหมาะ

แทน Copy SQLมหาศาลผ่าน Web UIในบางกรณี

109. phpMyAdmin UploadกับServer Gone Away

Web Layerยังมี:

PHP timeout
Upload limits

อีกชุดหนึ่ง

อย่าคิดว่า Errorจาก Web UIเป็น MariaDBอย่างเดียวโดยไม่ดู Messageจริง

110. FiveM Runtimeไม่มี PHP Layer

จึงแยก Diagnosisออก

111. Error2006 Character Save

ตรวจ:

MariaDBยัง Upไหม
Resourcesอื่น Errorไหม
Character Dataใหญ่ผิดปกติไหม
Connection Poolเก่าหรือไม่

112. Error2006 Inventory Save

ตรวจ Serialized Payload Size

113. Error2006 Housing Save

ตรวจ Furniture JSON

114. Error2006 Vehicle Save

ตรวจ Vehicle Properties

115. Error2006 Phone

ตรวจ Resource ConnectionและPayload

116. Error2006 Logs

ตรวจ Bulk Log Insertsและ Query Frequency

117. Error2006ตอน Server Startup

Databaseอาจยังไม่ Ready

FiveM Resources Startก่อน MariaDBพร้อมรับ Connections

118. Startup Dependency

ถ้า DBอยู่คนละ Service/Container:

ตรวจ Startup/Health Readiness

119. อย่าแก้ด้วย Wait 30วินาทีแบบสุ่มเสมอไป

Health Check/Reconnect Mechanismที่เหมาะกับ Environmentดีกว่า Hardcoded Delay

120. Errorหลัง Server Bootเท่านั้น

เป็น Patternให้ตรวจ Startup Order

121. Errorตอนเล่นปกติหลังหลายชั่วโมง

ตรวจ Idle/Restart/Network

122. Errorเฉพาะกลางคืน

ตรวจ Scheduled Jobs/Backups/Hosting Maintenance

123. Errorทุกเวลา 04:00

ดู Cron/Backupก่อน Random Code Changes

124. Errorหลัง Database Backup

อย่าสรุปว่า Backupทำ Connectionหลุดทันที

ตรวจ Logว่า Service Restartหรือไม่

125. Errorหลัง MariaDB Upgrade

Configuration Defaults/Connector Compatibilityอาจเปลี่ยนตาม Version

ใช้ Official Migration/Upgrade Documentation

126. Errorหลังเปลี่ยน MySQL→MariaDB

ตรวจ:

Connector
SQL Modes
Connection settings
Resource Compatibility

127. แต่คำว่า `MySQL server has gone away` ยังพบใน MariaDB

แม้ใช้ MariaDB Serverก็ตาม ดังที่ MariaDB Documentationแสดง Error2006ด้วยข้อความนี้.

128. จึงไม่ต้องตกใจว่าติดตั้ง MySQLผิด

ข้อความเป็น Compatibility Error Message

129. Error2006แล้ว Databaseกลับมาเอง

FiveM Resourceอาจ Reconnectอัตโนมัติ

แต่ควรหาสาเหตุถ้าเกิดบ่อย

130. ถ้าเกิดปีละครั้งระหว่าง Maintenance

ความรุนแรงต่างจากเกิดทุก10นาที

131. Frequencyสำคัญ

เก็บ:

เวลา
Resource
Query
DB uptime

132. Monitoring Uptime

ช่วยจับ Restartที่ไม่ได้ตั้งใจ

133. Monitoring Connections

ช่วยจับ Reconnect Storm/Capacity

134. Monitoring Error Logs

ช่วยจับ Crash/OOM

135. ไม่ต้อง Monitoringซับซ้อนตั้งแต่แรก

เริ่มจาก LogsและStatus Metricsที่มี

136. วิธีตรวจเบื้องต้น


SELECT @@wait_timeout;


SHOW VARIABLES LIKE 'max_allowed_packet';


SHOW GLOBAL STATUS LIKE 'Uptime';


SHOW FULL PROCESSLIST;

MariaDBมี System/Status Variablesและ Processlistสำหรับตรวจ Server Configuration/Stateและ Connections.

137. ถ้า MariaDB Uptimeลด

สงสัย Restart/Crash

138. ถ้า Uptimeปกติแต่ Errorหลัง Idle

สงสัย Connection Timeout/Pool

139. ถ้า Errorเฉพาะ Payloadใหญ่

สงสัย Packet/Data Size

140. ถ้า Errorเฉพาะ Remote DB

ตรวจ Networkเพิ่ม

141. ถ้า Errorทุก Resourceพร้อมกัน

ตรวจ Database Serviceระดับระบบ

142. ถ้า Error Resourceเดียว

ตรวจ Resource/Pool

143. Decision Tree


Error 2006
↓
MariaDB restart หรือไม่?
├─ ใช่ → หาเหตุผลที่ restart/crash
└─ ไม่
   ↓
เกิดหลัง idle?
├─ ใช่ → wait_timeout / stale pool
└─ ไม่
   ↓
เกิดเฉพาะ query ใหญ่?
├─ ใช่ → max_allowed_packet / payload
└─ ไม่
   ↓
Remote DB?
├─ ใช่ → network/infrastructure
└─ ไม่
   ↓
ตรวจ wrapper / logs / query

144. อย่าเปลี่ยนหลายค่าในครั้งเดียว

เช่น:


wait_timeout
max_allowed_packet
connect_timeout
net_read_timeout
net_write_timeout

พร้อมกันทั้งหมด

145. ทำไม

ถ้า Errorหาย:

คุณจะไม่รู้ว่าตัวไหนแก้จริง

และอาจสร้าง Side Effects

146. เปลี่ยน Configurationแบบมี Evidence

ดีที่สุด

147. `connect_timeout` ต่างจาก wait_timeout

connect_timeout เกี่ยวกับช่วงสร้าง Connection ส่วน wait_timeout เกี่ยวกับ Connectionที่ไม่มี Activityหลังเชื่อมแล้วในบริบทของ MariaDB Server Variables.

148. อย่าเพิ่ม connect_timeoutเพื่อแก้ Idle Connection

เป็นคนละปัญหา

149. Resource Developerควร Handle Reconnect

Database Clientควรสามารถตรวจ Connection Failureและดำเนินตาม Retry/Reconnect Policyอย่างเหมาะสม

150. Retry Queryทุกชนิดได้ไหม

ไม่

โดยเฉพาะ:

INSERT purchase
Money transfer
Give item

เพราะต้องรู้ว่า Queryก่อน Connectionหาย:

Serverได้รับหรือไม่
Commitหรือไม่

151. นี่สำคัญมาก

Networkหายหลัง Clientส่ง Queryแล้วไม่ได้รับ Response:

Applicationอาจไม่รู้แน่นอนว่า Server Commit Operationไปแล้วหรือยัง

152. Blind Retryเสี่ยง Duplicate

เช่น:


ซื้อรถ
↓
INSERTส่งไป
↓
connectionหายก่อน clientเห็น result
↓
client retry
↓
รถอาจถูกสร้างซ้ำ

หาก Resourceไม่มี Duplicate/Idempotency Protection

153. Money Transferก็เช่นกัน

Retryผิดสามารถทำ Transactionซ้ำ

154. Inventory Rewardก็เช่นกัน

อาจเกิด Dupe

155. Error Handlingจึงต้องแยก ReadกับWrite

SELECTบางชนิด Retryง่ายกว่า Write Operationที่มี Side Effects

156. Resource Ownerทั่วไปไม่ควรเพิ่ม Auto Retryให้ทุก SQL Queryเอง

ใช้ Database Wrapperที่รองรับและ Application Logicที่ Developerออกแบบ

157. Transaction IDsช่วยได้

ระบบการเงินที่ดีอาจใช้ Unique Transaction Referenceเพื่อป้องกัน Requestเดียวถูก Processซ้ำ

ขึ้นกับ Architecture

158. Database Restartกลาง Transaction

Transactionที่ยังไม่ Commitโดยทั่วไปไม่ควรถูกถือว่าสำเร็จเพียงเพราะบาง Statementsเคยรัน

แต่พฤติกรรม Recovery/Application Stateต้องดู Database EngineและTransactionจริง

159. อย่าบอก Playerว่ารายการสำเร็จจน Commitยืนยัน

โดยเฉพาะ Economy Systems

160. Player-facing Handling

ถ้า Databaseขาด:

Resourceควร Failอย่างควบคุมแทน:

ให้เงิน
ให้รถ
ให้ Item

โดยไม่รู้ว่า Saveสำเร็จหรือไม่

161. Database Outageควรหยุด Sensitive Transactions

ถ้าระบบไม่สามารถรับประกัน Persistence

162. Error2006แล้ว Playerยังเล่นต่อได้ไหม

บาง Resourcesอาจใช้ Cacheใน Memoryชั่วคราว

แต่ถ้า Persistenceล้ม:

มีความเสี่ยงข้อมูลไม่ Save

163. อย่ารอจน Server Restartแล้วข้อมูลหาย

แก้ Database Connection Errorsที่เกิดซ้ำ

164. Character Save Errorรุนแรง

เพราะ:

Money
Job
Position
Metadata

อาจไม่ถูกเขียน

ตาม Queryที่ล้ม

165. Log Errorรุนแรงน้อยกว่า Core Saveใน Gameplay Impact

แต่ยังควรแก้

166. Severity Matrix

Error เกิดกับ	ความสำคัญ
Character Save	สูง
Banking	สูง
Inventory	สูง
Vehicle Ownership	สูง
Housing	สูง
Optional Log	ต่ำกว่า Core State

167. ตรวจว่า Databaseกลับมาแล้วจริง

อย่าดูแค่ว่า Service Process Running

ทดลอง Queryสุขภาพที่เหมาะสมผ่าน Admin Client

168. เช่น


SELECT 1;

เป็น Simple Testว่าการ Queryพื้นฐานตอบได้

169. แต่ `SELECT 1`ผ่านไม่ได้พิสูจน์ว่า Heavy Queryจะผ่าน

ถ้าปัญหาคือ Packet Size

170. ต้อง Reproduce Featureที่ Error

เช่น Character Save

171. หลังเพิ่ม max_allowed_packet

ทดสอบ Payloadเดิม

ไม่ใช่แค่ Login Database

172. หลังปรับ Pool

ทดสอบ:

Idle
Reconnect
Server Restart

173. หลังแก้ Startup Order

Restartทั้ง Environmentตามลำดับจริง

174. หลังแก้ Resource

Trigger Featureจริง

175. Backupก่อนแก้ Database Configไหม

Config Changeบางอย่างไม่แก้ Dataโดยตรง

แต่ก่อนทำ Migration/Data Cleanupควร Backupเสมอ

176. ก่อน Restart Production DB

ควรวาง Maintenanceและรู้ผลกระทบต่อ FiveM

177. Restart DBกลางคนเล่น

Connectionsทั้งหมดจะได้รับผล

จึงไม่ควรใช้เป็น Troubleshooting Routine

178. Error2006 FAQ

FiveM `MySQL server has gone away` คืออะไร

หมายถึง Database Connectionที่ Clientต้องการใช้ไม่สามารถใช้งานต่อได้ โดย MariaDB Documentationแสดง Error2006ในกรณี Connection/Transaction Timeoutด้วย.

Error2006หมายถึง MariaDBดับเสมอไหม

ไม่ อาจเกิดจาก Connection Timeoutหรือเหตุอื่นที่ทำ Sessionหายได้

MariaDB Restartทำ Error2006ได้ไหม

ได้ เพราะ Existing Connectionsไม่สามารถใช้ Sessionเดิมต่อหลัง Server Restart

`wait_timeout`เกี่ยวไหม

เกี่ยว MariaDBใช้ wait_timeoutในการปิด Connectionsหลังไม่มี Activityตามช่วงเวลาที่กำหนด.

เพิ่ม wait_timeoutดีไหม

เฉพาะเมื่อพิสูจน์แล้วว่า Idle Timeoutไม่เหมาะกับ Pool/Workload ไม่ควรเพิ่มมหาศาลเพื่อซ่อน Reconnect Bug

`max_allowed_packet`เกี่ยวไหม

ควรตรวจเมื่อ Errorสัมพันธ์กับ Query/Payloadขนาดใหญ่ เพราะ MariaDBกำหนด max_allowed_packetเป็นขนาดสูงสุดของ PacketหรือGenerated/Intermediate String.

ดู max_allowed_packetอย่างไร


SHOW VARIABLES LIKE 'max_allowed_packet';

ดู wait_timeoutอย่างไร


SHOW VARIABLES LIKE 'wait_timeout';

Errorเกิดหลัง Idleหลายชั่วโมงทำอย่างไร

ตรวจ wait_timeoutและ Connection Pool idle/reconnect behaviorก่อน

Errorเกิดหลัง Database Restartทำอย่างไร

ตรวจว่า Database Wrapper Reconnectได้ถูกต้องและหา Root Causeของ Restart

Errorเกิดเฉพาะ Characterเดียว

ตรวจ Serialized Data/Payloadของ Characterนั้นเทียบกับคนปกติ

Errorเกิดเฉพาะ Inventoryใหญ่

ตรวจ JSON/Metadata Sizeและ max_allowed_packet แต่ต้องหาว่าข้อมูลโตผิดปกติจาก Bugหรือไม่

Errorเกิดเฉพาะ Houseหนึ่งหลัง

ตรวจ Furniture/Object Data Size

Errorเกิดเฉพาะ Vehicleหนึ่งคัน

ตรวจ Vehicle Properties/Serialized Data

Errorเกิดทุก Resourceพร้อมกัน

ตรวจ MariaDB Service, Uptime, HostingและNetwork

Errorเกิด Resourceเดียว

ตรวจ Pool/Connection Configของ Resourceนั้น

Errorเกิดหลัง Server Restart

ตรวจ Database readinessและ Reconnect Burst

Errorเกิดทุกเช้าหลัง Serverว่าง

ตรวจ Idle Connection Timeout

Errorเกิดเวลาเดิมทุกวัน

ตรวจ Scheduled Restart, BackupหรือHosting Maintenance

Clear FiveM Cacheช่วยไหม

โดยทั่วไปไม่ใช่ Fixของ Database Connectionที่ถูก MariaDB/Networkปิด

Restart FiveMช่วยไหม

อาจสร้าง Connectionsใหม่และทำให้อาการหายชั่วคราว แต่ไม่แก้สาเหตุที่ Connectionเดิมหาย

Restart MariaDBช่วยไหม

ถ้า MariaDBทำงานผิดปกติอาจจำเป็นในบางเหตุการณ์ แต่ Restartเองจะตัด Existing Connectionsและไม่ควรใช้เป็น Fixประจำ

เพิ่ม max_allowed_packetเป็น1GBเลยดีไหม

ไม่ ควรดู Payloadจริงและ Requirementก่อน

เพิ่ม wait_timeoutเป็นหลายวันดีไหม

ไม่ควรทำจากการเดา ให้ตรวจ Pool/Reconnectionก่อน

Networkทำให้เกิดได้ไหม

Remote Databaseมี Network Pathเพิ่ม จึงควรตรวจ Infrastructureเมื่อ MariaDBไม่ได้ Restartและ Errorเกิดกับ Remote Connection

Pingปกติแปลว่า Database Connectionปกติไหม

ไม่จำเป็น Database Sessionกับ ICMP Pingเป็นคนละ Connection/Protocol Context

Database Wrapperเก่าทำให้เกิดได้ไหม

ได้ในแง่ Compatibility/Connection Management จึงควรตรวจ Versionและ Official Configurationเมื่อ Errorเริ่มหลังเปลี่ยน Wrapper

Queryใหญ่ทำให้เกิดได้ไหม

Payloadขนาดใหญ่ควรตรวจ max_allowed_packet.

Error2006กับ1040เหมือนกันไหม

ไม่

1040 = Too many connections
2006 = Existing/expected connectionไม่สามารถใช้ต่อ

Error2006กับ1205เหมือนกันไหม

ไม่

1205 = Lock wait timeout
2006 = Connectionหาย

Error2006กับ1213เหมือนกันไหม

ไม่

1213 = Deadlock
2006 = Connection issue

Retry Queryได้เลยไหม

ไม่ควร Retry Write Operationทุกชนิดแบบ Blind เพราะหาก Connectionหายหลัง Serverได้รับ Operationแล้ว Applicationอาจเสี่ยงทำ Actionซ้ำ

ต้อง Reinstall MariaDBไหม

โดยทั่วไปไม่ใช่ First Fix

ตรวจ:

Service uptime
Timeout
Pool
Packet
Network
Logs

ก่อน

ต้องลบ Databaseไหม

ไม่

Error2006ไม่ใช่เหตุผลให้ลบ Database

ต้อง Backupไหม

หากต้องแก้ข้อมูลผิดปกติ, Migrationหรือ Schemaควร Backupก่อน ส่วนการแก้ Connection Configต้องทำอย่างมี Maintenance Planใน Production

สรุป FiveM MySQL Server Has Gone Away Error 2006

FiveM MySQL/MariaDB MySQL server has gone away Error 2006 หมายความว่า Database Connection ที่ Resource ต้องการใช้ไม่สามารถใช้งานต่อได้ และ MariaDB Documentationแสดงว่า Timeoutของ Connection/Transactionสามารถทำให้ Clientได้รับ Error2006ได้ ขณะที่ max_allowed_packetควรถูกตรวจเมื่อลักษณะปัญหาสัมพันธ์กับ Payloadหรือ Queryขนาดใหญ่.

ให้วิเคราะห์ตามลำดับ:


Error 2006
↓
MariaDB เพิ่ง Restart หรือไม่?
↓
เกิดหลัง Idle หรือไม่?
↓
ตรวจ wait_timeout
↓
เกิดเฉพาะ Query/Payload ใหญ่หรือไม่?
↓
ตรวจ max_allowed_packet
↓
Remote Database หรือไม่?
↓
ตรวจ Network
↓
ตรวจ Connection Pool / Wrapper
↓
แก้ Root Cause

สิ่งที่ comsiam แนะนำคืออย่าปรับ wait_timeout และ max_allowed_packet ให้สูงมากพร้อมกันทันที เพราะ Error2006มีได้หลายต้นเหตุ ถ้า MariaDBเพิ่ง Restart การปรับ Packetไม่ได้ช่วย ถ้า Poolกำลัง Reuse Connectionที่ถูกปิด การเพิ่ม Packetก็ไม่เกี่ยว และถ้า Character JSONโตผิดปกติจาก Bug การขยาย Packetเพียงทำให้ Databaseรับข้อมูลที่ใหญ่ขึ้นโดยไม่ได้แก้สาเหตุ

อีกหลักที่ comsiam แนะนำคือให้เก็บเวลาที่ Errorเกิดแล้วเปรียบเทียบกับ MariaDB Uptime, Resourceที่ Errorและขนาด Query หากเกิดทุก Resourceพร้อมกันให้ตรวจ Database/Infrastructureก่อน แต่ถ้าเกิดเฉพาะ Character, Inventory, Houseหรือ Vehicleบาง Record ให้ตรวจ Serialized Dataและ max_allowed_packet; หากเกิดหลัง Idleเป็นเวลานานให้ตรวจ wait_timeoutกับ Pool Reconnection Logic วิธีนี้จะหาสาเหตุได้ตรงกว่าการ Restart FiveMหรือเพิ่ม Database Limitsแบบสุ่ม