ข้อผิดพลาด 2006 (HY000): เซิร์ฟเวอร์ MySQL หายไปแล้ว

ฉันได้รับข้อผิดพลาดนี้เมื่อฉันพยายามที่จะแหล่งไฟล์ SQL ขนาดใหญ่ ( INSERTแบบสอบถามใหญ่)

mysql>  source file.sql
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    2
Current database: *** NONE ***

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    3
Current database: *** NONE ***

ไม่มีการอัปเดตอะไรในตาราง ฉันได้ลองลบและยกเลิกการลบตาราง / ฐานข้อมูลรวมถึงการเริ่ม MySQL ใหม่ สิ่งเหล่านี้ไม่สามารถแก้ไขปัญหาได้

นี่คือขนาดแพ็คเก็ตสูงสุดของฉัน:

+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+

นี่คือขนาดไฟล์:

$ ls -s file.sql 
79512 file.sql

เมื่อฉันลองวิธีอื่น ...

$ ./mysql -u root -p my_db < file.sql
Enter password: 
ERROR 2006 (HY000) at line 1: MySQL server has gone away

max_allowed_packet=64M

การเพิ่มบรรทัดนี้เป็นmy.cnfไฟล์แก้ปัญหาของฉัน

นี้จะเป็นประโยชน์เมื่อคอลัมน์ที่มีค่าขนาดใหญ่ซึ่งก่อให้เกิดปัญหาที่คุณสามารถหาคำอธิบายที่นี่

บน Windows ไฟล์นี้อยู่ที่: "C: \ ProgramData \ MySQL \ MySQL Server 5.6"

บน Linux (Ubuntu): / etc / mysql

คุณสามารถเพิ่ม Max Packet Packet ได้

SET GLOBAL max_allowed_packet=1073741824;

http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet

การอัปเดตทั่วโลกและการตั้งค่า my.cnf ไม่ทำงานสำหรับฉันด้วยเหตุผลบางอย่าง การส่งผ่านmax_allowed_packetค่าโดยตรงไปยังลูกค้าทำงานที่นี่:

mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql

โดยทั่วไปแล้วข้อผิดพลาด:

ข้อผิดพลาด: 2006 ( CR_SERVER_GONE_ERROR) - เซิร์ฟเวอร์ MySQL หายไปแล้ว

หมายความว่าลูกค้าไม่สามารถส่งคำถามไปยังเซิร์ฟเวอร์

mysql นำเข้า

ในกรณีเฉพาะของคุณในขณะที่นำเข้าไฟล์ฐานข้อมูลผ่านmysqlหมายความว่าคำสั่งบางคำในไฟล์ SQL นั้นมีขนาดใหญ่เกินไปที่จะนำเข้าและไม่สามารถเรียกใช้งานบนเซิร์ฟเวอร์ดังนั้นไคลเอ็นต์จึงล้มเหลวในข้อผิดพลาดที่เกิดขึ้นครั้งแรก

ดังนั้นคุณมีความเป็นไปได้ดังต่อไปนี้:

• เพิ่มตัวเลือกบังคับ ( -f) mysqlเพื่อดำเนินการต่อและเรียกใช้แบบสอบถามที่เหลือ

  สิ่งนี้มีประโยชน์หากฐานข้อมูลมีคิวรีขนาดใหญ่ที่เกี่ยวข้องกับแคชซึ่งไม่เกี่ยวข้องกัน

• เพิ่มmax_allowed_packetและwait_timeoutในการกำหนดค่าเซิร์ฟเวอร์ของคุณ (เช่น~/.my.cnf)

• ดัมพ์ฐานข้อมูลโดยใช้--skip-extended-insertอ็อพชันเพื่อแยกเคียวรีขนาดใหญ่ จากนั้นนำเข้าอีกครั้ง

• ลองใช้ตัวเลือกสำหรับการ--max-allowed-packetmysql

สาเหตุทั่วไป

โดยทั่วไปข้อผิดพลาดนี้อาจหมายถึงหลายสิ่งเช่น:

