วันเสาร์, ธันวาคม 03, 2548

Hospital OS V III era has Begun.

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


ตัดสินใจว่าจะใช้ PostgreSQL แบบคอมไพล์จากซอร์สดีกว่า เนื่องจากยังไม่อยากจะอัพดิสโทรไปเป็น Etch ประกอบกับทดสอบแล้วบนเครื่องที่ใช้ทำงาน ว่า Sarge+PostgreSQL 8.0.3 (Compile เอง) มันก็เวอร์คดีไม่มีปัญหา สิ่งที่ไม่ได้คิดว่าจะเป็นปัญหาแม้แต่น้อยก็คือว่า เมื่อจัดการ apt-get remove --purge postgresql บนเครื่องที่ใช้งานจริง + เครื่องที่ใช้ทำดาต้าเบสมิเรอร์ ตามขั้นตอนต่อไปนี้

db :~/tmp/postgresql-8.0.3/#./configure --prefix=/usr/local/pgsql
db :~/tmp/postgresql-8.0.3/#make
db :~/tmp/postgresql-8.0.3/#make install
db :~/tmp/postgresql-8.0.3/#mkdir /usr/local/pgsql/data
db :~/tmp/postgresql-8.0.3/#chown -R postgres.postgres /usr/local/pgsql/data
db :~/tmp/postgresql-8.0.3/#chmod -R 700 /usr/local/pgsql/data
db :~/tmp/postgresql-8.0.3/#su postgres
db :~/tmp/postgresql-8.0.3/$/usr/local/pgsql/bin/initdb -E UNICODE -D /usr/local/pgsql/data
db :~/tmp/postgresql-8.0.3/$exit
db :~/tmp/postgresql-8.0.3/#nano -w contrib/start-scripts/linux
db :~/tmp/postgresql-8.0.3/#cp contrib/start-scripts/linux /etc/init.d/postgresql-8.0
db :~/tmp/postgresql-8.0.3/#chmod 700 /etc/init.d/postgresql-8.0
db :~/tmp/postgresql-8.0.3/#/etc/init.d/postgresql-8.0 start

