เหตุใดไฟล์บันทึกข้อมูล bin ของ MySQL ยังคงมีอยู่หลังจากการล้างข้อมูลหรือลบทิ้ง?


12

ฉันใช้ PURGE BINARY LOGS เช่นเดียวกับ FLUSH LOGS แต่ไดเรกทอรี mysql ยังคงมีไฟล์เหล่านี้:

mysql-bin.000025
mysql-bin.000024
mysql-bin.000023
mysql-bin.000022
mysql-bin.000021
mysql-bin.000020
mysql-bin.000019
mysql-bin.index

มีเหตุผลทำไมการใช้คำสั่งไม่ทำงาน? ไฟล์เหล่านี้ใช้พื้นที่มาก ฉันต้องการกำจัดพวกเขาอย่างปลอดภัย

คำตอบ:


10

PURGE BINARY LOGSคำสั่งลบไฟล์ทั้งหมดเข้าสู่ระบบไบนารีระบุไว้ในแฟ้มดัชนีเข้าสู่ระบบก่อนที่จะมีชื่อไฟล์ที่ระบุไว้เข้าสู่ระบบหรือการประทับเวลา ไฟล์บันทึกที่ถูกลบจะถูกลบออกจากรายการที่บันทึกไว้ในไฟล์ดัชนีเพื่อให้ไฟล์บันทึกที่กำหนดกลายเป็นไฟล์แรกในรายการ

ฉันหวังว่าคุณจะลบบันทึกการทำงานแบบทวิภาคไปจนถึงการmysql-bin.000019ใช้คำสั่ง

PURGE BINARY LOGS TO 'mysql-bin.000019';

หากคุณต้องการล้างบันทึกทั้งหมดทำเช่นนั้น

PURGE BINARY LOGS TO 'mysql-bin.000025';

mysql-bin.000025นี้จะลบบันทึกไบนารีเกิน

UPDATE

คุณสามารถลอง

RESET MASTER;

RESET MASTER ลบไฟล์บันทึกไบนารีทั้งหมดที่ระบุไว้ในไฟล์ดัชนีรีเซ็ตไฟล์ดัชนีบันทึกไบนารีให้ว่างเปล่าและสร้างไฟล์บันทึกไบนารีใหม่

ผลของความRESET MASTERแตกต่างจาก PURGE BINARY LOGS ใน 2 วิธีหลัก:

  1. RESET MASTER ลบไฟล์บันทึกไบนารีทั้งหมดที่ระบุไว้ในไฟล์ดัชนีโดยปล่อยให้ไฟล์บันทึกไบนารีไฟล์เดียวที่ว่างเปล่าที่มีส่วนต่อท้ายเป็นตัวเลขเท่ากับ. 000001 ในขณะที่ตัวเลขจะไม่ถูกรีเซ็ตด้วย PURGE BINARY LOGS

  2. RESET MASTERไม่ได้ตั้งใจจะใช้ในขณะที่ทาสการจำลองกำลังทำงานอยู่ พฤติกรรมของRESET MASTERเมื่อใช้ในขณะที่ทาสกำลังทำงานไม่ได้กำหนด (และไม่ได้รับการสนับสนุน) ในขณะที่PURGE BINARY LOGSอาจถูกนำมาใช้อย่างปลอดภัยในขณะที่ทาสการจำลองกำลังทำงาน

CAVEAT โดย RolandoMySQLDBA

