มาทำความรู้จัก MariaDB Galera Cluster ในเบื้องต้น

เป็น note ที่เขียนไว้นานแหละ แต่ draft ไว้ไม่ได้โพส เลยมาโพสสรุปสักหน่อย

MariaDB Galera Cluster เป็น Synchronous replication แบบ master-master replication (Active-active multi-master topology) ต้องใช้ Server จำนวน 3 เครื่องขึ้นไปในการทำงาน โดยความสามารถของ MariaDB Galera Cluster นั้น เป็นการช่วยเสริมความมั่นคง และเหมาะกับระบบที่เน้นข้อมูลที่มีการเปลี่ยนแปลงอยู่บ่อยครั้ง เพราะจากแต่เดิมนั้น เรามักใช้ MySQL หรือ MariaDB ในรูปแบบ standalone server แบบเดิมๆ ซึ่งอาจจะปรับไปใช้รูปแบบโครงสร้างที่ชื่อว่า Asynchronous replication (master-slave replication) โดยรูปแบบดังกล่าวมีข้อเสียในด้านความมั่นคงของข้อมูลที่ master server ที่ใช้เพื่อ เพิ่ม ลบ และเปลี่ยนแปลงข้อมูล ที่มีเพียง server ตัวเดียวที่ทำงานเหล่านี้ได้ และมักเน้นหนักไปที่การอ่านข้อมูลมากกว่าการเปลี่ยนแปลงข้อมูล ซึ่งอาจเกิดเหตุการณ์ที่ทำให้ master server หยุดทำงานไป มีผลทำให้ไม่สามารถ เพิ่ม ลบ และเปลี่ยนแปลงข้อมูลได้ ทำให้การให้บริการเต็มรูปแบบนั้นหยุดลง ด้วยเหตุผลดังกล่าว เราจึงจำเป็นต้องหาแนวทางที่ชื่อว่า Synchronous replication หรือ multi-master replication (Active-active multi-master topology) ของ MariaDB Galera Cluster โดยต้องทำการย้ายฐานข้อมูลจาก MySQL หรือ MariaDB ในรูปแบบ standalone server หรือใช้รูปแบบโครงสร้าง Asynchronous replication (master-slave replication) ไปใช้ MariaDB Galera Cluster เพื่อใช้ในการแก้ไขปัญหาดังกล่าว

จุดสำคัญของตัว MariaDB Galera Cluster คือ มันสามารถอ่าน และเขียนได้จาก cluster node ใดๆ ก็ได้ โดยที่มีระบบ membership control สามารถปลดออกจากกลุ่มเมื่อพบความผิดพลาด หรือเพิ่ม cluster node อัตโนมัติเมื่อมีการเพิ่มเข้ามาในระบบ โดยข้อมูลในการจัดการภายในเป็นแบบเป็น parallel replication ระดับ row

สำหรับการเชื่อมต่อกับ MariaDB Galera Cluster นั้นสามารถใช้ MySQL Library โดยทั่วไป โดยไม่ต้องแก้ไข code ใดๆ (นอกจากแก้ไขตามข้อจำกัดของระบบ Cluster บางอย่าง)

แน่นอนว่ามีข้อดีก็ต้องมีข้อจำกัด โดยข้อจำกัดของ MariaDB Galera Cluster นั้นคือ

  • ใช้ได้แต่ InnoDB storage engine เท่านั้น ถ้ามี MyISAM storage engine ให้ alter เสียก่อน
  • การที่ MariaDB Galera Cluster สามารถเพิ่มข้อมูลที่ตัว node ใดๆ ก็ได้ ต้องปรับแก้ auto_increment_increment และ auto_increment_offset ให้สอดคล้องกับ cluster node ที่ใช้ auto increment ใน table ต่างๆ แนะนำให้ใช้การเพิ่มข้อมูล 1-2 cluster node เพื่อป้องกันการทำ auto increment ซ้ำซ้อนกัน
  • สำหรับการใช้ DELETE ต้องใช้กับ table ที่มี primary key คำแนะนำง่ายๆ ถ้าจะใช้ table ทุกๆ ตัวต้องมี primary key และการ DELETE ต้องทำผ่าน primary key
  • เมื่อเป็น multi-master replication การใช้ binlog-do-db และ binlog-ignore-db จึงทำไม่ได้ รวมไปถึงใช้ Query cache ไม่ได้ (แนะนำให้ใช้ Memcached แก้ไขปัญหาแทนได้)
  • ทำ LOCK/UNLOCK TABLES และใช้ XA transactions ไม่ได้ (แต่ยังใช้ Transaction ตามปรกติได้)
  • แนะนำให้ใช้เพียง character_set_server แบบ utf8 เท่านั้น
  • ไม่สนับสนุนบน Windows

