อะไรคือเหตุผลที่นักเทียบท่าไม่ควรใช้กับฐานข้อมูล

ฉันมีการสนทนากับเพื่อนเกี่ยวกับกรณีการใช้งานสำหรับนักเทียบท่า ผู้ชายคนหนึ่งในทีมต้องการใช้ Docker สำหรับทุกสิ่ง - เหมือนเสื้อคลุมกระบวนการยูนิกซ์ทั่วไป อีกคนคิดว่านักเทียบท่าควรใช้กับแอปพลิเคชั่นไร้สัญชาติเช่นMicroservicesและแอพสไตล์AWS Lambdaเท่านั้น

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

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

ฉันพยายามฟังและเข้าใจมุมมองของเขาทั้งในการแสดงความเห็นอกเห็นใจ แต่ก็ให้เหตุผลที่ดีกว่ากับเขาด้วย (เราทุกคนเข้ากันได้ดี - นี่เป็นการผสมผสานระหว่างการพูดคุยอย่างสนุกสนานและจริงจัง)

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

คำถามของฉันคืออะไรเหตุผลที่นักเทียบท่าไม่ควรใช้สำหรับฐานข้อมูลคืออะไร

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

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

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

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

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

(ฉันใช้ Oracle เป็นตัวอย่างเพราะฉันคุ้นเคยกับมันทั้งโลหะเปลือยและ dockerized และเพราะมันเป็นสัตว์ที่มีชื่อเสียงที่ค่อนข้างโด่งดังเพราะเป็นเพียงบิตที่ไม่สำคัญต่อการทำงานหากคุณผ่านการตั้งค่าเริ่มต้น)