หากคุณรันRESET MASTERด้วยการเชื่อมต่อกับ Slaves และการทำงาน IO Thread ของแต่ละ Slave จะหายไปทันที การจำลองจึงใช้งานไม่ได้และคุณจะต้องใช้เวลาในการรับข้อมูลจาก Slaves ทั้งหมดที่ซิงค์อีกครั้ง หากคุณต้องการลบบันทึกไบนารีอย่างปลอดภัยจากอาจารย์โดยไม่ทำลายความสมบูรณ์ของการจำลองแบบนี่คือสิ่งที่คุณทำ:

  • ทำงานSHOW SLAVE STATUS\Gในแต่ละทาส
  • Relay_Master_Log_Fileจด นี่คือบันทึกไบนารีซึ่งมีคำสั่งล่าสุดดำเนินการสำเร็จใน Slave)
  • จากการแสดงทั้งหมดSHOW SLAVE STATUS\Gให้กำหนดว่าอันRelay_Master_Log_Fileใดที่เก่าที่สุด (ตัวอย่างเช่น 'mysql-bin.00123')
  • คุณสามารถเรียกใช้PURGE BINARY LOGS TO 'mysql-bin.00123';ไม่มีทาสจะเสียสถานที่

ผลกระทบโดยรวม? สิ่งนี้จะทิ้งไว้ข้างหลังล็อกไบนารีบนมาสเตอร์ที่มีคำสั่งที่ยังไม่ถูกเรียกใช้บนทาสทั้งหมดในตอนนี้


ใช่. ฉันได้ลองแล้ว ไม่ทำงาน.
lamp_scaler

ล้างข้อมูลไบนารีการบันทึกเป็น 'mysql-bin.000025'; เมื่อคุณเรียกใช้สิ่งนี้คือข้อผิดพลาด
อับดุลมานาฟ

ใช่. ฉันได้ลองแล้ว ไม่ทำงาน.
lamp_scaler

ฉันอัพเดตคำตอบแล้วคุณสามารถลอง RESET MASTER ได้
Abdul Manaf

1
@ydaetskcoR ไม่ฉันหมายถึงคนแก่ที่สุดจริงๆ ให้ฉันอธิบาย: ถ้าคุณเรียกใช้เมื่อCHANGE MASTER TOใดก็จะลบบันทึกการถ่ายทอดทั้งหมด ถ้าRelay_Master_Log_fileเป็นmysql-bin.00123นั่นคือบันทึกไบนารีที่เก่าแก่ที่สุดของ Master ที่ Slave รู้จัก หากmysql-bin.00123ไม่มีอยู่ใน Master อีกต่อไปคุณอาจสูญเสียสถานที่ที่เหมาะสมในการทำซ้ำจากถ้าคุณเรียกใช้งานใด ๆCHANGE MASTER TOบน Slave ที่ไม่ได้อ้างอิงบันทึกใหม่ สิ่งนี้สามารถถูกมองข้ามได้และคุณจะต้องทำการจำลองแบบด้วยตนเอง
RolandoMySQLDBA

5

ฉันไม่แน่ใจว่านี่คือสิ่งที่เกิดขึ้นกับคุณ แต่ในกรณีของฉัน MySQL ได้หยุดการบันทึก "การขี่จักรยาน" และไฟล์ mysql-bin.index ได้กลายเป็น "เสียหาย" ด้วยรายการไฟล์ binlog ที่ไม่ถูกต้อง

โดยเฉพาะไฟล์ดัชนีเริ่มต้นที่ mysql-bin.000001 และไปที่ mysql-bin.000220 แต่ก็เริ่มต้นอีกครั้งจาก 001 เมื่อฉันเปรียบเทียบสิ่งนี้กับไฟล์บนเซิร์ฟเวอร์ของฉันฉันเห็นว่าฉันมีไฟล์ตั้งแต่ 001 ถึง 022

ตอนแรกฉันพยายามPURGE LOGS TO 'mysql-bin.000022';แต่มันไม่ได้ผล

ในที่สุดฉันก็หยุด MySQL และแก้ไขไฟล์ดัชนีด้วยตนเองจนกว่ามันจะตรงกับไฟล์ที่ฉันมีบนเซิร์ฟเวอร์ของฉัน เมื่อฉันรีสตาร์ท MySQL มันจะทำความสะอาดไฟล์ binlog เพื่อเคารพการexpire_logs_daysตั้งค่าและเริ่มทำงานตามปกติอีกครั้ง