สำหรับในการติดตั้งนั้นไม่ได้ยุ่งยากอะไรนัก ใช้ตัว configuration ของ wsrep ในการตั้งค่าต่างๆ (MySQL Write Set Replication; MySQL-wsrep) โดยเข้าไปแก้ไขใน my.cnf สามารถทำตาม ที่บทความ Install MariaDB Galera Cluster in Ubuntu ได้เลย

เมื่อแอพบน Windows 8.1 และ Windows Phone 8.1 กำลังรวมกันด้วย Universal WinRT อาจตัดสินอนาคตของ Microsoft

อนาคตของ Windows ในตลาด tablet และ mobile นั้นดูจะยังลุ่มๆ ดอนๆ อยู่พอสมควร อาจจะเพราะชะล่าใจ จนเข้ามาช้าไป อีกทั้งเข้ามาช้าก็เร่งเครื่องไม่ทันกระแส พัฒนาไล่ตามคู่แข่งแบบหวานเย็น จนเหล่านักพัฒนา และผู้ใช้ที่ติดตามฝั่ง Windows ได้แต่มอง platform อื่นๆ เค้าก้าวหน้าไปอย่างรวดเร็ว

แม้ว่าช่วงปีที่ผ่านมา จะเห็นได้ว่า Microsoft ได้วางแผนว่า Windows ในอนาคตจะต้องให้ประสบการณ์ในการใช้งานตั้งแต่หน้าจอประมาณ 3” จนถึง 30” แล้วมีประสบการณ์เดียวกัน ซึ่ง codename ชื่อ Windows Blue เป็นแผนงานที่วางไว้ในช่วงปีที่แล้วจนถึงปีนี้ แต่ดูเหมือนแผนงานฝั่ง Windows desktop และ tablet ก็ดูจะได้รับการตอบรับที่ดีในระดับหนึ่ง ซึ่งถูกมองว่าเป็นแผนงานอุดข้อเสียและปรับปรุงให้ดีขึ้นมากกว่า ส่วนในด้านของ Windows Phone ก็ช้ากว่าฝั่ง Windows เข้าไปอีก ด้วยการออก Windows Phone 8 GDR 1, GDR 2 และ GDR 3 ที่ดูเหมือนจะเป็นเพียงการไล่ตามในสิ่งที่ผู้เล่นในตลาดมีอยู่ก่อนแล้วมาก่อน 1-2 ปี

แต่จากข่าวในช่วงเดือนที่ผ่านมาของ Windows Phone 8.1 (codename: Blue) นั้น ได้สร้างความตื่นเต้นพอสมควรในด้านความสามารถที่มากมายกว่า Windows Phone 8 GDR 1 จนถึง GDR 3 รวมกันเสียอีก อีกทั้ง ส่วนที่น่าสนใจมากกว่านั้นคือ ได้มีข้อมูลที่รวมการพัฒนาแอพบน Windows 8.1 และ Windows Phone 8.1 เข้าด้วยกัน สร้างความน่าสนใจมากกว่าข่าวลือเรื่อง Microsoft มีความคิดจะนำแอพ Android มาทำงานบน Windows เสียอีก

จากเอกสาร Windows Phone 8.1 SDK ที่หลุดออกมานั้น เปิดเผยว่า Windows Phone 8.1 ช่วยให้นักพัฒนาสามารถสร้างแอพโดยใช้ Universal Windows Runtime (หรือเรียกอีกชื่อว่า Universal WinRT) ได้ โดยเป็นผลดีต่อต้นทุนในการพัฒนาแอพเป็นอย่างมาก ซึ่งชื่อ “WinRT” นั้น คงคุ้นหูกันมาก่อน เพราะมันคือชื่อ runtime ของแอพ Windows Store apps บน Windows RT และ Windows 8 อยู่ก่อนแล้ว นั้นหมายความว่า เราสามารถสร้างแอพที่ทำงานได้ทั้งบน Windows Phone 8.1 และ Windows 8.1 ได้ในการพัฒนาเพียงครั้งเดียว ในชื่อ “Universal Store apps” เพื่อใช้เรียกว่า runtime ใหม่ ให้แยกต่างหากจากของเดิมที่ชื่อ “WinRT”  เป็น “Universal WinRT” แน่นอนว่าสำหรับแอพเดิมที่เคยพัฒนาอยู่ก่อนแล้วบน Windows Phone 8 นั้นสามารถอัพเกรดแอพด้วยการคอมไพล์ไปใช้ Windows Phone Silverlight 8.1 (หรือเรียกอีกชื่อว่า WP Silverlight 8.1) แทนได้เช่นเดิม หรือจะพัฒนาโดยใช้ Universal WinRT ก็ได้โดยเริ่มต้นสร้าง Solution ใน Visual Studio ใหม่อีก Solution หนึ่งจาก Template ที่มีอยู่ใหม่