• แบบสอบถามไปยังเซิร์ฟเวอร์ไม่ถูกต้องหรือใหญ่เกินไป

  การแก้ไข: เพิ่มmax_allowed_packetตัวแปร

  • ตรวจสอบให้แน่ใจตัวแปรที่อยู่ภายใต้ส่วนไม่ได้[mysqld][mysql]

  • อย่ากลัวที่จะใช้จำนวนมากในการทดสอบ (เช่น1G)

  • อย่าลืมรีสตาร์ทเซิร์ฟเวอร์ MySQL / MariaDB

  • ตรวจสอบอีกครั้งว่าการตั้งค่าถูกต้องโดย:

    mysql -sve "SELECT @@max_allowed_packet" # or:
    mysql -sve "SHOW VARIABLES LIKE 'max_allowed_packet'"

• คุณหมดเวลาจากการเชื่อมต่อ TCP / IP ทางฝั่งไคลเอ็นต์

  การแก้ไข: เพิ่มwait_timeoutตัวแปร

• คุณพยายามเรียกใช้คิวรีหลังจากการเชื่อมต่อกับเซิร์ฟเวอร์ถูกปิด

  การแก้ไข: ข้อผิดพลาดเชิงตรรกะในแอปพลิเคชันควรได้รับการแก้ไข

• การค้นหาชื่อโฮสต์ล้มเหลว (เช่นปัญหาเซิร์ฟเวอร์ DNS) หรือเซิร์ฟเวอร์เริ่มต้นด้วย--skip-networkingตัวเลือก

  ความเป็นไปได้อีกอย่างหนึ่งคือไฟร์วอลล์ของคุณบล็อกพอร์ต MySQL (เช่น 3306 โดยค่าเริ่มต้น)

• เธรดที่กำลังทำงานถูกฆ่าตายแล้วลองอีกครั้ง

• คุณพบข้อผิดพลาดที่เซิร์ฟเวอร์เสียชีวิตขณะดำเนินการค้นหา

• ไคลเอนต์ที่ทำงานบนโฮสต์ที่แตกต่างกันไม่มีสิทธิ์ที่จำเป็นในการเชื่อมต่อ

• และอีกมากมายเรียนรู้เพิ่มเติมที่: B.5.2.9 เซิร์ฟเวอร์ MySQL หายไปแล้ว

แก้จุดบกพร่อง

ต่อไปนี้เป็นแนวคิดการดีบักระดับผู้เชี่ยวชาญเล็กน้อย:

• ตรวจสอบบันทึกเช่น

  sudo tail -f $(mysql -Nse "SELECT @@GLOBAL.log_error")

• ทดสอบการเชื่อมต่อของคุณผ่านทางmysql, telnetหรือฟังก์ชั่นปิง (เช่นmysql_pingใน PHP)

• ใช้tcpdumpเพื่อดมกลิ่นการสื่อสาร MySQL (จะไม่ทำงานสำหรับการเชื่อมต่อซ็อกเก็ต) เช่น:

  sudo tcpdump -i lo0 -s 1500 -nl -w- port mysql | strings

• บน Linux straceใช้งาน สำหรับ BSD / Mac ให้ใช้dtrace/ dtrussเช่น

  sudo dtruss -a -fn mysqld 2>&1

  ดู: การเริ่มต้นกับ DTracing MySQL

เรียนรู้เพิ่มเติมเกี่ยวกับวิธีการแก้ปัญหา MySQL เซิร์ฟเวอร์หรือลูกค้าที่: 26.5 แก้จุดบกพร่องและ Porting MySQL

สำหรับการอ้างอิงตรวจสอบซอร์สโค้ดในsql-common/client.cไฟล์ที่รับผิดชอบในการโยนCR_SERVER_GONE_ERRORข้อผิดพลาดสำหรับคำสั่งไคลเอ็นต์

MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg));
if (net_write_command(net,(uchar) command, header, header_length,
          arg, arg_length))
{
  set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate);
  goto end;
}

ในกรณีเพื่อตรวจสอบตัวแปรที่คุณสามารถใช้ได้

$> mysqladmin variables -u user -p 

นี่จะแสดงตัวแปรปัจจุบันในกรณีนี้ max_allowed_packet และตามที่มีคนพูดในคำตอบอื่นคุณสามารถตั้งค่าชั่วคราวด้วย

