mysqldump ไม่สมบูรณ์


11

ฉันพยายามเรียกใช้ mysqldump เพื่อสร้างสแนปชอตของฐานข้อมูลและฉันพบว่ามันจะหยุดกลางคันแบบสุ่มโดยไม่ต้องรายงานข้อผิดพลาดใด ๆ ฐานข้อมูลของฉันมีขนาดค่อนข้างเล็ก (ประมาณ 100MB) และใช้งาน InnoDB

ฉันใช้มันเหมือน:

mysqldump --force --single-transaction --quick --user myuser --password=mypass -h mydatabasehost mydb > /tmp/snapshot.sql

การตรวจสอบรหัสออกรายงาน 0

รุ่นของฉันคือ: mysqldump Ver 10.13 Distrib 5.1.52 สำหรับ redhat-linux-gnu (i386)

ฉันเคยเห็นโพสต์ที่คล้ายกันและแม้กระทั่งรายงานข้อผิดพลาดอย่างเป็นทางการแต่ดูเหมือนว่าจะไม่มีวิธีแก้ปัญหา

ฉันจะใช้ mysqldump เพื่อถ่ายภาพฐานข้อมูลที่สมบูรณ์ได้อย่างไร

แก้ไข: ฐานข้อมูลของฉันอยู่ใน RDS ของ Amazon ในปัจจุบัน


มีพื้นที่ว่างเพียงพอหรือไม่ และคุณได้ใช้ตารางตรวจสอบเพื่อดูว่าไม่มีความเสียหายฐานข้อมูลในตารางหรือไม่

คุณลองลบ--forceพารามิเตอร์เพื่อดูว่าคุณได้รับข้อผิดพลาดอะไรบ้าง หรือ--quick?

@ เอเดรียใช่ฉันมีพื้นที่ว่างประมาณ 10GB มากกว่าเพียงพอ และใช่ทุกโต๊ะเช็คเอาท์ตกลง

@ Yzmir ใช่ปัญหาเดียวกันเกิดขึ้น

คำตอบ:


5

อาจเป็นปัญหาโดยที่max_allowed_packetไม่ได้รับการตั้งค่าที่สูงพอทั้งบนไคลเอนต์ (เช่น mysqldump) และเซิร์ฟเวอร์ (เช่น Amazon RDS) ฉันตั้งค่านี้เป็น 500M สำหรับทั้งคู่และดูเหมือนว่าจะแก้ไขปัญหาได้แล้ว

เนื่องจากตาราง schema ข้อมูลของ InnoDB ให้การประมาณจำนวนแถวเท่านั้นจึงเป็นการยากที่จะบอกได้ว่าภาพรวมของฉันรวมทุกอย่างจาก RDS อย่างแท้จริงหรือไม่ ตารางทั้งหมดอยู่ที่นั่น แต่จำนวนแถวแตกต่างกัน ฉันจะอัปเดตด้วยคำตอบที่ชัดเจนยิ่งขึ้นเมื่อฉันมีเวลาในการวิเคราะห์สคริปต์ให้ละเอียด


4

คุณเคยลองไหม

mysqldump --compress --add-drop-table data --routines --events  --comments --extended-insert -h {host} -u {user} -p {database} > dbdump.sql

นี่เป็นวิธีที่ง่าย ๆ ที่ฉันจะทำโดยไม่มีปัญหา โดยทั่วไปแล้วการถ่ายโอนข้อมูลด้วยวิธีนี้คุณจะได้รับทุกสิ่งที่คุณมี (ข้อมูลวัตถุและความคิดเห็นอันมีค่าบางครั้ง) ในช่วงเวลาหนึ่งโดยไม่สนใจธุรกรรมที่ไม่ได้รับการจัดการ


1
ฉันได้รับข้อผิดพลาดต่อไปนี้เมื่อพยายามเรียกใช้คำสั่งนั้น:mysqldump: Got error: 1049: "Unknown database 'data'" when selecting the database
Andy

1
@ แล้วคุณพูดอะไรผิดกับตอนนี้ dev.mysql.com/doc/refman/5.7/en/... ฉันคิดว่า "data" ไม่ควรอยู่ที่นั่นเลย
Rui Marques

1

เท่าที่ฉันเข้าใจเอกสาร mysql - ธุรกรรมเดี่ยวจะล้มเหลวหากมีการอ่านข้อมูลบนโต๊ะขณะที่คุณทิ้งข้อมูล ผลลัพธ์เมื่อทำงานโดยไม่มี "--force --single-transaction --quick" คืออะไร


ฉันได้รับข้อผิดพลาดเดียวกัน
Cerin

ฉันไม่พบสิ่งใดในเอกสารประกอบเพื่อสนับสนุนคำสั่งนี้ AFAIK การอ่านและเขียนบนโต๊ะได้รับการสนับสนุนเมื่อ - ดำเนินการธุรกรรมเดี่ยว แต่คำสั่งการเปลี่ยนแปลงโครงสร้างตาราง (ALTER, CREATE, TRUNCATE และอื่น ๆ ) อาจทำให้การถ่ายโอนข้อมูลล้มเหลวหรือให้ข้อมูลที่ไม่คาดคิด ( dev.mysql.com/doc/refman/5.7/en/… )
รหัสผู้บัญชาการ

1

เป็นไปได้อย่างสิ้นเชิงว่าโต๊ะเสียหาย ฉันไม่ได้หมายความว่าหน้าข้อมูลและ / หรือดัชนีเสียหาย อาจมีบางสิ่งที่ง่ายมากที่ถูกทำลาย