แต่ทั้งนี้ ด้วยข้อจำกัดของทั้ง Universal WinRT และ WP Silverlight 8.1 นั้นมีหลายส่วนในเบื้องต้น ซึ่งข้อจำกัดใน Universal WinRT นั้นยังมีอยู่มากตามเอกสารที่หลุดออกมา และคิดว่าน่าจะเข้าใกล้การพัฒนาจนไร้ข้อจำกัดในการผสานกันระหว่าง Windows 8และ Windows Phone ในอนาคต

ส่วนต่อมาที่น่าสนใจในเอกสารคือ Share โดยถ้าว่ากันตามจริง ใช้หลักการเดียวกับบน Windows 8 ที่ใช้การส่ง command ไปยังแอพปลายทาง (target app) และเมื่อแชร์จบแล้วจึงย้อนกลับมาที่แอพเดิม (source app) ทำให้ต่อการ การแชร์ระหว่างแอพจะทำได้สะดวกขึ้น และไล่ตามความสามารถของคู่แข่งได้สูสีมากขึ้น

สำหรับข้อมูลส่วนอื่นๆ ที่น่าสนใจตามเอกสาร SDK ที่หลุดมา จะเป็นส่วนของการเตรียมตัวและพัฒนาแอพให้สามารถทำงานบน Windows Phone 8.1 ได้อย่างราบรื่นและสมบูรณ์ รวมไปถึงทำความเข้าใจแนวคิดใหม่ของ Universal WinRT ที่กำลังจะเป็นส่วนสำคัญในการพัฒนาแอพในอนาคตด้วย

จากการวิเคราะห์นั้น คิดว่าการพัฒนาแอพที่สามารถทำงานได้กับอุปกรณ์ทั้ง desktop, tablet และ phone ในตัวเดียว อาจจะสร้างความยุ่งยากอยู่พอสมควร ในการแสดงผลให้แตกต่างกันในแต่ละอุปกรณ์ แต่ถ้ามองในมุมบริหารจัดการ และการจูงใจนักพัฒนาแอพบน desktop และ tablet มาพัฒนาบน phone และในทางกลับกัน นักพัฒนาบน phone ก็ขยับมาลงใน desktop และ tablet นั้นดูน่าสนใจมากขึ้น เพราะในขณะนี้ รูปแบบการพัฒนานั้นดูจะแตกต่างกันอย่างเห็นได้ชัด และการพัฒนาแอพบน Windows Store apps นั้นก็ง่ายกว่าบน Windows Phone apps อย่างมาก ซึ่งจุดนี้เองที่น่าสนใจว่าผู้เล่นจากฝั่งไหนจะลงมาเล่นมากกว่ากัน ต้องลองติดตามต่อไป ถ้าเอกสารที่หลุดมานั้นเป็นเอกสารจริง

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

ประสบการณ์ในการเปลี่ยนแบตเตอรี่ของ Nokia Lumia 920 จาก ศ. Nokia Care

ผมใช้ Nokia Lumia 920 มาประมาณ 1 ปีกับอีก 2 เดือนนิดๆ ถามว่าใช้แล้วมีความสุขไหม ก็ต้องบอกว่าโอเคในระดับที่ประทับใจ แน่นอนหลายคนที่รู้จักผมจะทราบว่าผมมันติ่ง Microsoft พอสมควร แต่แน่นอนห่วยก็ด่า ดีก็ชม มันก็ง่ายๆ ผมใช้ Lumia 920 และ Windows Phone 8 มาตั้งแต่เริ่มเปิดตัวใหม่ๆ ในไทย ช่วงเดือน พ.ย. 2012 จนวันนี้ 13 ก.พ. 2014 ถ้าพูดในเรื่องเสถียรภาพ ต้องบอกว่าไม่ค่อยผิดหวังเท่าไหร่ ในด้านการใช้งานทั่วไป ไม่เคยเจอว่าอยู่ๆ ดับไปเองสักครั้ง หรือรีเซตตัวเองในเวลาที่จำเป็นต้องใช้รีบๆ ส่วนเรื่องแอพก็ค่อยๆ มา แรกๆ ที่ใช้ก็หงุดหงิดเรื่องนี้ เพราะย้ายมาจาก Android แต่พอเริ่มทำใจ เริ่มปรับตัว ประกอบกับหลังๆ ดีขึ้นเป็นลำดับ

แต่ในช่วง 1-2 เดือนให้หลังมานี้อายุการอยู่ของแบตเตอรี่ของเครื่องค่อนข้างแย่ลง เลยหาข้อมูลการเปลี่ยนแบตเตอรี่ ซึ่งไม่ค่อยมีประสบการณ์ในการเปลี่ยนให้เน็ตให้ได้อ่าน หรือมีข้อมูลราคาของ ศ. Nokia Care เลย