mysql> SET GLOBAL max_allowed_packet=1072731894

ในกรณีของฉันไฟล์ cnf ไม่ได้ถูกนำมาพิจารณาและฉันไม่รู้ว่าทำไมรหัส SET GLOBAL จึงช่วยได้จริงๆ

ฉันแก้ไขข้อผิดพลาดERROR 2006 (HY000) at line 97: MySQL server has gone awayและโอนย้ายไฟล์> 5GB sql โดยทำตามสองขั้นตอนต่อไปนี้ตามลำดับ:

1. สร้าง /etc/my.cnf ตามที่คนอื่น ๆ แนะนำโดยมีเนื้อหาดังต่อไปนี้:

   [mysql]
   connect_timeout = 43200
   max_allowed_packet = 2048M
   net_buffer_length = 512M
   debug-info = TRUE

2. การต่อท้ายแฟล็ก--force --wait --reconnectกับคำสั่ง (เช่นmysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect)

หมายเหตุสำคัญ: จำเป็นต้องทำตามขั้นตอนทั้งสองเพราะหากฉันไม่ได้สนใจที่จะเปลี่ยนแปลงไฟล์ /etc/my.cnf เช่นเดียวกับการต่อท้ายแฟล็กเหล่านั้นบางตารางก็หายไปหลังจากการนำเข้า

ระบบที่ใช้: OSX El Capitan 10.11.5; mysql Ver 14.14 Distrib 5.5.51 สำหรับ osx10.8 (i386)

ฉันมีปัญหาเดียวกัน แต่การเปลี่ยน max_allowed_packet ในไฟล์ my.ini / my.cnf ภายใต้ [mysqld] ทำให้เกิดกลอุบาย

เพิ่มบรรทัด

max_allowed_packet=500M

ตอนนี้เริ่มบริการ MySQL เมื่อคุณทำเสร็จแล้ว

คุณยังสามารถล็อกอินเข้าสู่ฐานข้อมูลในฐานะ root (หรือสิทธิ์พิเศษ SUPER) และทำ

set global max_allowed_packet=64*1024*1024;

ไม่ต้องการการรีสตาร์ท MySQL ด้วย โปรดทราบว่าคุณควรแก้ไขmy.cnfไฟล์ตามที่ระบุในโซลูชันอื่น ๆ :

[mysqld]
max_allowed_packet=64M

และยืนยันการเปลี่ยนแปลงหลังจากที่คุณรีสตาร์ท MySQL:

show variables like 'max_allowed_packet';

คุณสามารถใช้บรรทัดคำสั่งได้เช่นกัน แต่อาจต้องมีการอัพเดตสคริปต์เริ่ม / หยุดซึ่งอาจไม่รอดจากการอัพเดตระบบและแพตช์

ตามที่ร้องขอฉันจะเพิ่มคำตอบของตัวเองที่นี่ ดีใจที่ได้เห็นมันใช้งานได้!

การแก้ปัญหาคือการเพิ่มค่าที่กำหนดwait_timeoutและconnect_timeoutพารามิเตอร์ในไฟล์ตัวเลือกของคุณภายใต้[mysqld]แท็ก

ฉันต้องกู้คืนข้อมูลสำรอง mysql ขนาด 400MB และสิ่งนี้ใช้ได้กับฉัน (ค่าที่ฉันใช้ด้านล่างนั้นค่อนข้างโอ้อวด แต่คุณเข้าใจประเด็น):