• การบรรจุซอฟต์แวร์ DB ไว้ในคอนเทนเนอร์จะให้ประโยชน์ตามปกติ - มีเวอร์ชันเดียวกันทุกที่หลีกเลี่ยงปัญหาการพึ่งพา / การแชร์ไลบรารีสามารถหมุน DB เดียวกันในแล็ปท็อปนักพัฒนาหรือที่ใดก็ตามที่คุณต้องการ
• มันเป็นสแน็ปการไปทำงานที่ใดก็ได้; การอัปเดตเป็นเรื่องเล็กน้อยและอื่น ๆ ใช้ประโยชน์จากนักเทียบท่าทั้งหมด มีอิมเมจ Oracle บน Dockerhub ซึ่งช่วยให้คุณสามารถหมุน DB ที่ทำงานได้ในหนึ่งหรือสามนาที (และสำหรับหลักสูตรอื่น ๆ เช่นกัน)
• ผู้คนทำการทดสอบประสิทธิภาพและไม่พบความแตกต่างของ I / O ระหว่างปริมาณและโลหะเปลือย ( https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/ , https: // stackoverflow .com / คำถาม / 21889053 / what-is-the-the-runtime-performance-cost-of-a-docker-container )
• ใต้ฝากระโปรงมันไม่เหมือน Docker ที่สกัดกั้น I / O ทั้งหมดอย่างไรก็ตาม มันเพิ่งได้รับการสร้างสรรค์ด้วยเครื่องมือ Linux มาตรฐาน (ผูกติดในกรณีนี้ mangling ของตารางเคอร์เนลภายในที่ทำให้ Docker-fu เป็นไปได้เลย)
• เห็นได้ชัดว่านั่นไม่ได้หมายความว่าคุณสามารถเรียกใช้อินสแตนซ์ของฐานข้อมูลได้สองอินสแตนซ์และให้พวกเขาทำงานกับไฟล์เดียวกัน แต่ไม่มีใครบอกได้ นักเทียบท่าไม่ให้คุณเข้าถึงไดรฟ์ข้อมูลพร้อมกันโดยอัตโนมัติและไร้ที่ติอย่างน่าอัศจรรย์และไม่เคยแสร้งทำเช่นนั้น ส่วนที่เหลือของผลประโยชน์ยังคงใช้ หากฐานข้อมูลของคุณไม่พบข้อขัดแย้งเช่นนี้คุณควรส่งสคริปต์ CMD ไปยังรูปภาพที่ปฏิเสธการหมุนที่เก็บคอนเทนเนอร์ที่สองเมื่อใช้งานไดรฟ์ข้อมูลอยู่แล้ว
• คุณจะต้องระมัดระวังให้มากขึ้นเล็กน้อยในการหมุนขึ้น / ปิดภาชนะ (เช่นเดียวกับที่คุณจะไม่เพียงแค่ปิดเซิร์ฟเวอร์ DB โลหะเปลือย) แต่ควรจัดการได้ค่อนข้างดี

ตอนนี้ขึ้นอยู่กับสถานการณ์อาจมีเหตุผลที่อ่อนนุ่มที่จะไม่ทำ:

• ตัวอย่างเช่น Oracle (บริษัท ) จะไม่สนับสนุนคุณอย่างแน่นอนหากคุณเรียกใช้ RDBMS ในคอนเทนเนอร์ Docker แต่บางทีคุณกำลังใช้อิมเมจ Oracle RDBMS ที่ถูกปรับเทียบเท่านั้นสำหรับนักพัฒนาและสภาพแวดล้อมการทดสอบซึ่งคุณไม่ต้องการการสนับสนุนในทุกกรณีสำรองไว้สำหรับเซิร์ฟเวอร์การผลิตโลหะเปลือย (แต่อย่าลืมจ่ายใบอนุญาตของคุณ ... )
• หาก ops guys ไม่คุ้นเคยกับ Docker อาจเป็นการง่ายกว่าที่จะฆ่าทุกสิ่งโดยไม่ได้ตั้งใจทำลายไฟล์ข้อมูลของคุณ ฯลฯ
• หากคุณมีเครื่อง DB โลหะเฉพาะขนาดใหญ่อยู่แล้วพร้อมที่เก็บข้อมูล SAN จำนวนมากที่รวดเร็วและไม่ต้องใช้อะไรอีกแล้วคงไม่มีประเด็นที่จะใช้ Docker ในการจัดวางเซิร์ฟเวอร์เหล่านั้นเพราะคุณจะไม่หมุนเซิร์ฟเวอร์อีกต่อไปเมื่อมี คือ 100s of GB หรือแม้แต่ TB ของข้อมูล ท้ายที่สุดสำหรับการผลิต RDBMS อย่างเช่นออราเคิลนั้นมีความก้าวหน้าขั้นสูงมากในการทำซ้ำข้อมูลจำนวนเต็มการล้มเหลวที่ไม่มีการหยุดทำงาน ฯลฯ โปรดทราบว่าอาร์กิวเมนต์นี้เพิ่งบอกว่า "คุณไม่จำเป็นต้อง containerize RDBMS ของคุณ" มันไม่ได้บอกว่า "คุณไม่ควรทำ" - บางทีคุณอาจต้องการทำเพราะคุณต้องการที่จะเปิดตัวซอฟต์แวร์อัพเกรดฐานข้อมูลผ่านทางคอนเทนเนอร์หรือด้วยเหตุผลอื่นที่คุณสามารถจินตนาการได้

ดังนั้นคุณไป โดยรวมแล้วทำการเชื่อมต่อฐานข้อมูลของคุณอย่างน้อยที่สุดสำหรับนักพัฒนาของคุณ (ผู้ที่จะขอบคุณไปชั่วนิรันดร์) และสภาพแวดล้อมการทดสอบของคุณ ในการผลิตก็จะลงมารสชาติและมีอย่างน้อยฉันยังต้องการแก้ปัญหาที่ตั้งที่ดีที่สุดกับผู้เชี่ยวชาญ DBA / Ops - ถ้าพวกเขามีประสบการณ์การทำงานเซิร์ฟเวอร์ DB โลหะเปลือยแล้วโดยทั้งหมดหมายความว่าไว้วางใจพวกเขา เพื่อดำเนินการต่อ แต่ถ้าคุณเป็นผู้เริ่มต้นที่มีไอทีทั้งหมดในคลาวด์อย่างไรก็ตามคอนเทนเนอร์ Docker ก็จะกลายเป็นหัวหอมชิ้นต่อไปในภาพรวม

ฉันเขียนเกี่ยวกับเรื่องนี้ในเชิงลึกแต่นี่คือบทสรุป:

• การป้องกันการแยกสมอง (เลือกโหนดหลักมากกว่าหนึ่งโหนด) จำเป็นต้องแก้ไข การไม่ทำเช่นนั้นอาจเป็นความหายนะ

• ไม่มีโซลูชันหน่วยเก็บข้อมูลแบบแบ่งใช้ที่พร้อมใช้งานจริงเพื่อให้สามารถปิดฐานข้อมูลในอินสแตนซ์เดียวได้

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

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

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