ผมเลยตัดสินใจโทรเข้า Nokia Careline เพื่อสอบถามเรื่องราคาแบตเตอรี่ แต่ผมก็ได้ความน่าหงุดหงิดของ Nokia Careline กลับมาพอสมควร คือสอบถามเรื่อง ราคาแบตเตอรี่ ค่าดำเนินการเปลี่ยน และระยะเวลาในการเปลี่ยน แต่เจ้าหน้าที่ Nokia Careline กลับตอบคำถามลูกค้าไม่มีเซ้นสักท่าไหร่เลย คือ ตอบแบบโยนๆ ให้ไปสอบถาม ศ. Nokia Care เอง และไม่ได้ประสานงานช่วยลูกค้าอะไรมากไปกว่าบอกว่า ทาง Nokia Careline ไม่มีข้อมูลราคาในส่วนนี้ และให้โทรไปที่ ศ. Nokia Care ที่ใกล้ที่สุดมาแทน

พอได้ข้อมูลที่ไม่ค่อยได้ช่วยอะไรมากนัก ผมก็เลยโทรไปที่ ศ. Nokia Care ที่เราใกล้สุดตามที่ Nokia Careline แจ้ง คือ ศ. Nokia Care สาขา MBK แต่ไม่มีใครรับสาย ด้วยความสิ้นหวัง ก็เลยเข้า Live Chat ของ Nokia Care ผ่านเว็บ แล้วก็ได้คำตอบเดียวกับ Nokia Careline ในข้างต้น แต่รอบนี้ ได้เบอร์ ศ. Nokia Care สาขาอื่นๆ มาเพิ่มแล้วให้เราโทรไปสอบถาม ศ. Nokia Care อื่นๆ ที่ได้มาอีกรอบ แต่ท้ายที่สุด เจ้าหน้าที่ Live Chat ของ Nokia Care ก็แนะนำให้เข้าไปสอบถามที่ ศ. ที่ใกล้ที่สุด จะได้คำตอบที่ตรงที่สุด

โอเค … คือถ้าผมว่างมีเวลาเข้าไปที่ ศ. Nokia Care สาขา MBK ผมคงไม่โทรหา Nokia Careline หรือ Live Chat หรอก

อ่ะ ข้อเสนอให้ปรับปรุงในส่วนนี้คือ บริการ Nokia Careline และ Live Chat ควรจะมีข้อมูลในส่วนนี้ แม้จะมีคนสอบถามปีละ 2-3 หรือหลายสิบคน ก็ควรจะเป็นเรื่องที่ควรประเมิณได้ทางโทรศัพท์ เพราะไม่ได้เกี่ยวกับตัวเครื่องที่นำไปให้ช่างซ่อมที่ ศ. Nokia Care ตรวจสอบ ควรทำเหมือน check list แล้วเสนอราคาได้เลยว่าประมาณเท่าไหร่ คือไม่ต้องตรง 100% แต่พอจะเข้าใจ หรือเตรียมตัวได้เวลาเข้าไปที่ ศ. Nokia Care

โอเค จบเรื่องบ่นๆ ยาวๆ ด้านบน มาต่อว่าผมเปลี่ยนแบตเตอรี่มามีขั้นตอนอย่างไรบ้าง

การเปลี่ยนแบตเตอรี่ของ Nokia Lumia 920 สำหรับเครื่องหมดประกันแล้วนั้น ทาง ศ. Nokia Care มีค่าใช้จ่ายให้เราชำระอยู่ 2 ส่วน คือ ค่าแบตเตอรี่และค่าดำเนินการซ่อม รวม 1,670 บาท (รวม VAT 7% แล้ว) โดยเป็นค่าดำเนินการซ่อมในใบรับเครื่องระบุไว้ 400 บาท ส่วนที่เหลือคือค่าแบตเตอรี่

โดยแบตเตอรี่ที่เปลี่ยนใหม่จะมีประกันตัวแบตเตอร์รี่ 1 ปีหลังจากเปลี่ยนแบตเตอรี่ไปแล้ว โดยทาง ศ. Nokia Care จะออกใบเสร็จให้เราเก็บไว้ และคืนแบตเตอรี่เก่าให้เราด้วย

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

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

ทั้งหมดก็หวังว่าจะเป็นข้อมูลสำหรับคนที่จะเข้าไปเปลี่ยนแบตเตอรี่ ของ Nokia Lumia รุ่นที่เปลี่ยนแบตเตอรี่เอง โดยผู้ใช้งานไม่ได้ครับ ;)

2Uc2Nu

แอพ Android บน Windows platform เป็นไปได้แค่ไหน?

เป็นงานเขียนที่เป็นแนวคิดแบบเร็วๆ ที่ในตอนแรกว่าจะเขียนสั้นๆ บน facebook แต่คิดว่าน่าจะต่อยอดวิธีคิด และสร้างวิธีคิดที่ละเอียดได้มากขึ้น เลยเขียนลงที่นี่น่าจะดีกว่า โดยมาจาก “ข่าวลือ” ที่ว่า Microsoft มีแผนให้แอพบน Android รันบน Windows และ Windows Phone ได้

