ฉันมีฐานข้อมูล MySQL ที่เก็บข้อมูลจำนวนมาก (100-200GB - การวัดทางวิทยาศาสตร์จำนวนมาก) ข้อมูลส่วนใหญ่ถูกเก็บไว้ในตารางSampleเดียว ตอนนี้ฉันกำลังสร้างแบบจำลองทาสของฐานข้อมูลและฉันต้องการใช้ประโยชน์จากinnodb_file_per_tableกระบวนการนี้ ดังนั้นฉันตั้งค่าinnodb_file_per_tableในการกำหนดค่าทาสของฉันและนำเข้าการถ่ายโอนข้อมูลของฐานข้อมูล ด้วยความประหลาดใจของฉันมันล้มเหลวด้วย

ข้อผิดพลาด 1114 (HY000) ที่บรรทัด 5602: ตาราง 'ตัวอย่าง' เต็ม

ปัจจุบันไฟล์Sample.ibdนี้มีขนาดประมาณ 93GB โดยมีพื้นที่ว่างบนพาร์ติชันมากกว่า 600GB ดังนั้นจึงไม่ใช่ปัญหาเรื่องพื้นที่ว่างบนดิสก์ ดูเหมือนว่ามันจะไปกระทบขีด จำกัด ของระบบไฟล์ทุกประเภท (ฉันใช้ ext4)

ฉันจะขอบคุณสำหรับความคิดใด ๆ ที่อาจเป็นสาเหตุหรือสิ่งที่จะตรวจสอบ

UPDATE:mysql Ver 14.14 Distrib 5.1.66, for debian-linux-gnu (x86_64)ฉันใช้

SELECT @@datadir; -- returns `/home/var/lib/mysql/`
SHOW VARIABLES LIKE '%innodb_data_file_path%'; -- ibdata1:10M:autoextend 

df -h /home/var/lib/mysql/
768G   31G  699G   5% /home

ข้อเท็จจริง

ext4คุณบอกว่าคุณกำลังใช้ ขีด จำกัด ขนาดไฟล์คือ 16TB ดังนั้นSample.ibdไม่ควรเต็ม

คุณบอกว่าคุณมีinnodb_data_file_path ibdata1:10M:autoextendดังนั้นไฟล์ ibdata1 เองจึงไม่มีขีด จำกัด ของขนาดยกเว้นจากระบบปฏิบัติการ

เหตุใดข้อความนี้จึงเกิดขึ้นทั้งหมด สังเกตว่าข้อความคือ "ตาราง ... เต็ม" ไม่ใช่ "ดิสก์ ... เต็ม" ตารางเงื่อนไขนี้เต็มจากมุมมองเชิงตรรกะ คิดเกี่ยวกับ InnoDB เกิดปฏิกิริยาอะไรขึ้น?

ฉันเดาว่า InnoDB กำลังพยายามโหลดข้อมูล 93GB เป็นธุรกรรมเดียว Table is Fullข้อความจะแพร่กระจายจากที่ไหน ฉันจะดูที่ ibdata1 ไม่ใช่ขนาดทางกายภาพของมัน (ซึ่งคุณได้ตัดออกไปแล้ว) แต่ในแง่ของข้อ จำกัด ของการทำธุรกรรม

ภายใน ibdata1 คืออะไรเมื่อเปิดใช้งานinnodb_file_per_tableและคุณโหลดข้อมูลใหม่ลงใน MySQL

• พจนานุกรมข้อมูล
• บัฟเฟอร์การเขียนซ้ำ
  • Safety Net เพื่อป้องกันการเสียหายของข้อมูล
  • ช่วย Bypass OS สำหรับการแคช
• แทรกบัฟเฟอร์ (ปรับปรุงการเปลี่ยนแปลงดัชนีรอง)
• ส่วนย้อนกลับ
• เลิกทำการบันทึก
• คลิกที่นี่เพื่อดูภาพแทน ibdata1

ความสงสัยของฉันบอกฉันว่าบันทึกการเลิกทำและ / หรือการทำซ้ำบันทึกเป็นความผิด

บันทึกเหล่านี้คืออะไร? ตามหนังสือ

บทที่ 10: "เครื่องมือจัดเก็บ" หน้า 203 ย่อหน้า 3,4 พูดต่อไปนี้:

เอ็นจิ้น InnoDB เก็บบันทึกสองประเภท: บันทึกเลิกทำและบันทึกทำซ้ำ วัตถุประสงค์ของการบันทึกการเลิกทำคือการย้อนกลับการทำธุรกรรมเช่นเดียวกับการแสดงข้อมูลรุ่นเก่ากว่าสำหรับการสืบค้นที่รันในระดับการแยกธุรกรรมที่ต้องใช้ รหัสที่จับบันทึกยกเลิกสามารถพบได้ในการจัดเก็บข้อมูล / innobase / buf / log / log0log.c

วัตถุประสงค์ของบันทึกการทำซ้ำคือการจัดเก็บข้อมูลที่จะใช้ในการกู้คืนความผิดพลาด อนุญาตให้กระบวนการกู้คืนดำเนินการธุรกรรมที่อาจหรืออาจไม่เสร็จสิ้นก่อนที่จะเกิดความผิดพลาด หลังจากดำเนินการธุรกรรมเหล่านั้นอีกครั้งฐานข้อมูลจะถูกนำไปสู่สถานะที่สอดคล้องกัน รหัสที่เกี่ยวข้องกับการทำซ้ำล็อกที่สามารถพบได้ในการจัดเก็บข้อมูล / innobase / log / log0recv.c

การวิเคราะห์