[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000

blockquote

มีสองสิ่งเกิดขึ้นที่นี่

• คุณINSERTใช้เวลานานและลูกค้ากำลังยกเลิกการเชื่อมต่อ เมื่อทำการเชื่อมต่อใหม่จะไม่ได้เลือกฐานข้อมูลดังนั้นจึงเกิดข้อผิดพลาด ทางเลือกหนึ่งที่นี่คือการเรียกใช้ไฟล์แบตช์ของคุณจากบรรทัดคำสั่งและเลือกฐานข้อมูลในอาร์กิวเมนต์เช่นนั้น

$ mysql db_name <source.sql

• อีกวิธีหนึ่งคือการเรียกใช้คำสั่งของคุณผ่านphpหรือภาษาอื่น ๆ หลังจากแต่ละคำสั่งที่ใช้เวลานานคุณสามารถปิดและเปิดการเชื่อมต่ออีกครั้งเพื่อให้แน่ใจว่าคุณได้เชื่อมต่อเมื่อเริ่มต้นของการสืบค้นแต่ละข้อ

หากคุณอยู่บน Mac และติดตั้ง mysql ผ่านการชงแบบฉันการทำงานต่อไปนี้

1. cp $(brew --prefix mysql)/support-files/my-default.cnf /usr/local/etc/my.cnf

ที่มา: สำหรับการติดตั้ง Homebrew mysql, my.cnf อยู่ที่ไหน?

2. เพิ่มmax_allowed_packet=1073741824ไปยัง/usr/local/etc/my.cnf

3. mysql.server restart

ฉันพบข้อผิดพลาดนี้เมื่อฉันใช้ Mysql Cluster ฉันไม่ทราบว่าคำถามนี้มาจากการใช้คลัสเตอร์หรือไม่ เป็นข้อผิดพลาดเหมือนกันดังนั้นให้วิธีแก้ปัญหาของฉันที่นี่ รับข้อผิดพลาดนี้เนื่องจากโหนดข้อมูลล้มเหลวอย่างกระทันหัน แต่เมื่อโหนดล่มคุณยังสามารถรับผลลัพธ์ที่ถูกต้องได้โดยใช้ cmd:

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

และ mysqld ยังทำงานได้อย่างถูกต้องดังนั้นในตอนแรกฉันไม่สามารถเข้าใจสิ่งที่ผิด และประมาณ 5 นาทีต่อมาผลลัพธ์ ndb_mgm แสดงว่าโหนดข้อมูลไม่ทำงาน จากนั้นฉันก็ตระหนักถึงปัญหา ดังนั้นลองรีสตาร์ทโหนดข้อมูลทั้งหมดจากนั้นเซิร์ฟเวอร์ mysql จะกลับมาและทุกอย่างก็โอเค

แต่สิ่งหนึ่งที่แปลกสำหรับฉันหลังจากที่ฉันทำเซิร์ฟเวอร์ mysql หายไปสำหรับบางข้อสงสัยเมื่อฉันใช้ cmd like show tablesฉันยังคงได้รับข้อมูลการส่งคืนเช่น33 rows in set (5.57 sec)แต่ไม่มีข้อมูลตารางแสดง

สำหรับ amazon RDS (เป็นกรณีของฉัน) คุณสามารถเปลี่ยนmax_allowed_packetค่าพารามิเตอร์เป็นค่าตัวเลขใด ๆ ในหน่วยไบต์ที่เหมาะสมสำหรับข้อมูลที่ใหญ่ที่สุดในส่วนแทรกใด ๆ ที่คุณอาจมี (เช่น: หากคุณมีค่า 50mb หยดในส่วนแทรกของคุณตั้งค่าmax_allowed_packetเพื่อ 64M = 67108864) parameter-groupในใหม่หรือที่มีอยู่ จากนั้นใช้พารามิเตอร์กลุ่มกับอินสแตนซ์ MySQL ของคุณ (อาจต้องรีบูตอินสแตนซ์)

หากกำลังเชื่อมต่อใหม่และรับ ID การเชื่อมต่อ 2 เซิร์ฟเวอร์ก็เกือบจะเกิดข้อผิดพลาด

ติดต่อผู้ดูแลเซิร์ฟเวอร์และให้พวกเขาวินิจฉัยปัญหา ไม่มี SQL ที่ไม่เป็นอันตรายควรทำให้เซิร์ฟเวอร์ขัดข้องและผลลัพธ์ของ mysqldump ไม่ควรแน่นอน

อาจเป็นกรณีที่ผู้ดูแลเซิร์ฟเวอร์ทำข้อผิดพลาดในการดำเนินงานใหญ่เช่นการกำหนดขนาดบัฟเฟอร์ที่มากกว่าขีด จำกัด พื้นที่ที่อยู่ของสถาปัตยกรรมหรือมากกว่าความจุหน่วยความจำเสมือน บันทึกข้อผิดพลาดของ MySQL อาจมีข้อมูลที่เกี่ยวข้อง พวกเขาจะตรวจสอบเรื่องนี้หากพวกเขามีความสามารถอยู่แล้ว

นี่เป็นปัญหาที่เกิดขึ้นได้ยากมาก แต่ฉันได้เห็นสิ่งนี้ถ้ามีคนคัดลอกไดเร็กทอรี / var / lib / mysql ทั้งหมดเพื่อโอนย้ายฐานข้อมูลของพวกเขาไปยังเซิร์ฟเวอร์อื่น สาเหตุที่ใช้ไม่ได้เนื่องจากฐานข้อมูลกำลังทำงานและใช้ไฟล์บันทึก บางครั้งมันจะไม่ทำงานหากมีการบันทึกใน / var / log / mysql ทางออกคือการคัดลอกไฟล์ / var / log / mysql เช่นกัน

สำหรับผู้ใช้ Drupal 8 กำลังมองหาวิธีแก้ปัญหาการนำเข้าฐานข้อมูลล้มเหลว:

ในตอนท้ายของไฟล์ sql dump มีคำสั่งที่สามารถแทรกข้อมูลลงในตาราง "webprofiler" นั่นคือฉันเดาไฟล์บันทึกการดีบักบางส่วนและไม่สำคัญสำหรับไซต์ที่จะทำงานดังนั้นสิ่งนี้สามารถลบออกได้ ฉันได้ลบส่วนแทรกทั้งหมดรวมถึง LOCK TABLES และ UNLOCK TABLES (และทุกอย่างระหว่าง) มันอยู่ที่ด้านล่างสุดของไฟล์ sql ปัญหาอธิบายไว้ที่นี่:

https://www.drupal.org/project/devel/issues/2723437

แต่ไม่มีวิธีแก้ปัญหาสำหรับมันนอกจากการตัดทอนตารางนั้น

BTW ฉันลองวิธีแก้ปัญหาทั้งหมดจากคำตอบข้างต้นและไม่มีสิ่งใดช่วย

ฉันได้ลองวิธีแก้ปัญหาทั้งหมดข้างต้นแล้วทั้งหมดล้มเหลว

ฉันสิ้นสุดขึ้นกับการใช้แทนการใช้ค่าเริ่มต้น-h 127.0.0.1var/run/mysqld/mysqld.sock

ข้อความแสดงข้อผิดพลาดนี้ยังเกิดขึ้นเมื่อคุณสร้าง SCHEMA ด้วย COLLATION ต่างจากที่ใช้ในการถ่ายโอนข้อมูล ดังนั้นหากมีการถ่ายโอนข้อมูล

CREATE TABLE `mytab` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

คุณควรสะท้อนสิ่งนี้ในการเปรียบเทียบ SCHEMA:

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

ฉันใช้ utf8mb4_general_ci ใน schema ทำให้สคริปต์ของฉันมาจากการติดตั้ง V8 ที่สดใหม่ตอนนี้โหลด DB บน ​​5.7 รุ่นเก่าล้มเหลวและทำให้ฉันเกือบคลั่ง

ดังนั้นนี่อาจช่วยให้คุณประหยัดเวลาได้มาก ... :-)

(MacOS 10.3, MySQL 5.7)

หากไม่มีคำตอบนี้แก้ปัญหาให้คุณได้ฉันจะแก้ไขโดยลบตารางแล้วสร้างมันขึ้นมาใหม่โดยอัตโนมัติด้วยวิธีนี้:

when creating the backup, first backup structure and be sure of add:
DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
CREATE PROCEDURE / FUNCTION / EVENT
IF NOT EXISTS
AUTO_INCREMENT

จากนั้นเพียงแค่ใช้การสำรองข้อมูลนี้กับฐานข้อมูลของคุณและมันจะลบและสร้างตารางที่คุณต้องการ

จากนั้นคุณสำรองข้อมูลและทำเช่นเดียวกันและมันจะทำงาน

วิธีการเกี่ยวกับการใช้ไคลเอนต์ mysql เช่นนี้:

mysql -h <hostname> -u username -p <databasename> < file.sql