ในความเห็นส่วนตัวมองว่า ในระยะยาว Microsoft จะไม่ได้อะไรจากการที่สามารถทำให้แอพบน Android นั้นรันบน Windows platform ได้ (ผมใช้คำว่า platform เพราะต้องการพูดรวมๆ ทั้ง Windows และ Windows Phone) เนื่องจากการทำแบบนั้น ย่อมเท่ากับทำลาย ecosystem ของตัวเองที่กำลังสร้างขึ้นในระยะเวลา 2-3 ปีที่ผ่านมา ซ้ำร้ายอาจจะทำลาย ecosystem ทั้งหมดที่ตัวเองมีมาอย่างยาวนานอีกด้วย

ทำไมถึงเป็นเช่นนั้น …. ต้องย้อนกลับไปดูว่า ecosystem ที่ตัวเองกำลังสร้างขึ้นในช่วงที่ผ่านมา และยังเป็นอนาคตของ Microsoft อย่าง Windows Store apps และ Windows Phone apps นั้น การทำตามที่ข่าวลือออกมา อาจเป็นการทำลายความน่าสนใจใน ecosystem ลงโดยสิ้นเชิง ซึ่งเป็นเรืองที่ร้ายแรงมาก เพราะถึงแม้ ในระยะสั้น กองทัพแอพของ Android ที่มาลงใน platform จะมหาศาลมาก สร้างความน่าสนใจต่อการดึงดูดผู้ใช้ และนักพัฒนาให้หันกลับมาใช้ Windows platform เพื่อใช้ และพัฒนาแอพ Android ได้ในระยะสั้นๆ แต่ในระดับ ecosystem ที่ตัวเองถืออยู่ก่อนแล้วจะไม่โต สุดท้ายจะไม่รอดทั้งหมด เพราะหมายถึงไปลดความสำคัญของ ecosystem ที่มีอยู่ และอาจรุกไปถึง การที่นักพัฒนาถอยห่างออกจาก .NET Framework ไปใช้ชุดพัฒนาอื่นๆ ที่เหมาะสมกับการพัฒนาบน Android แทน เพราะดันไปลดความได้เปรียบในการควบคุม platform ที่มีอยู่ในอดีตตให้กับ Google

แน่นอนว่าการไม่เอา Android ก็อาจจะทำให้การต่อสู้ระยะยาวมีปัญหา ในความคิดเห็นส่วนตัวมองว่าควรใช้ Mobile division ที่กำลังจะปิดดีลกับทาง Nokia มาเป็นประโยชน์ อาจจะสร้าง ecosystem กันชน (คล้ายๆ กับ Amazon) เพื่อเหยียบเรือสองแคมไปก่อนเพื่อสร้างความคุ้นเคยในตลาดที่ Microsoft ไม่ถนัด (ผมมองว่าไม่ถนัดอย่างมาก จากการเห็นลักษณะง่อยๆ ของ Windows Phone 8 ในช่วง 1 ปีกว่าๆ) โดยนำเอาประสบการณ์ของ Nokia ที่มีประสบการณ์ในการพัฒนาโทรศัพท์ มาปรับปรุง ecosystem บน platform ของตนเอง ซึ่งจะเป็นเรื่องที่น่าจะดีกว่าในการทำกำไร และสร้างความคุ้นเคย พัฒนาซอฟต์แวร์อื่นๆ ให้ทำงานบน Android ให้ได้ดีมากขึ้น รวมไปถึงการเก็บค่าพัฒนา หรือเช่าใช้ตามแนวทางใหม่ของตัวเองด้วย

สำหรับตัวอย่างที่เห็นได้ชัดเจนที่สุดที่นำเอาแอพ Android มาทำงานบน platform ตัวเองแล้วไม่ประสบความสำเร็จอย่างสิ้นเชิง คือ BlackBerry ซึ่งในตัว BB 10 นั้น BlackBerry ได้ประกาศว่าสามารถที่จะพอตตัวแอพของ Android มาลงได้ไม่ยากนัก เพื่อหวังจะเพิ่มจำนวนแอพให้พุ่งขึ้นอย่างรวดเร็ว และวิ่งไล่ทัน Android ในระยะเวลาอันสั้น โดยหวังว่าจะใช้ความได้เปรียบตรงนี้ในการจูงใจผู้ใช้ และนักพัฒนา ให้หันกลับมาพัฒนาแอพในระดับ native ในที่สุด ซึ่งในตอนแรกที่เปิดตัวก็ดูว้าวดี แต่สุดท้ายนักพัฒนาก็เอาง่ายเข้าว่าด้วยการพอตตัวแอพจาก Android มาทั้งหมดโดยไม่ได้ปรับปรุงให้เข้ากับประสบการณ์การใช้งานของ BB 10 ที่แตกต่างกันในหลายๆ ส่วน และในบางแอพยังมีประสิทธิภาพที่แย่ (ถึงแย่มาก) อีกทั้งตัว runtime ของ BB 10 ที่ใช้สำหรับให้แอพ Android ทำงานนั้น ก็กินทรัพยากรมากกว่า ซึ่งเป็นผลร้ายต่อประสบการณ์ในการใช้งานระยะยาวของกลุ่มผู้ใช้ที่แย่จนรับไม่ได้ในที่สุด