ต่อไปก็เป็นการสร้างดาต้าเบส ดัมพ์ฐานข้อมูลเดิมกลับเข้าไป อัพเดทด้วย SQL สำหรับใช้กับเวอร์ชั่นสาม ทั้งสองเครื่องใช้เวลาไม่นานมากเท่าไรประมาณชั่วโมงกว่าๆ พร้อมกับทำดาต้าเบสมิเรอร์ด้วยแหละ อะไรจะขนาดนั้น จากที่เริ่มต้นปิดระบบตอนประมาณ 3 ทุ่มๆกว่าเสร็จก็ 4 ทุ่มกว่าๆ ของคืนวันที่ 30 พ.ย 2548 ก็เดินลงมาบอกน้องพยาบาลเวรให้เริ่ม login เข้าทำงานได้ อิ อิ พอเริ่มเปิด visit ผู้ป่วยบันทึกอาการเจ็บป่วยเสร็จ พอจะสั่งยาเท่านั้นแหละ ค้นหารายการออเดอร์ไม่เจอ ตอนนั้นยังไม่ซีเรียสอะไรมาก ลองโทรไปถามเบะซะหน่อย คำตอบที่ได้รับปรากฏว่า postgres ไม่สนับสนุนการใช้งานแบบ multibyte ทำให้ค้นหารายการออเดอร์ไม่เจอ เป็นเหตุการณ์เดียวกันกับที่ ชุมแสง และเป็น Critical มากเลยสำหรับซอพท์แวร์ที่เกี่ยวกับการให้บริการสุขภาพ ถ้าสั่งยาไม่ได้ก็แทบจะไม่มีความหมายอะไร ไม่ได้เป็นแค่เซอร์เวอร์ที่ใช้บริการจริงๆ นะ ตัวที่ทำเป็นมิเรอร์ก็เป็นไปกับเค้าด้วย โอ จอร์ช มันยอดมากเลย มีทางแก้มั๊ย อากาศตอนสี่ทุ่มกว่าๆ ที่ทุ่งหัวช้างก็เย็นมากแล้ว แต่ทำไมผมรู้สึกร้อนๆ เหงื่อเต็มฝ่ามือไปหมด ที่ชุมแสงแก้ปัญหาโดยเปลี่ยนจากเดเบียนไปเป็น Redhat Enterprice ที่เบะติดเอาไปด้วยแล้วคอมไพล์ postgres ใหม่ก็สามารถทำงานได้ปกติ เอ้อแล้วกรู จะไปเอา Redhat Enterprice มาจากไหนฟะ ดึกดื่นขนาดนี้แล้ว อย่าว่าแต่ดึกๆ เลย กลางวันแสกๆ ยังไม่มีปัญญาไปหา Distro อื่นหรอก ก็คบเดเบียนมานานโขแล้วจนไม่คิดที่จะใช้อย่างอื่น ก็มีแต่เดเบียน เอ๊ะแต่ทำไมทองแสนขันถึงใช้เดเบียน+postgresql คอมไพล์ได้ว่ะ เริ่มมีกำลังใจมานิดๆ แต่ตอนนี้มันห้าทุ่มกว่าๆ แล้วจะโทรไปถามก็ดึกมาก ไม่เป็นไรลองคอมไพล์ใหม่เพิ่ม option --enable-multibyte ไปด้วยซะ ก็ตอนแรกๆ ที่ใช้ Postgres ก็ใช้แบบคอมไพล์นี่แหละ แต่ตอนนั้น option เยอะกว่านี้มากจำไม่ได้แล้ว จำได้แค่ว่าใช้ Linux SIS + PostgreSQL 7.1.3 ก็ใช้มาตลอดตั้งแต่เดือน ตุลาคม 2545 (เริ่มใช้ Hospital OS เวอร์ชั่นแรกๆ) จนถึง มกราคม 2548 ก็เปลี่ยนมาใช้เดเบียนซึ่งยังไม่ stable+PostgreSQL ที่มากับ Distro พร้อมๆกับ upgrade มาเรื่อยจน Sarge กลายเป็น Stable และ PostgreSQL หยุดอยู่ที่ 7.4.7 กลับมาที่การคอมไพล์ครั้งที่สองบวก option --enable-multibyte ไปด้วยผลออกมาก็คือยังไม่สามารถใช้งานได้ มาถึงตอนนี้เริ่มเครียดเนื่องจากว่าเข้าสู่วันใหม่แล้ว โชคดีที่เวรดึกไม่มีผู้มารับบริการเลยทำให้ตัดความกังวลไปได้บ้าง คิดว่าจะต้องลงเดเบียนใหม่อีกที ทีนี้ขออัพเกรดไปเป็น Etch เพื่อเลือกใช้ PostgreSQL 8.0.3 ที่มากับ Distro อาจจะตัดปัญหาเรื่อง multibyte ไปได้ (คิดอะไรไม่ออกแล้วตอนนี้ต้องเสี่ยง) เสร็จประมาณตีสามกว่ารวมเวลาที่คอยการ fetch package จากอินเทอร์เน็ตด้วย เน็ตก็ไม่ค่อยเป็นใจเท่าไร โอยกว่าจะก้าวหน้าที่ละ k ใจจะขาดซะให้ได้ ผลที่ออกมาน่ะเรอะ เหอะ เหอะ เหมือนเดิม ตอนนี้เครียดกว่าเดิมอีก เหลือเวลาอีกไม่กี่ชั่วโมงก็จะสว่างแล้ว แล้วยังมีคลินิคเบาหวานด้วย โอ จอร์ช พระเจ้าจะช่วยกรู ได้ไหมฟะเนี่ย ทำงัยดีล่ะ เอางี้แล้วกันถอยกลับไปใช้เวอร์ชั่นสองอีกครั้ง เอาเครื่องที่เป็นมิเรอร์นั่นแหละ ให้บริการไปก่อน ลืมบอกไปว่าหลังจากที่พบว่ามีเออร์เรอร์เรื่อง multibyte ผมก็เอา PostgreSQL 8.0.3 ที่คอมไพล์บนเครื่องมิเรอร์ออก แล้วก็กลับไปใช้ 7.4.7 เหมือนเดิมปรากฏว่าไม่มีเออร์เรอร์เรื่อง multibyte แฮะ อย่างน้อยก็ยังอุ่นใจได้อย่างน้อยก็สักวันหนึ่ง แต่จะหวังให้ใช้งานหนักๆ เร๊อะ คงยากเนื่องจากสเปคของ Hardware เป็นสเปคของ Desktop PC ธรรมดาลำพังการเอามาทำเป็นมิเรอร์เนี่ยก็ค่อนข้างโหลดมากแล้ว มองดูนาฬิกาอีกทีตีสามกว่าเกือบตีสี่แล้ว เอาเป็นลงเดเบียนอีกทีน่ะ คราวนี้เอา Sarge เหมือนเดิมก็แล้วกันแล้วคอมไพล์ PostgreSQL เอา ลองดูอีกทีน่ะยังพอมีเวลา ทีนี้ตอนลงเพิ่ม Repository ของ update เข้าไปด้วยตีห้ากว่าๆ ก็เสร็จ ตอนที่ login เข้าไปเทสต์น่ะ ผมงี้ลุ้นใจจะขาด ในที่สุดสวรรค์ยังเมตตา ไม่ให้ผมต้องรับกรรมไปมากกว่านี้อีก กว่าจะเริ่ม fine tunning , set up crontab อีกสว่างคาตาเลยครับ คำพูดที่ว่าฟ้าเหลืองน่ะ มีจริงผมยืนยันได้ เจอกับตัวเองเข้าถึงรู้ เหอ เหอ