มี 1023 เลิกทำบันทึกอยู่ภายใน ibdata1 (กลุ่มดูย้อนกลับและเลิกทำอวกาศ) เนื่องจากบันทึกเลิกทำเก็บสำเนาข้อมูลตามที่ปรากฏก่อนที่จะโหลดอีกครั้ง 1,023 บันทึกการเลิกทำทั้งหมดถึงขีด จำกัด แล้ว จากมุมมองอื่น ๆ 1,023 บันทึกการเลิกทำทั้งหมดอาจจะทุ่มเทให้กับธุรกรรมหนึ่งที่โหลดSampleตาราง

แต่เดี๋ยวก่อน...

คุณอาจพูดว่า "ฉันกำลังโหลดSampleตารางว่าง" บันทึกเลิกทำมีส่วนร่วมอย่างไร ก่อนที่Sampleตารางจะถูกโหลดด้วยข้อมูล 93GB มันจะว่างเปล่า การแทนทุกแถวที่ไม่มีอยู่ต้องใช้พื้นที่ว่างในการทำความสะอาดใน Undo Logs เติม 1,023 บันทึกการเลิกทำดูเหมือนเล็กน้อยเนื่องจากปริมาณข้อมูลที่ไหลเข้าibdata1มา ฉันไม่ใช่คนแรกที่สงสัยสิ่งนี้:

จากเอกสาร MySQL 4.1, หมายเหตุPosted by Chris Calender on September 4 2009 4:25pm:

โปรดทราบว่าใน 5.0 (pre-5.0.85) และใน 5.1 (pre-5.1.38) คุณอาจได้รับข้อผิดพลาด "table is full" สำหรับตาราง InnoDB หาก InnoDB หมดสล็อตเลิกทำ (bug # 18828)

นี่คือรายงานข้อผิดพลาดสำหรับ MySQL 5.0: http://bugs.mysql.com/bug.php?id=18828

คำแนะนำ

เมื่อคุณสร้าง mysqldump ของSampleตารางโปรดใช้--no-autocommit

mysqldump --no-autocommit ... mydb Sample > Sample.sql

นี้จะทำให้ชัดเจนทุกครั้งหลังCOMMIT; INSERTจากนั้นโหลดตารางอีกครั้ง

ถ้าสิ่งนี้ใช้ไม่ได้ ( คุณจะไม่ทำแบบนี้ ) ให้ทำสิ่งนี้

mysqldump --no-autocommit --skip-extended-insert ... mydb Sample > Sample.sql

สิ่งนี้จะทำให้แต่ละ INSERT มีเพียงหนึ่งแถว mysqldump จะใหญ่กว่ามาก (มากกว่า 10+ เท่า) และอาจใช้เวลาโหลดนาน 10 ถึง 100 เท่า

ไม่ว่าในกรณีใดกรณีนี้จะเป็นการสำรองบันทึกการเลิกทำจากการถูกน้ำท่วม

ให้มันลอง !!!

อัพเดท 2013-06-03 13:05 EDT

คำแนะนำเพิ่มเติม

หากตารางระบบ InnoDB (aka ibdata1) ขีด จำกัด ขนาดไฟล์และไม่สามารถใช้ Undo Logs คุณสามารถเพิ่ม tablespace ระบบอื่น (ibdata2)

ฉันเพิ่งพบสถานการณ์นี้เมื่อสองวันก่อน ฉันอัปเดตโพสต์เก่าของฉันด้วยสิ่งที่ฉันทำ: ดูการออกแบบฐานข้อมูล - การสร้างฐานข้อมูลหลายรายการเพื่อหลีกเลี่ยงการ จำกัด ขนาดตาราง

โดยพื้นฐานแล้วคุณต้องเปลี่ยนinnodb_data_file_pathเพื่อรองรับไฟล์ tablespace ของระบบใหม่ ให้ฉันอธิบายวิธี:

สถานการณ์

บนดิสก์ (ext3) เซิร์ฟเวอร์ของลูกค้าของฉันมีดังต่อไปนี้:

[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql     362807296 Jun  2 00:15 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun  2 00:15 ibdata2

การตั้งค่าคือ

innodb_data_file_path=ibdata1:346M;ibdata2:500M:autoextend:max:10240000M

โปรดทราบว่าการibdata2ขยายตัวเพื่อ 2196875759616 2145386484Mซึ่งเป็น

ฉันต้องฝังขนาดไฟล์ของibdata2ลงใน innodb_data_file_path และเพิ่มibdata3

innodb_data_file_path=ibdata1:346M;ibdata2:2196875759616;ibdata3:10M:autoextend

เมื่อฉันรีสตาร์ท mysqld มันทำงาน:

[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql     362807296 Jun  3 17:02 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun  3 17:02 ibdata2
-rw-rw---- 1 s-em7-mysql s-em7-mysql   32315015168 Jun  3 17:02 ibdata3

ใน 40 ชั่วโมงibdata3เพิ่มขึ้นเป็น 31G MySQL ทำงานอีกครั้ง

ฉันมีปัญหาเดียวกันและฉันเพิ่งทำสิ่งหนึ่งและทำงานได้

ดูเหมือนว่าคุณจะมีขนาดสูงสุดต่ำเกินไปสำหรับไฟล์การกำหนดค่าinnodb_data_file_pathของคุณ my.cnfเพียงแค่เปลี่ยนรหัสด้านล่าง -

innodb_data_file_path = ibdata1:10M:autoextend:max:512M

สิ่งสำคัญหมายเหตุคุณไม่สามารถโฮสต์มากกว่า512MBข้อมูลในInnoDB ตารางทั้งหมดรวมกัน

นอกจากนี้คุณยังสามารถเปลี่ยนไปใช้รูปแบบ Innodb ต่อตารางinnodb_file_per_tableได้