ถ้า Microsoft จะดำเนินตามแผนที่ BlackBerry เคยทำ อาจจะจบไม่สวยก็เป็นได้ …

 

 

แนวคิดการ Backup ทั้งบน Cloud และที่บ้าน

จากที่ผมเขียน แนวทางการ Backup ข้อมูล และ มาทำ Backup ไฟล์สำคัญจากมือถือและโน๊ตบุ๊ก ไปไว้บน Cloud กันดีกว่า!!! (Online Sync) จนผมมักพูดว่า “Backup พันวัน เอาไว้ใช้วันสำคัญวันเดียว … วันที่ข้อมูลมีปัญหา!!!” ซึ่งมีใจโดยสรุปดังนี้

  1. เพื่อป้องกันทั้งการ “ลบ” หรือ “ทำข้อมูลสูญหาย” ทั้งที่ตั้งใจและไม่ตั้งใจ
  2. “กู้ข้อมูลเก่า” เนื่องจากแก้ไขข้อมูลปัจจุบันแล้วมีปัญหา หรือไฟล์ที่มีใช้งานไม่ได้ จึงต้องการกลับไปใช้ต้นฉบับก่อนหน้านี้
  3. ป้องกัน “สื่อเก็บข้อมูลเสียหาย” อันนี้สำคัญเก็บดีแค่ไหน ไอ้ตัวที่เก็บข้อมูลดันเสียเองก็จบกัน
  4. “โดนขโมย” อันนี้ปัจจัยควบคุมได้ยากสุดแต่เกิดขึ้นได้น้อยแต่ก็ต้องระวัง

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

รูปแบบการ Backup นั้นมีหลายแบบ ตั้งแต่ระดับคนทั่วไปใช้ จนระดับบริษัทขนาดใหญ่โตนับพันล้านใช้ แต่เอาเหอะ เอาระบบบ้านๆ คนทั่วไปใช้งานดีกว่า ซึ่งผมขอแบ่งง่ายๆ 4 แบบ ที่คุ้นเคยกัน

  1. Unstructured หรือ Full (พวก Data Sync ก็แนวๆ นี้เหมือนกัน) – เป็นแบบง่ายๆ ตรงไปตรงมาครับ อย่างที่ผมบอกไปตั้งแต่ต้น copy ไว้หลายๆ ชุด แต่ต้องระวังว่าไฟล์ไหนเป็นไฟล์ล่าสุด ต้องจัดระเบียบไม่ดี เดี่ยวไป merge/replace ทับไฟล์ล่าสุดจะงานเข้าซะ ปรกติคนทั่วไปที่ไม่มีความรู้ทางเทคนิคมาก จะชอบใช้กัน เพราะที่ง่ายสุด และไม่ต้องใช้ซอฟต์แวร์พิเศษใดๆ ให้ยุ่งยาก แค่รู้วิธีการ copy-paste เป็นก็ทำงานได้แล้ว
  2. Full and Incrementals – คล้ายๆ ข้อแรก แต่มีซอฟต์แวร์มาช่วยจัดการให้ โดยจะมีการทำ copy ข้อมูลไว้เป็นไฟล์ๆ (ตามรูปแบบของแต่ละซอฟต์แวร์จัดการ อาจจะเป็นไฟล์เดียวใหญ่ๆ หรือแบ่งเป็นหลายๆ ไฟล์ก็ได้) แล้วเมื่อมีการสำรองข้อมูลครั้งต่อไปก็จะตรวจสอบเฉพาะไฟล์ที่มีการเปลี่ยนแปลง หรือถูกลบออกไปจากการ Backup ครั้งที่แล้ว แล้วทำการ mark/update เพื่อ Backup ไว้เป็นวัน และเวลานั้นๆ ต่อไปเรื่อยๆ เป็นลูกโซ่ ซึ่งช่วยประหยัดพื้นที่ในการจัดเก็บได้มาก ถ้ามีการ Backup ทุกวัน ไฟล์ที่ได้จากการ Backup แบบนี้มันเพิ่มขึ้นมาเรื่อยๆ เวลาจัดเก็บไฟล์พวกนี้ต้องอยู่ครบทุกไฟล์ ต้องระวังให้ครั้งทำ Full-Incrementals ซ้ำไปซ้ำมาเป็นชุดๆ เพราะการเชื่อมไฟล์ Backup แบบนี้ ยิ่งเยอะจะยิ่งช้า และอ่านนานมาก ปรกติโดยส่วนตัวจะพยายามไม่ให้เกิน 14 ไฟล์ หรือขนาดไม่ใหญ่เกินไป (สัก 100GB – 150GB กำลังพอไหว) เพราะป้องกันไฟล์บางไฟล์เสียหาย หรือซอฟต์แวร์เปิดไฟล์ทั้งหมดไม่ได้ เพราะมีขนาดใหญ่เกินไป
  3. Full and Differential – อันนี้คล้ายกับตัวที่สอง ต่างกันเล็กน้อยตรงที่ เมื่อมีการสำรองข้อมูลครั้งต่อไปก็จะตรวจสอบเฉพาะไฟล์ที่มีการเปลี่ยนแปลง หรือถูกลบออกไปล่าสุดจากการ Backup ตัว Full แล้วทำการ mark/update เพื่อ Backup ไว้เป็นวัน และเวลานั้นๆ ไปเรื่อยๆ เวลากู้คืนกลับมาใช้ไฟล์ Full และตัวไฟล์ที่ Backup ตัวล่าสุด หรือวันที่ต้องการ แค่ 2 ส่วนก็กู้คืนได้แล้ว ซึ่งข้อดีคือ เร็วทั้งการอ่าน และเขียนไฟล์ รวมไปถึงลดความเสี่ยงต่อการสูญหายของไฟล์แต่ละส่วนก็น้อยกว่า แต่มีข้อเสียที่ เสียพื้นที่เยอะกว่าแบบข้อที่ 2 มาก
  4. Versioning with File System – อันนี้เป็นแบบที่ไม่ค่อยมีใครใช้กันสักเท่าไหร่ เพราะมันถูกจัดการด้วยตัว OS เองเป็นหลักเลย โดยผมขอยกตัวอย่างใน Windows 8 ชือ File History และใน Windows 7 ชื่อ Previous Versions โดยหลักการง่ายๆ คือระบบจะทำการสำรองข้อมูลของเราเป็น restore point หรือ snapshot  เมื่อเรา save ข้อมูลไว้อีกชุดนึงไว้ เวลาจะเรียกกลับมาก็แค่คลิ้กขวา restore กลับไปตามวันและเวลาที่มัน Backup ไว้ล่าสุด วิธีนี้ง่ายๆ แต่ผมนานๆ ใช้ที ดูแล้วมันทำงานบ้างไม่ทำงานบ้าง ยัง งงๆ อยู่ว่าทำไม อาจจะเพราะตั้งค่ามันเก็บข้อมูลให้ใช้พื้นที่น้อยไปหน่อยเลยมีค่าเฉลี่ยของ ครั้งที่สำรองข้อมูลของไฟล์บางชนิดน้อยลงไปเรื่อยๆ ส่วนใหญ่ผมจะใช้ตอนรีบเร่งจริงๆ เท่านั้น ออกแนวมีไว้อุ่นใจเป็นหลัก