ฉันเพิ่งประสบปัญหากับสคริปต์สำรองบนเซิร์ฟเวอร์ Slave เมื่อฉันขนาน mysqldumped หลายฐานข้อมูล การเรียกใช้ mysqldump บนหนึ่งในฐานข้อมูลส่งผลให้ mysqldump มีขนาดเล็กมาก ฐานข้อมูลมี 80+ ตาราง อย่างไรก็ตาม mysqldump หยุดที่โต๊ะที่ห้าในฐานข้อมูล เมื่อฉันวิ่งSHOW CREATE TABLE tblname\Gบนโต๊ะบน Slave ฉันได้รับข้อผิดพลาด "Table Not Found" เมื่อฉันวิ่งไปหาSHOW CREATE TABLE tblname\GMaster คำอธิบายตารางจะปรากฏขึ้นตามที่คาดไว้

สิ่งที่เกิดขึ้นเป็นบ้าเล็กน้อย: ลูกค้าขอคืนค่าตารางและวิศวกรกู้คืนไฟล์. ibd ของตาราง InnoDB จากข้อมูลสำรองดิสก์ id tablespace ของไฟล์. ibd (ซึ่งเป็น 25) ไม่ตรงกับ id ของ tablespace ที่ลงทะเบียนใน ibdata1 (ซึ่งคือ 28)

ฉันแก้ไขปัญหาโดยการปิดทาสใช้ mysqldumping master และตั้งค่าการจำลองแบบจากศูนย์ โชคดีที่ข้อมูลและดัชนี spave มีจำนวนทั้งสิ้น 7GB ดังนั้นกระบวนการ rstore จึงไม่ใช่เรื่องใหญ่

นิทานสอนใจ

ปัญหาพื้นฐานคือ mysqldump ไม่ได้รายงานข้อผิดพลาดบน InnoDB เมื่อ id ของ tablespace ไม่ถูกต้อง เมื่อ mysqldump เสร็จสิ้นและไม่ได้ถ่ายโอนข้อมูลทุกตารางตามลำดับตัวอักษรนั่นแสดงว่ามันถูกยกเลิกโดยข้อผิดพลาดและทำได้โดยไม่ต้องพิมพ์ข้อความแสดงข้อผิดพลาด

ตรวจสอบให้แน่ใจ

  • คุณสามารถแสดงโครงสร้างของตารางโดยใช้ SHOW CREATE TABLE
  • คุณสามารถค้นหาทุกอย่างเกี่ยวกับตารางได้จาก INFORMATION_SCHEMA.TABLES

0

ต่อไปนี้เป็นเพียงการระดมสมองใน mysqldump และ InnoDB:

โปรดคิดเกี่ยวกับพฤติกรรมของ mysqldump เทียบกับตาราง InnoDB หากมีเพจสกปรกใน InnoDB Buffer Pool ที่อยู่ในตารางที่คุณกำลังดัมพ์หน้าสกปรกของตารางนั้นจะต้องถูกล้างออกไปยังดิสก์ก่อนที่จะSELECT /* SQL_NO_CACHE */สามารถดำเนินการกับมันได้

เนื่องจากคุณกำลังใช้ Amazon RDS ความรู้สึกของฉันคือฐานข้อมูลของคุณอยู่ในโครงสร้างพื้นฐานหลายแบบ (รู้สึกฟรีเพื่อแก้ไขคำสั่งนี้หากฉันใช้วิธีนี้มากเกินไป) ฐานข้อมูลอื่นอาจใช้ InnoDB Buffer Pool ที่แชร์ไฟล์เมตาดาต้าที่ใช้ร่วมกัน (ibdata1) และ tablespace ที่ใช้ร่วมกัน (ibdata1 ถ้าปิดใช้งานinnodb_file_per_table )

อาจมีความซ้ำซ้อนของฐานข้อมูลที่เกิดขึ้นซึ่งอาจส่งผลกระทบต่อMVCCกับฐานข้อมูลแม้ว่าจะเป็นชุดข้อมูลขนาดเล็ก

คุณอาจต้องการเพิ่มinnodb_lock_wait_timeout (ค่าเริ่มต้น 50 วินาที)ในเซสชั่น mysqldump ของคุณเพื่อดูว่าสิ่งนี้มีผลกับ Amazon RDS หรือไม่หรือให้ Amazon เพิ่มขีด จำกัด นี้) นอกจากนี้ลองทดสอบด้วยการทิ้งตารางแต่ละรายการ

อัพเดท 2011-11-14 17:58 EDT

ลองดำเนินการนี้ภายในเซสชัน DB ของคุณ (ตั้งค่าเป็นสองนาที):

SET innodb_lock_wait_timeout = 120;

innodb_lock_wait_timeout เป็นพารามิเตอร์แบบคงที่ใน RDS ที่ไม่สามารถเปลี่ยนแปลงได้
Cerin

@Cerin: ตามเอกสารคุณสามารถตั้งค่าในเซสชั่นของคุณ
RolandoMySQLDBA

คุณหมายถึงอะไร "เซสชันของฉัน"? mysqldump ไม่มีรายการตัวเลือกในการปรับการหมดเวลา
Cerin

ขออภัยฉันมองย้อนกลับไป ฉันหมายถึงว่าตั้ง innodb_lock_wait_timeout ใน Amazon RDS
RolandoMySQLDBA
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.