กำลังสำรองฐานข้อมูล MySQL ใน Git เป็นความคิดที่ดีหรือไม่

57

ฉันพยายามปรับปรุงสถานการณ์การสำรองข้อมูลสำหรับแอปพลิเคชันของฉัน ฉันมีแอพพลิเคชั่น Django และฐานข้อมูล MySQL ฉันอ่านบทความแนะนำการสำรองฐานข้อมูลใน Git

ในมือข้างหนึ่งฉันชอบมันจะเก็บสำเนาของข้อมูลและรหัสในการซิงค์

แต่ Git นั้นออกแบบมาสำหรับรหัสไม่ใช่สำหรับข้อมูล เช่นนี้มันจะทำงานพิเศษมากมายซึ่งต่างจากการถ่ายโอนข้อมูล MySQL ทุกการกระทำซึ่งไม่จำเป็นจริงๆ หากฉันบีบอัดไฟล์ก่อนจัดเก็บไฟล์ git จะยังคงแตกต่างกันหรือไม่?

(ปัจจุบันไฟล์การถ่ายโอนข้อมูลถูกยกเลิกการบีบอัด 100MB, 5.7MB เมื่อบีบอัดไฟล์)

แก้ไข: คำจำกัดความสคีมาของรหัสและฐานข้อมูลมีอยู่แล้วใน Git จริง ๆ แล้วเป็นข้อมูลที่ฉันกังวลเกี่ยวกับการสำรองตอนนี้

— wobbily_col
แหล่งที่มา

13

หาก บริษัท ของคุณมีแผนก IT (ops) พวกเขาควรจัดการเรื่องนี้

— Michael Hampton

1

ข้อมูลเป็นส่วนหนึ่งของแอปพลิเคชันหรืออะไรที่สร้างขึ้นผ่านแอปพลิเคชัน

— Winston Ewert

1

Git จะพยายามกระจายไฟล์ทั้งหมดเมื่อคุณเรียกใช้git gc(หรือเป็นพื้นฐานgit repack; git จะตามค่าเริ่มต้นที่กำหนดค่าได้เรียกใช้โดยอัตโนมัติเป็นครั้งคราว) มันจะทำให้มันยุบตัวเสมอดังนั้นมันอาจจะเป็นการดีกว่าถ้าคุณเก็บมันไว้แบบไม่บีบอัด

— Jan Hudec

1

เป็นฐานข้อมูลประเภทใด: เป็นฐานข้อมูลการผลิตหรือการพัฒนา

— el.pescado

6

viget.com/extend/backup-your-database-in-gitเขาเป็น "นักพัฒนาอาวุโส"

— wobbily_col

101

ก่อนที่คุณจะสูญเสียข้อมูลใด ๆ ให้ฉันลองแนะนำมุมมองดูแลระบบสำหรับคำถามนี้

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

นี่คือปัญหาที่ฉันสามารถคาดการณ์ได้ด้วยการพยายามสำรองฐานข้อมูลของคุณในคอมไพล์:

พื้นที่เก็บข้อมูลจะเพิ่มขึ้นอย่างมากในทุก ๆ "การสำรองข้อมูล" เนื่องจากgit เก็บวัตถุทั้งหมด (แม้ว่าจะถูกบีบอัด) และแตกต่างออกไปในภายหลัง (เช่นเมื่อคุณเรียกใช้git gc)และเก็บประวัติไว้ตลอดไปคุณจะมีข้อมูลจำนวนมากที่คุณไม่ต้องการหรือต้องการ คุณอาจต้อง จำกัด จำนวนหรือระยะเวลาการเก็บข้อมูลสำรองที่คุณทำเพื่อประหยัดพื้นที่ดิสก์หรือด้วยเหตุผลทางกฎหมาย แต่เป็นการยากที่จะลบการแก้ไขเก่าออกจาก repo gitโดยไม่มีความเสียหายด้านหลักประกันจำนวนมาก
การกู้คืนจะถูก จำกัด ไว้เฉพาะเวลาที่คุณเก็บไว้ในที่เก็บและเนื่องจากข้อมูลมีขนาดใหญ่มากการย้อนเวลามากกว่าเวลาเล็กน้อยอาจจะช้า ระบบสำรองข้อมูลที่ออกแบบมาเพื่อวัตถุประสงค์จะ จำกัด ปริมาณข้อมูลที่จัดเก็บในขณะที่อาจให้ความละเอียดมากขึ้นและให้การกู้คืนที่เร็วขึ้นลดการหยุดทำงานในกรณีที่เกิดภัยพิบัติ โซลูชันการสำรองข้อมูลที่ทราบถึงฐานข้อมูล ( ตัวอย่าง ) ยังสามารถให้การสำรองข้อมูลอย่างต่อเนื่องเพื่อให้แน่ใจว่าไม่มีธุรกรรมใดสูญหาย
ความมุ่งมั่นมีแนวโน้มที่จะช้าเช่นกันและช้าลงเมื่อฐานข้อมูลเติบโตขึ้น โปรดจำไว้ว่า git นั้นเป็นที่เก็บข้อมูลคีย์ - ค่าที่แม็พกับระบบไฟล์และดังนั้นจึงขึ้นอยู่กับคุณสมบัติประสิทธิภาพของระบบไฟล์ที่สำคัญ เป็นไปได้สำหรับระยะเวลานี้ในที่สุดเกินช่วงเวลาการสำรองข้อมูลและ ณ จุดนั้นคุณไม่สามารถตอบสนอง SLA ของคุณได้อีกต่อไป ระบบสำรองข้อมูลที่เหมาะสมนั้นใช้เวลาในการสำรองนานกว่าเมื่อข้อมูลเติบโตขึ้น แต่ไม่มากนักเนื่องจากระบบจะจัดการขนาดของตัวเองโดยอัตโนมัติตามนโยบายการเก็บรักษาที่คุณจะกำหนดค่า

แม้ว่าข้อเท็จจริงที่ว่ามีสิ่งที่น่าสนใจหลายอย่างที่คุณสามารถทำได้กับดัมพ์ฐานข้อมูลถ้าคุณใส่มันเข้าไปในคอมไพล์โดยรวมแล้วฉันไม่สามารถแนะนำมันเพื่อจุดประสงค์ในการสำรองข้อมูล โดยเฉพาะอย่างยิ่งเนื่องจากระบบสำรองข้อมูลนั้นมีอยู่อย่างกว้างขวาง (และส่วนใหญ่เป็นโอเพ่นซอร์ส) และทำงานได้ดีขึ้นมากในการรักษาข้อมูลของคุณให้ปลอดภัยและทำให้สามารถกู้คืนได้โดยเร็วที่สุด

— Michael Hampton
แหล่งที่มา

นี่เป็นคำตอบที่ดีที่สุดเนื่องจาก Michael ได้กล่าวถึงประเด็นเรื่องความมั่นคง ทั้งนี้ขึ้นอยู่กับขนาดและการใช้งานของฐานข้อมูลสแนปชอตไม่สามารถสร้างข้อมูลได้อย่างน่าเชื่อถือ ณ จุดที่กำหนดและคุณมีแนวโน้มที่จะพบปัญหาข้อ จำกัด การจำลองอาจเป็นสิ่งที่คุณต้องการค้นหา - dev.mysql.com/doc/refman/5.0/en/replication.html

— Aaron Newton

4

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

— Maximus Minimus

2

@JimmyShelter มีโรงเรียนคิดว่า DevOps หมายความว่าไม่ว่า Dev และ Ops ทำงานกันอย่างใกล้ชิด แต่ที่ Dev จริงไม่ Ops มันมักจะทำงานได้ไม่ดี แต่นั่นก็ไม่ได้หยุดที่คนจะลอง

— Michael Hampton

นี่ควรเป็นคำตอบที่ยอมรับได้ มันอธิบายข้อกำหนดและจุดประสงค์ของระบบสำรองอย่างชัดเจนจากนั้นแสดงให้เห็นว่าระบบคอมไพล์ไม่เหมาะสม คะแนนโบนัสพิเศษสำหรับการอภิปรายความสอดคล้องและประสิทธิภาพ

— Gabriel Bauman

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

— logc

39

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

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