จากข้อมูลสรุปๆ ผมก็เขียนเรื่องแนวๆ นี้ซึ่งก็มี แนวทางการ Backup ข้อมูล (ฉบับปรับใหม่) และ วิธีเก็บไฟล์รูปภาพให้อยู่กับเรานานๆ อีกด้วย

แน่นอนว่าในยุคที่เรามีการใช้ Cloud Storage กันอย่างกว้างขวาง ส่วนตัวแล้วไม่ได้ใช้ Cloud Storage  แค่ช่วยในการ Backup ข้อมูลเท่านั้น แต่ผมยังใช้ในการทำงานระหว่างเครื่องคอมพิวเตอร์ และมือถือที่ทุกๆ เครื่องสามารถเข้าถึงไฟล์ใน Cloud Storage ได้เหมือนๆ กันทุกเครื่อง ทำให้ไม่ต้องพก Flash Drive หรือ External Hard drive ไปๆ มาๆ ลดโอกาสสูญหาย และหลงลืมได้ ขอให้มี internet เพื่อเข้าถึง Cloud Storage ที่ใช้อยู่ได้ก็เพียงพอ

โดยปรกติตอนนี้ผมใช้ Cloud Storage อยู่หลักๆ 3 ตัวคือ SkyDrive เป็นตัวหลัก SkyDrive Pro เป็นที่เก็บไฟล์สำคัญบางอย่าง และ Dropbox เป็นส่วนสำหรับแชร์ทำงานกับลูกค้า โดยไม่ว่าจะมือถือหรือคอมพิวเตอร์ทุกเครื่องจะสามารถเข้าถึง Cloud Storage ทั้ง 3 ตัวนี้ได้ทั้งหมด แน่นอนว่าจะมีส่วนหนึ่งที่ใช้ Cloud Storage แบบเฉพาะ ที่ไว้จัดเก็บ Source code ซึ่งผมจะใช้ BitBucket.org ในการเป็น source code revision control (Git) ในการช่วยแบ่งเบาภาระของ SkyDrive, SkyDrive Pro และ Dropbox ไปอีกชั้นหนึ่ง