ปัญหาที่เกิดขึ้นผมพอจะเดาเอาเอง ซึ่งอาจจะไม่ใช่สาเหตุจริงๆ ก็ได้

  1. Sarge ที่ติดตั้งบนเครื่อง Database Server ไม่ได้ update เลยอาจทำให้บางแพคเกจมีปัญหาในการใช้งาน PostgreSQL+mutibyte

  2. เครื่องที่ทำเป็น Database Mirror ผมมักจะใช้เป็นเครื่องที่ทดลองการใช้งาน Debian อยู่เสมอและเปิดการอัพเดทด้วยทำให้ไม่มีปัญหากับ multibyte เมื่อใช้กับ Postgres 7.4.7 แม้ว่าจะคอมไพล์ 8.0.3 ไม่ผ่านแต่ก็สามารถ Down ลงมาใช้ของเดิมได้

  3. Etch ไม่มีระบบการ update security เนื่องจากยังอยู่ในการ Testing บางทีอาจจะยังไม่พบปัญหานี้ก็ได้ เป็นปัญหาของเดเบียนหรือว่า Postgres กันแน่ ?


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

ทีนี้ก็เหลือภาระงานอีกอย่างที่ต้องรีบเร่งทำ คือการทำมิเรอร์ ให้กับ Database จากประสบการณ์ที่ผ่านมาทำให้ไม่วางใจในเซอร์เวอร์เพี่ยงเครื่องเดียว คงต้องเหนื่อยอีกรอบ สู้โว๊ย



: )
ผมก็เคย tune up ระบบ
36 ชั่วโมงรวดเหมือนกันครับ

เหนื่อย แต่ถ้าสำเร็จ ก็มันส์ดี  


แสดงความคิดเห็น
Powered for by Blogger Templates free hit counter code
Copyright ? 2008-2009 Uthai Lueadnakrop. All Rights reserved