เนื้อหาจริงของCREATEตารางjust -d เหล่านั้นไม่มีส่วนเกี่ยวข้องกับเวอร์ชันของซอร์สโค้ดของคุณ ลองนึกภาพคุณติดตั้งซอฟต์แวร์รุ่น 1.0 ของคุณบนเซิร์ฟเวอร์ A และบนเซิร์ฟเวอร์ B ซึ่งใช้ใน บริษัท ต่าง ๆ โดยทีมงานที่แตกต่างกัน หลังจากผ่านไปหลายสัปดาห์เนื้อหาของตารางจะแตกต่างกันมากแม้ว่าแบบแผนจะเหมือนกันทุกประการ

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

แก้ไข :

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

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

— LogC
แหล่งที่มา

2

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

— wobbily_col

10

จุดจัดเก็บสกีมาที่ไม่มีข้อมูลก็คือซอฟต์แวร์ของคุณควร "พร้อมใช้งาน" ทันทีหลังการติดตั้ง ถ้าเป็นวิกิก็ควรพร้อมที่จะเริ่มสร้างหน้าวิกิและเขียนบางสิ่งลงไป หากคุณติดตั้งสคีมาและเนื้อหาแสดงว่า wiki ของคุณเต็มไปด้วยหน้า Wiki X หลังการติดตั้ง ... นั่นไม่ใช่ "ติดตั้งระบบ wiki เพื่อเขียนเนื้อหาของเรา" แต่ "คัดลอก wiki จากที่อื่นเพื่ออ่าน" .

— logc

3

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

— LogC

2

@wobbily_col รูปแบบไบนารีที่ไม่ใช่ข้อความมีค่า จำกัด ในบริบทของการควบคุมแหล่งที่มา คุณไม่สามารถdiffมันคุณจะไม่สามารถสาขา / ผสานมัน ฯลฯ ดังนั้นในขณะที่คุณอย่างแน่นอนสามารถใช้คอมไพล์ในการจัดเก็บฐานข้อมูลคนส่วนใหญ่ชอบที่จะสคริปต์โครงสร้างฐานข้อมูลเช่นเดียวกับข้อมูลที่จำเป็น มันเป็นการประนีประนอมระหว่างการทำงานอีกเล็กน้อย แต่ให้รายชื่อของคุณสมบัติด้านบน คุณจะต้องพิจารณาว่านี่เป็นความคิดที่ดีสำหรับโซลูชันของคุณหรือไม่ ไม่เช่นนั้นคุณอาจได้รับ GIT เพื่อจัดเก็บฐานข้อมูลโดยตรง แต่มันก็ไม่เหมาะกับงาน

— Daniel B

3

@RaduMurzea: ฉันคิดว่านี่เป็นคำถามของหลักการ ระบบควบคุมเวอร์ชันได้รับการออกแบบมาเพื่อจัดการซอร์สโค้ดไม่ใช่สำหรับไบนารี มันไม่ใช่คำถามเรื่องขนาด ไม่ไม่ควรทิ้งฐานข้อมูลลงในที่เก็บเช่นเดียวกับวิดีโอการฝึกอบรมที่ไม่ควรทำการเช็คอิน แต่ไม่มีใครหยุดคุณจากการทำเช่นนั้น :)

— logc

7

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

ด้วยเหตุผลเหล่านี้ฉันไม่เห็นประโยชน์ใด ๆ ในการจัดเก็บไฟล์สำรองสำหรับวันที่ 1 และวันที่ 2 จากนั้นจึงเห็นความแตกต่างระหว่างไฟล์สำรองสองไฟล์ มันจะต้องมีงานพิเศษและไร้ประโยชน์มากมาย แทนที่จะใช้ GIT เพื่อจัดเก็บการสำรองฐานข้อมูลเมื่อคุณส่งรหัสใหม่ให้เก็บการสำรองฐานข้อมูลในเส้นทางที่แตกต่างคั่นด้วยวันที่และเวลาและใส่รหัสของคุณในการอ้างอิงถึงการสำรองฐานข้อมูลใหม่ที่สร้างขึ้นสำหรับแต่ละรุ่นโดยใช้แท็ก ตามที่มีคนแนะนำแล้ว

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

