SQL Server Replication
ในบทความนี้ ปัญหาเริ่มจากการที่เรามี ฐานข้อมูล 2 ที่ ซึ่งเราจำเป็นต้อง ให้ข้อมูลในฐานข้อมูลทั้ง 2 นี้ update หากันตลอดเวลา เราจะทำได้อย่างไร
ลองนึกตัวอย่าง หากสมมุติว่าเรามีฐานข้อมูลในเครื่องของตัวเอง ไว้เพื่อทดสอบ และ เรามี ฐานข้อมูลที่อยู่บน Hosting สำหรับใช้งานจริง แล้ว ถ้าเราจะเอาข้อมูลจาก host backup เพื่อมา restore ในเครื่องทดสอบของเรา เองนั้นก็เป็นสิ่งที่ไม่ยากใช่มั้ยครับ
แต่หากว่า เราต้อง backup และ restore ทุกวัน หรือวันละ หลายๆครั้งเราจะทำยังไง ให้นั่งทำตลอดเวลา มันไม่ใช่เรื่องเล่นๆแน่ ทั้งวันคงไม่ต้องทำอย่างอื่นแล้ว ดังนั้นจึงจำเป็นที่จะต้องมีเทคโนโลยีที่เป็นตัวช่วยสำหรับเหตุการอย่างนี้ ขึ้นมา หรือก็คือการทำ Replication นั่นเอง เพื่อให้ข้อมูล จากที่หนึ่ง วิ่งไป หาข้อมูลอีกที่หนึ่ง แบบอัตโนมัติ
สำหรับในบทความนี้ ผมได้นำมาจาก เว็บไซต์ http://coresharp.net/blogs/article/archive/2008/01/01/sql-server-replication-pocket-pc-1.aspx ที่เขียนข้อมูลไว้ได้ มากครับ
สิ่งที่อยากจะเสริมก็คือเรื่องราวเกี่ยวกับ SQL Server CE ซึ่งจะถูกใช้เป็นโปรแกรมบริหารฐานข้อมูลสำหรับแอพพลิเคชัน .NET ที่ทำงานบน Pocket PC พวกคุณผู้อ่านบางคนคงจะรู้ว่า SQL Server นั้นบันทึกข้อมูลของฐานข้อมูลเป็นไฟล์ ถ้าเป็นเวอร์ชันพี่เบิ้มหน่อยอย่าง Enterprise หรือ Developer นั้นก็จะเป็นไฟล์ที่มีนามสกุล mdf (หรือ ndf) และถ้าเป็นเวอร์ชัน CE (ขอเรียกสั้นๆหน่อยนะครับ) ก็จะเป็นไฟล์นามสกุล sdf ทีนี้เจ้าไฟล์ sdf ตัวนี้จะรับข้อมูลเริ่มต้นมาจากฐานข้อมูลศูนย์กลาง แล้วมันก็จะถูกใช้งานเฉพาะตัวสำหรับสมาร์ทดีไวส์หนึ่งๆเท่านั้นเอง และเมื่อถึงระยะเวลาหนึ่งมันก็จะต้องทำการซิงโครไนส์กับฐานข้อมูลศูนย์กลาง เพื่อนำรายละเอียดการเปลี่ยนแปลงที่มันบันทึกไว้ไปบันทึกและดึงข้อมูลจากฐานข้อมูลศูนย์กลางมาอัพเดพข้อมูลของมัน การซิงโครไนส์ดังกล่าวมีวิธีให้เลือกทำได้ 2 วิธีคือ RDA (Remote Data Access) หรือไม่ก็ Merge Replication โดยหลายตำรารวมถึงแหล่งข้อมูลความรู้ส่วนใหญ่จะแนะนำให้ใช้วิธี Merge Replication เหตุผลหลักก็คือความสามารถที่สูงส่งกว่านั่นเอง
ถ้ากล่าวโดยรวมๆแล้ว Replication นั้นได้รับการกล่าวขานจากนักวิจารณ์, DBA, Consultant จำนวนมากว่าเป็นฟีเจอร์ที่ดีที่สุดและน่าชื่นชมที่สุดฟีเจอร์หนึ่งเลยทีเดียว งานที่ต้องดำเนินการแบบกระจาย (Distributed Transaction) สามารถดำเนินไปด้วยประสิทธิภาพที่ดีเมื่อเลือกใช้ Replication เป็นโซลูชัน งานดังกล่าวจะรวมถึง
- การกระจายและรวบรวมข้อมูลจากสำนักงาน(หรือสาขา)ที่กระจายอยู่ในหลายภูมิภาค
- แอพพลิเคชันแบบ Scaling Out
- การเตรียมข้อมูลสำเนาให้ใช้ในการออกรายงานหรืองานที่ไม่มีการเปลี่ยนแปลงข้อมูล
- การทำ Data Warehouse
คำจำกัดความอย่างสั้นๆของ Replication คือการทำสำเนาข้อมูลซึ่งอาจจะเล็กแค่หนึ่งเทเบิลหรือใหญ่ถึงขนาดมีข้อมูลครบทั้งฐานข้อมูล แล้วกระจายออกไปใช้งานในแหล่งอื่นๆที่มีความสัมพันธ์กัน และยังสามารถกำหนดให้นำข้อมูลที่มีการเปลี่ยนแปลงจากแหล่งใดๆ (ที่ได้รับการกระจายข้อมูลให้ในตอนแรก) กลับมาอัพเดตให้กับแหล่งอื่นๆที่เกี่ยวข้องกันด้วย
สิ่งที่ควรพูดถึงต่อไปเกี่ยวกับ Replication ก็คือองค์ประกอบหลัก ซึ่งเกิดขึ้นและทำงานร่วมกันหลังจากการกำหนดค่าใน SQL Server ขึ้นมาแล้ว ไมโครซอฟท์อุปมาอุปมัยงาน Replication เหมือนเป็นธุรกิจสิ่งพิมพ์ (นิตยสาร, วารสาร) ซึ่งองค์ประกอบที่สำคัญคือ
- Publisher เป็นเซิร์ฟเวอร์ที่ให้กำเนิดข้อมูลที่จะส่งกระจายออกไปนั่นเอง ข้อมูลที่เตรียมไว้และจะส่งกระจายออกไปแต่ละครั้งนั้นจะเรียกว่า Publications (สิ่งตีพิมพ์) ซึ่งประกอบขึ้นมาจาก Articles (บทความ) โดยแต่ละ Article ก็จะเป็นลอจิคัลเทเบิล ขึ้นอยู่กับการกำหนดค่าของ Replication เองว่า Article หนึ่งๆอาจจะเป็นหนึ่งเทเบิลหรือหนึ่งวิวเลยก็ได้ (เทเบิล<table> และวิว<view> นั้นคาดว่าผู้อ่านส่วนใหญ่น่าจะแยกแยะและเข้าใจความหมายได้ดี) หรืออาจจะเป็นกลุ่มของคอลัมน์จากเทเบิล/วิวใดๆ โดยไม่ได้ดึงมาครบทั้งเทเบิล/วิวก็ได้
- Subscriber เป็นเซิร์ฟเวอร์ที่คอยรับ Publications (หรือไปดึงเอามา) ที่ Publisher ผลิตออกมา ก่อนจะรับหรือไปดึงมา ต้องจัดการเรื่อง Subscription (การสมัคร) ให้เรียบร้อยก่อนซึ่งมีอยู่ 2 แบบได้แก่
Pull Subsciption เป็นการสมัครเพื่อที่ Subscriber จะได้ไปดึงข้อมูล Publications มาใช้งานได้ หรือกล่าวได้ว่าเป็นการทำงานหรือความรับผิดชอบของเซิร์ฟเวอร์ที่เป็น Subscriber เองในการไปรับข้อมูล Publications มา เหมาะกับเซิร์ฟเวอร์ที่ไม่ได้เชื่อมต่อกับเซิร์ฟเวอร์ที่เป็น Publisher อย่างสม่ำเสมอ
Push Subscription เป็นการสมัครเพื่อที่เซิร์ฟเวอร์ที่เป็น Publishers จะเป็นฝ่ายดำเนินการส่งข้อมูลออกมาให้เซิร์ฟเวอร์ที่เป็น Subscribers เอง การทำงาน(รวมไปถึงการใช้ทรัพยากรระบบ) จะเกิดขึ้นที่ Distributors - Distributor เป็นเซิร์ฟเวอร์ที่ทำหน้าที่รวบรวม Publications จาก Publishers (หลาย Publishers สามารถใช้งาน Distributor เดียวกันร่วมกันได้) ก่อนจะส่งต่อออกไปที่ Subscribers (หรือ Subscribers มาดึงเอาไป) ถ้าเป็น Replication ที่กำหนดค่าอย่างง่ายแล้ว Publisher กับ Distributor สามารถถูกกำหนดให้ทำงานอยู่บนเซิร์ฟเวอร์เดียวกันก็ได้ (ถ้ากล่าวในมุมมองของ SQL Server อาจกล่าวได้ว่าถูกกำหนดให้ทำงานอยู่ในอินสแตนส์ (Instance) เดียวกัน) ข้อมูล Publications จะถูกเก็บรวบรวมไว้ที่ฐานข้อมูลระบบชื่อ Distribution ซึ่งหากยังไม่มีการกำหนดให้เกิดงาน Replication ขึ้นก็จะไม่มีฐานข้อมูลนี้ปรากฏขึ้นมาที่เซิร์ฟเวอร์ที่เป็น Distributor
เมื่อรู้จักองค์ประกอบเรียบร้อยแล้ว ก่อนจะจบบทความตอนนี้ไป ขอโปรยไว้นิดนึงก่อนว่า Replication ใน SQL Server นั้นมีอยู่ด้วยกัน 3 ชนิด ได้แก่
- Snapshot Replication
- Transactional Replication
- Merge Replication
รายละเอียดนั้นจะมาบรรยายในบทความหัวเดียวกันนี้ในตอนต่อไป ติดตามกันต่อนะครับ ขอให้ทุกท่านประสบแต่สิ่งดี
**********************
การประมวลผล distributed transactions ร่วมกับ DTC นั้นทุกเซิร์ฟเวอร์ที่ทำงานแบบกระจายจะต้องออนไลน์ (พร้อมทำงาน) ด้วยกันทั้งหมด เมื่อทรานแซกชันย่อยที่แต่ละเซิร์ฟเวอร์ทำเสร็จก็จะถูกคอมมิทและจัดการด้วยขั้นตอนตามโปรโตคอล 2-phase commit ซึ่งหากข้อผิดพลาดเกิดขึ้นแม้แต่จุดเดียวทรานแซกชันโดยรวมจะถูกยกเลิก แต่หากไม่มีข้อผิดพลาดเกิดขึ้นเลย สภาพข้อมูลในทุกเซิร์ฟเวอร์ก็จะถูกอัพเดตไปพร้อมกัน เสมือนไม่มีดีเลย์ในทุกเซิร์ฟเวอร์ ถ้ามองในแง่ความสัมพันธ์แล้วกล่าวได้ว่าสภาพข้อมูลไม่เป็นอิสระจากกัน (ต้องถูกจัดการให้ถูกต้องเหมือนกันพร้อมกันไปตลอดเวลาในทุกเซิร์ฟเวอร์)
ทีนี้หากต้องเลือกสักทางเลือกก็คงต้องดูว่าระบบฐานข้อมูลนั้น ยอมรับได้แค่ไหนในระดับความเป็นอิสระจากกันของสภาพข้อมูลแต่ละเซิร์ฟเวอร์ (ต้องถูกต้องเหมือนกันตลอดเวลา หรือยอมให้ข้อมูลแต่ละเซิรฟเวอร์มีสภาพต่างกันได้บ้าง) << ความเป็นอิสระจากกันของสภาพข้อมูลของแต่ละเซิร์ฟเวอร์ = site autonomy >>
มาถึงตรงนี้ก็สามารถโยงไปถึง 3 ชนิดของ SQL Server replication ได้แล้วอันได้แก่
- Snapshot replication เป็นชนิดที่เรียบง่ายที่สุด ไม่มีการจัดการที่ซับซ้อนเหมือนอีก 2 ชนิด โดย publication ทั้งก้อนเต็มๆจาก publisher จะเป็นสิ่งเดียวที่จะนำมาใช้งาน ข้อมูลpublication แบบนี้ไมโครซอฟท์เรียกมันว่า snapshot (อันที่จริงข้อมูล snapshot นี้ replication อีก 2 ชนิดก็มีการใช้งานด้วยเช่นกัน) ข้อมูลการเปลี่ยนแปลงย่อยๆอื่นๆจะไม่มีการนำใช้ใน replication ชนิดนี้
- Transactional replication เริ่มต้นการทำงานนั้น publication แรกจะถือเป็นข้อมูล snapshot (ข้อมูลก้อนใหญ่ที่ใช้เป็นพื้นฐานแบบเดียวกับที่ snapshot replication ใช้) แต่มีความพิเศษตรงที่เมื่อมีการเปลี่ยนแปลงเกิดขึ้นกับ article (ลองย้อนกลับไปดูความหมายในตอนที่แล้วนะครับ) รายละเอียดการเปลี่ยนแปลงนั้นก็จะถูกรวบรวมจาก transaction log และนำส่งออกไปที่ subscriber อย่างต่อเนื่อง
- Merge replication คล้ายกับ transactional replication ในด้านการรวบรวมความเปลี่ยนแปลงของข้อมูลอย่างต่อเนื่อง แต่แทนที่จะส่งออกไปอย่างต่อเนื่องเช่นกัน จะมีการรวบรวมเป็นก้อนใหญ่กว่าแล้วค่อยส่งในลักษณะ batch ด้วยช่วงเวลาที่นานขึ้น นอกจากนี้ merge replication ยังมีการจัดการความขัดแย้งของข้อมูล (conflict resolver) ที่ดีเยี่ยมอีกด้วยเมื่อนำข้อมูลมาผสานหรือ merge กัน
หลังจากได้รู้จักกับทั้ง 3 ชนิดแล้ว ผู้อ่านอาจสงสัยว่ามันโยงกันหรือเปรียบเทียบกันได้อย่างไรกับ ‘การประมวลผล distributed transactions ร่วมกับ DTC’ ที่กล่าวถึงไปก่อนหน้านี้ บางคนอาจเดาได้แล้ว ใช่แล้วครับ…ประเด็น’ระดับความเป็นอิสระของสภาพข้อมูล’ นั่นเอง
จากรูปจะเห็นว่ากับการประมวลผล distributed transactions ร่วมกับ DTC นั้น ‘ระดับความเป็นอิสระจากกันของสภาพข้อมูล’ จะต่ำที่สุด จากนั้นก็จะไล่ไปที่ transactional replication และที่สูงที่สุดคือ merge replication
หรือกล่าวได้ว่า merge replication เป็นรูปแบบการทำงานที่แต่ละเซิร์ฟเวอร์ทำงานเป็นอิสระต่อกันสูงมาก เมื่อถึงเวลาอันเหมาะสมเวลาหนึ่งข้อมูลจากแต่ละเซิร์ฟเวอร์ก็จะถูกนำมาผสานกัน แน่นอนล่ะความขัดแย้งมีโอกาสเกิดขึ้นได้สูงเพราะต่างฝ่ายต่างทำงานเป็นอิสระจากกัน แต่ที่เซิร์ฟเวอร์ศูนย์กลางก็สามารถระบุเงื่อนไขและขั้นตอนสำหรับการจัดการกับความขัดแย้งดังกล่าวได้
และตอนนี้ก็สามารถโยงต่อมาได้ที่ Pocket PC applications ถึงเหตุผลที่ควรเลือกใช้ merge replication หลายคนคงเดาได้อีกว่าเพราะ Pocket PC นั้นจะให้ทำงานโดยเชื่อมต่อกับฐานข้อมูลศูนย์กลางตลอดเวลาคงลำบากหรือเป็นไปไม่ได้ ต้องใช้รูปแบบการทำงานแบบกระจายและต้องมีความเป็นอิสระสูงด้วย เมื่อถึงเวลาที่ต้องส่งข้อมูล (ที่บันทึกในไฟล์ sdf) ไปผสานที่ศูนย์กลางต้องคำนึงถึงวิธีการจัดการกับความขัดแย้งของข้อมูลที่อาจเกิดขึ้นด้วย (ตัวอย่างเช่น การบันทึกข้อมูลข่าวจากนักข่าวหลายๆคนใน Pocket PC ซึ่งเนื้อหาของข่าวเดียวกันอาจต่างกันได้ นั่นจึงต้องมีวิธีจัดการเมื่อนำมาผสานกันที่ศูนย์กลาง)
ที่จริงแล้วอยากบรรยายต่อในเรื่องของบรรดา agents ซึ่งพวกมันเป็นเซอร์วิสคอมโพเนนท์ที่ช่วยกันทำงาน replication ให้ลุล่วงไปได้ แต่จะทำให้บทความนี้ห่างไกลจากความเป็นบทความของ developer แต่จะกลายเป็นเข้าใกล้การเป็นบทความของ DBA ซะมากกว่า