1
... และนั่นคือวิธีที่คุณรับมือกับการเปลี่ยนแปลงการบันทึกของ MySQL แม้ว่านี่จะเป็นเหตุการณ์ที่เกิดขึ้นได้ยากมาก ฉันต้องทำสิ่งนี้ สิ่งที่ตลกคือPURGE LOGSใช้งานได้เฉพาะภายใต้การตั้งค่าที่เหมาะ: 1) เมื่อบันทึกไบนารีติดต่อกัน 2) ทั้งหมดบันทึกไบนารีจะมีชื่ออยู่ในmysql-bin.indexแฟ้ม 3) mysql-bin.indexไม่มีบันทึกพิเศษไม่ได้กล่าวถึงในที่มี +1 !!!
RolandoMySQLDBA

3

ในกรณีของฉันPURGE BINARYไม่ได้ลบอะไรเลย

ฉันมีพาร์ทิชันของฉันที่การใช้งาน 100% (ฉันต้องทำความสะอาดบันทึกการทำงานช้าของฉันเพื่อให้มีพื้นที่ว่างเพียงพอที่จะเริ่ม mysql ใหม่) ดังนั้นสิ่งแรกที่ฉันทำคือเปลี่ยน/etc/my.cnfความคิดเห็นในบรรทัดlog-bin=mysql-bin(มันไม่จำเป็น ในเซิร์ฟเวอร์นี้อีกต่อไปและฉันลืมที่จะลบมัน) และจากนั้นฉันเริ่ม mysql (นี่เป็นสิ่งจำเป็นเพราะมีคิวที่รอคิวที่ป้องกันไม่ให้PURGE BINARYถูกดำเนินการ)

หลังจากนั้นฉันก็วิ่งPURGE BINARYแต่ไม่มีอะไรเกิดขึ้น ดังนั้นฉันอ่านคู่มือและพบว่า:

คำสั่งนี้ไม่มีผลหากเซิร์ฟเวอร์ไม่ได้เริ่มต้นด้วยตัวเลือก --log-bin เพื่อเปิดใช้งานการบันทึกแบบไบนารี

ดังนั้นฉันเปิดใช้งานอีกครั้งlog-bin=mysql-binในของฉัน/etc/my.cnfรีสตาร์ทกำจัดไฟล์ (ด้วยความสำเร็จในขณะนี้) แสดงความคิดเห็นบรรทัดอีกครั้งแล้วรีสตาร์ท หลังจากนี้ไฟล์จะถูกลบและไม่ได้สร้างอีกต่อไป


2

สิ่งนี้ใช้ได้สำหรับฉัน: (รุ่นเซิร์ฟเวอร์ MySQL: 5.6.14)

PURGE BINARY LOGS BEFORE NOW();

ลบบันทึกไบนารีทั้งหมดในระบบของฉัน


คำตอบของคุณจะทำงานตราบใดที่การบันทึกแบบไบนารีและไฟล์ดัชนีการบันทึกแบบไบนารีนั้นสอดคล้องกันอย่างสมบูรณ์แบบ ดูคำตอบdba.stackexchange.com/a/74498/877เพื่อดูว่ามันไม่ทำงาน คำตอบของคุณยังคงได้รับ +1 !!!
RolandoMySQLDBA

0

คุณสามารถลบบันทึกทั้งหมดได้อย่างง่ายดายด้วย:

PURGE BINARY LOGS BEFORE NOW();

หรือแทนที่ func NOW () ตามวันที่ด้วยเครื่องหมายคำพูด:

PURGE BINARY LOGS BEFORE '2018-02-15 00:00:00';

หรือคุณสามารถดำเนินการนี้โดยอัตโนมัติด้วยexpire_logs_days = 10ใน my.cnf โดยค่าเริ่มต้นexpire_logs_daysคือ0 = ไม่ลบบันทึก

(ที่มา )

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