แน่นอนว่ามี Cloud Storage ในการจัดเก็บ แชร์ไฟล์งานระหว่างเครื่อง และกลุ่มการทำงานแล้ว ก็ต้องมีการ Backup ส่วนนี้ไว้เองที่บ้านด้วย (ต่อไปจะใช้คำว่า Local backup) ด้วยเช่นกัน เพราะต้องนึกถึงความเสี่ยงที่ระบบ Cloud Storage จะล่ม ซึ่งผมได้แบ่งกลุ่มไว้กว้างๆ อยู่ 3 กลุ่มคือ

1. กลุ่มสำคัญสูงสุด จะใช้  Cloud Storage และทำ Local backup ไปพร้อมๆ กัน โดยแยกไว้ 2 พวกย่อย คือ
– ไฟล์งานเอกสารที่หายไม่ได้ จะ backup ไว้ 2 ส่วน คือ ไว้บน Cloud Storage (SkyDrive/Dropbox ) และ HDD External ที่ตั้ง daily backup ทุกวัน (เปิดเครื่องทิ้งไว้ตอนกลางคืน ให้ Acronis True Image ทำการ Full and Incrementals backup)
– ไฟล์ source code และต้องทำ source code revision control จะ Backup ไว้ 2 ส่วน คือ ไว้บน BitBucket.org และ HDD External ที่ตั้ง daily backup ทุกวัน (เปิดเครื่องทิ้งไว้ตอนกลางคืน ให้ Acronis True Image ทำการ Full and Incrementals backup)

2. กลุ่มสำคัญมาก จะทำ Local backup เท่านั้น ได้แก่พวกไฟล์รูปภาพ หรือไฟล์ความทรงจำต่างๆ มักจะให้ความสำคัญสูงมาก หายไม่ได้ มีขนาดใหญ่ที่ไว้บน Cloud Storage ลำบาก ต้องมี 2 สำเนาเสมอบน HDD External โดยใช้ลักษณะการ Full data sync ต่าง HDD External ทุกครั้งที่มีข้อมูลใหม่ (ทำ Full data sync ผ่าน SyncToy)

3. กลุ่มสำคัญ จะทำ Local backup เท่านั้น ได้แก่พวกพวกไฟล์วิดีโอ (จำพวก เอ็มวีหายาก ไฟล์หนังหายากที่ rip จากแผ่นที่เก็บไว้ ป้องกันแผ่นเสีย), ไฟล์อีบุ๊ค, ซอฟต์แวร์ที่คัดลอกไว้เพื่อไว้สำหรับติดตั้งในอนาคต มีขนาดใหญ่ที่ไว้บน Cloud Storage ลำบาก ซึ่งส่วนใหญ่จะมี 2 สำเนาบน HDD External เสมอ และ Full data sync ต่าง HDD External เดือนละครั้ง (ทำ Full data sync ผ่าน SyncToy)

จากทั้งหมดที่กล่าวมา จะเห็นว่าผมพยายามปรับปรุงการ backup ให้รัดกุมที่สุด และถ้าได้ติดตามในตอนก่อนๆ จะเห็นว่ามีการปรับปรุงให้เรียบง่ายมากขึ้น ไม่ซับซ้อนเหมือนตอนก่อนๆ แน่นอนว่า หลายๆ คนคงให้เหตุผลว่าทำไมไม่ใช้ RAID ร่วมด้วย คือต้องอธิบายก่อนว่า RAID นั้นช่วยเรื่อง uptime เป็นหลัก ซึ่งเหมาะกับ Server และการให้บริการอย่างต่อเนื่อง การนำมาใช้ในการสำรองข้อมูลที่เน้นคงทน และสามารถกู้ข้อมูลกลับมาในวันก่อนๆ ได้นั้นยังคงเป็นจุดอ่อน รวมไปถึงมีจุดอ่อนในส่วนของ RAID Controller มีปัญหา หรือ File System เสียหายจนใช้งานไม่ได้ด้วย ซึ่ง RAID นั้นไม่ช่วยอะไรในกรณีนี้ ฉะนั้นการสำรองข้อมูลต่าง HDD แบบแยกออกเป็นอุปกรณ์ และทำ Full data sync จะดีกว่าสำหรับไฟล์แนวๆ ตัวอย่างที่ผมใช้ประจำคือ Server ที่ผมดูแลนั้นมีการใช้ RAID และยัง backup ข้อมูลต่างชุด HDD รวมไปถึงงานที่ซีเรียสมากๆ ผมจะ backup ต่างเครื่อง ด้วยซ้ำไป

สรุปผลจากทั้งหมดที่กล่าวมานี้ ช่วยชีวิตผมมาหลายต่อหลายครั้งแล้ว แม้ใช้งบเยอะหน่อย แต่ไฟล์งานสำคัญปลอดภัยผมถือว่าคุ้มค่าครับ