จากนั้นฉันไม่แนะนำให้เก็บข้อมูลสำรองโดยใช้ GIT ใช้โซลูชันซอฟต์แวร์สำรองข้อมูลที่ดีแทน (มีบางส่วนที่นี่ ) ซึ่งจะให้ข้อมูลที่ละเอียดยิ่งขึ้นและจะช่วยให้คุณรักษาข้อมูลของคุณให้ปลอดภัยและทำให้คุณปลอดภัย การกู้คืนข้อมูลที่ง่ายและรวดเร็วในกรณีที่เกิดภัยพิบัติ

— Alberto Solano
แหล่งที่มา

บางทีผู้ลงคะแนนจะอธิบายว่าทำไมเขา / เธอจึงลงคะแนน ..

— Alberto Solano

1

ไม่ใช่ downvoter แต่ฉันคิดว่าวิธีนี้จะนำเสนอความขัดแย้งผสานที่เคยนำเสนอซึ่งไม่เอื้อต่อสาขาบ่อยครั้งรวมเวิร์กโฟลว์บ่อยครั้งที่ผู้ใช้คอมไพล์ส่วนใหญ่ต้องการ

— Daniel B

@DanielB ฉันเสนอที่จะไม่ใช้ระบบควบคุมเวอร์ชันเพื่อจัดเก็บไฟล์สำรองฐานข้อมูล ฉันคิดว่าปัญหาการสำรองฐานข้อมูลสามารถแก้ไขได้อย่างง่ายดายโดยไม่ต้องใช้ระบบควบคุมเวอร์ชันใด ๆ ระบบควบคุมเวอร์ชัน (GIT, TFS, SVN และอื่น ๆ .. ) ได้รับการออกแบบมาสำหรับซอฟต์แวร์ไม่ใช่การถ่ายโอนไฟล์หรือสำรองฐานข้อมูลหรือเพียงแค่จัดเก็บข้อมูล (มีวิธีแก้ไขปัญหามากมาย)

— Alberto Solano

ฉันคิดว่าผู้ใช้ส่วนใหญ่อ่านสองสามประโยคแรกและ downvote เพราะดูเหมือนว่าคุณจะพูดว่ามันใช้ได้

1

@ AlbertoSolano ฉันเห็น; แต่การอ่านคำถาม ("ฉันสามารถสำรองฐานข้อมูลของฉันใน GIT ได้หรือไม่?") และจากนั้นคำสั่งแรกของคุณ ("การเก็บไฟล์สำรองข้อมูล ... ") ก็ดูเหมือนว่าคุณกำลังพูดตรงกันข้าม คำตอบที่เหลือดูเหมือนจะบอกว่ามันไม่ได้อยู่ที่นี่หรือที่นั่นในขณะที่ฉันสงสัยว่าคนส่วนใหญ่คิดว่ามันเป็นซากรถไฟที่จะเกิดขึ้น

— Daniel B

1

คุณไม่ควรจัดเก็บข้อมูลไบนารีใน Git - โดยเฉพาะฐานข้อมูล
การเปลี่ยนแปลงรหัสและการเปลี่ยนแปลง DML ของฐานข้อมูลเป็นสิ่งที่แตกต่างกันโดยสิ้นเชิง

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

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

— Jehy
แหล่งที่มา

1

ทำไมไม่มีใครใช้ Git เพื่อสำรอง "บันทึกการจัดเก็บ" ที่สร้างโดย MySQL?

— ริ้น

1

เพียงเพราะมันไม่สมเหตุสมผล บันทึกการเก็บถาวรในสภาพแวดล้อมการผลิตค่อนข้างหนักและควรลบออกหลังจากทำการสำรองข้อมูลเต็มรูปแบบปกติ นอกจากนี้ยังไม่มีประโยชน์ที่จะใส่ไว้ในคอมไพล์ - ซึ่งเป็นที่เก็บข้อมูลในบางแง่มุมอยู่แล้ว Michael Hampton ให้คำตอบที่ดีเกี่ยวกับปัญหานี้ (ในหน้านี้)

— Jehy

1

ทำไมต้องหมุนบันทึกถ้าคุณจะเก็บสำเนาทุกอย่างในคอมไพล์? อาจเก็บไฟล์บันทึกสัตว์ประหลาดหนึ่งไฟล์

— wobbily_col