คู่มือแก้ไขปัญหา PostgreSQL ในสภาพแวดล้อม ServBay บน macOS

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

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

ภาพรวม

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

ข้อกำหนดเบื้องต้น

ก่อนดำเนินการแก้ไขปัญหา โปรดตรวจสอบให้แน่ใจว่า:

1. ติดตั้งและเปิดใช้งานแอปพลิเคชัน ServBay เรียบร้อยแล้ว
2. ได้ติดตั้งเวอร์ชัน PostgreSQL ที่จะทำการแก้ไขปัญหาผ่าน ServBay แล้ว
3. มีพื้นฐานการใช้งานคำสั่ง Terminal ของ macOS
4. ทราบเส้นทางไฟล์คอนฟิกและ Directory ข้อมูลของ PostgreSQL ที่ใช้อยู่ (โดยทั่วไปคือ /Applications/ServBay/db/postgresql/<version>)
5. ทราบชื่อฐานข้อมูล ชื่อผู้ใช้ และรหัสผ่านที่ต้องการเชื่อมต่อ

ปัญหาที่พบบ่อยและแนวทางแก้ไข

1. ไม่สามารถเริ่มใช้งานแพ็คเกจ PostgreSQL ได้

หากคุณพยายามเริ่มแพ็คเกจ PostgreSQL ผ่าน ServBay แล้วสถานะยังคงเป็นหยุดหรือรันไม่ขึ้น อาจเกิดได้จากสาเหตุต่อไปนี้

สาเหตุที่เป็นไปได้

• ไฟล์คอนฟิกมีข้อผิดพลาดทางไวยากรณ์หรือเกิดความขัดแย้งในการตั้งค่า
• พอร์ตมาตรฐาน (5432) ถูกใช้โดยโปรแกรมอื่นอยู่แล้ว
• ไม่มีสิทธิสำหรับอ่าน/เขียนโฟลเดอร์ข้อมูลหรือไฟล์คอนฟิก
• Directory ข้อมูลของ PostgreSQL เสียหาย
• มีปัญหาภายในของ ServBay

วิธีแก้ไข

1. ตรวจสอบสถานะและล็อกผ่าน GUI ของ ServBay: เปิดหน้าต่าง ServBay ตรวจสอบสถานะของแพ็คเกจ PostgreSQL หากแสดงความผิดปกติ พยายามสั่งเริ่มจาก GUI อีกครั้ง ตรวจสอบล็อกหลักของ ServBay หรือไฟล์ล็อกเฉพาะของ PostgreSQL (หาก GUI แสดงให้ดู) โดยล็อกของ ServBay มักอยู่ที่ /Applications/ServBay/logs/ ให้ดูไฟล์ postgresql/<version>/postgresql-<version>.log เพื่อค้นหาเหตุผลของการเริ่มไม่สำเร็จ

2. ตรวจสอบไฟล์คอนฟิก: ไฟล์หลัักของ PostgreSQL คือ postgresql.conf กรุณาตรวจสอบให้แน่ใจว่าไม่มีข้อผิดพลาด ได้ระบุค่าที่ถูกต้อง ตัวอย่างใน ServBay สำหรับ PostgreSQL 13 อยู่ที่

   /Applications/ServBay/db/postgresql/13/postgresql.conf

   อีกไฟล์สำคัญคือ pg_hba.conf ใช้ควบคุมการยืนยันตัวตนลูกค้า หากตั้งค่าผิดอาจส่งผลถึงการเชื่อมต่อและบางกรณีอาจส่งผลทางอ้อมต่อการเริ่มระบบ (เช่น ต้องเช็คเชื่อมต่อบางอย่าง) ปกติจะอยู่โฟลเดอร์เดียวกับ postgresql.conf

   PostgreSQL ไม่มีคำสั่งตรงๆ สำหรับ “ตรวจสอบ” ไวยากรณ์ไฟล์คอนฟิก แนะนำให้อ่านข้อมูล error จากไฟล์ล็อก หรือเชื่อมต่อกับฐานข้อมูลที่รันอยู่เพื่อดูค่าต่าง ๆ แต่ทางลัดที่เร็วที่สุดคือหาสาเหตุจากล็อก

   สำหรับ pg_hba.conf สามารถเช็คกฎในระบบหลังเชื่อมต่อแล้ว:

   -- ต้องเชื่อมต่อฐานข้อมูลสำเร็จก่อนจึงจะใช้ได้
   SELECT * FROM pg_hba_file_rules();

   ตรวจสอบ error ขณะโหลดคอนฟิกได้จากตารางนี้เช่นกัน:

   -- ต้องเชื่อมต่อฐานข้อมูลสำเร็จก่อนจึงจะใช้ได้
   SELECT sourcefile, name, sourceline, error FROM pg_file_settings WHERE error IS NOT null;

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

3. ตรวจสอบการใช้พอร์ต: PostgreSQL จะฟังพอร์ต 5432 หากพอร์ตนี้ถูกใช้งานโดยโปรเซสอื่น จะทำให้เริ่มแพ็คเกจไม่ได้ ใช้คำสั่งนี้เพื่อตรวจสอบ:

   lsof -i :5432

   หากมีผลลัพธ์ แสดงว่ามีโปรแกรมใช้พอร์ตนี้อยู่ ให้ตัดสินใจว่าจะปิดโปรแกรมนั้น หรือปรับค่า port ใน postgresql.conf จากนั้น รีโหลดหรือรีสตาร์ท PostgreSQL ผ่าน GUI หรือ servbayctl

4. ตรวจสอบสิทธิ์ไฟล์และโฟลเดอร์: ServBay ต้องมีสิทธิ์อ่าน/เขียนทุกโฟลเดอร์และไฟล์ที่เกี่ยวข้องกับ PostgreSQL โดยทั่วไปจะรันด้วยสิทธิผู้ใช้ปัจจุบัน ให้ตรวจสอบดังนี้:

   ls -ld /Applications/ServBay/db/postgresql/13 # ตรวจสอบสิทธิ์ข้อมูล
   ls -l /Applications/ServBay/db/postgresql/13/postgresql.conf # ตรวจสอบไฟล์คอนฟิก
   ls -l /Applications/ServBay/db/postgresql/13/pg_hba.conf # ตรวจสอบไฟล์ยืนยันตัวตน

   หากพบว่าสิทธิ์ไม่ถูกต้อง ไม่ควรแก้ไขสิทธิเอง ยกเว้นเข้าใจผลกระทบ เพราะ ServBay จะเซ็ตให้ถูกตั้งแต่ติดตั้ง

5. ตรวจสอบและซ่อมแซม Directory ข้อมูล: โฟลเดอร์ข้อมูล PostgreSQL มีข้อมูลทั้งหมด หากเสียหาย จะทำให้ไม่สามารถเริ่มได้ ตรวจสอบจากไฟล์ล็อก หากพบ error เกี่ยวกับข้อมูลเสียหาย การซ่อมแซมอาจซับซ้อนและมีความเสี่ยง แนะนำให้สำรองข้อมูล (แม้อาจเสียหายแล้ว) ก่อนทำอะไรเสมอ PostgreSQL มีเครื่องมือเช่น pg_resetwal แต่ควรใช้อย่างระวังเพราะอาจทำให้ข้อมูลหาย

6. ลองรีสตาร์ทด้วยคำสั่ง ServBay: เมื่อแก้ไขตามข้อบนแล้ว ลองรีสตาร์ท PostgreSQL ด้วยคำสั่งระบุเวอร์ชันที่ถูกต้อง:

   servbayctl restart postgresql 13

   หรือรีสตาร์ทผ่าน GUI

2. เชื่อมต่อกับ PostgreSQL ไม่ได้

แม้ว่า PostgreSQL จะแสดงสถานะว่าใช้งานอยู่ แต่ยังเชื่อมต่อผ่าน psql pgAdmin หรือโค้ดโปรแกรมไม่สำเร็จ

สาเหตุที่เป็นไปได้

• PostgreSQL อาจยังไม่ได้เริ่มทำงานสมบูรณ์ หรือเกิดปัญหาระหว่างใช้งาน
• ตั้งค่า pg_hba.conf ไม่ยอมให้การเชื่อมต่อของคุณ
• มี firewall บล็อกพอร์ตเชื่อมต่อ
• กำหนดพารามิเตอร์การเชื่อมต่อไม่ถูกต้อง (ชื่อโฮสต์ พอร์ต ฐานข้อมูล ผู้ใช้ รหัสผ่าน)
• สิทธิ์ในการเชื่อมต่อไม่เพียงพอ

วิธีแก้ไข

1. ตรวจสอบสถานะผ่าน GUI หรือ servbayctl: เช็ค ServBay GUI ให้ PostgreSQL แสดงสถานะ "รันอยู่" หากไม่ใช่ ให้ย้อนกลับไปดูวิธีแก้ไขปัญหา “เริ่มระบบไม่ได้” ใช้คำสั่งนี้ตรวจสอบสถานะ:

   servbayctl status postgresql 13

   ให้อ่านค่าว่าเริ่มทำงานอยู่จริง

2. ตรวจสอบ pg_hba.conf: ไฟล์นี้ควบคุมสิทธิ์เชื่อมต่อ โฟกัสกับการยอมรับ localhost หรือ 127.0.0.1 สำหรับ local development ตรวจสอบว่ามีกฎยอมรับโฮสต์ ผู้ใช้ ฐานข้อมูล ที่คุณต้องการใช้งานด้วยวิธี auth ที่เหมาะสม (md5 หรือ trust)

   ตัวอย่าง (ยอมให้ servbay-demo เชื่อมต่อ local ผ่าน md5):

   # TYPE  DATABASE        USER            ADDRESS                 METHOD
   host    all             servbay-demo    127.0.0.1/32            md5
   host    all             servbay-demo    ::1/128                 md5

   หลังแก้ไข pg_hba.conf ให้ reload config โดยไม่ต้อง restart PostgreSQL:

   servbayctl reload postgresql 13

   หรือ reload ผ่าน GUI ServBay

3. ตรวจสอบ Firewall: firewall บน macOS หรือ third-party อาจบล็อกพอร์ต 5432 ตรวจสอบให้แน่ใจว่ายอมให้โพรเซส postgres ของ ServBay รับการเชื่อมต่อ ใช้คำสั่งนี้เพิ่มสิทธิ์ให้:

   # เพิ่มแอปเข้า whitelist
   sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/ServBay/bin/postgres
   # ยกเลิกการบล็อกแอป
   sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /Applications/ServBay/bin/postgres

   ต้องกรอกรหัสผ่านผู้ดูแลระบบ

4. เช็คค่าการเชื่อมต่อและสิทธิผู้ใช้: ตรวจสอบ host (localhost/127.0.0.1), port (5432), ฐานข้อมูล, ผู้ใช้, รหัสผ่าน ว่าถูกต้อง ทดสอบด้วย psql:

   psql -U your_username -d your_database -h localhost -p 5432

   แทนที่ your_username และ your_database ตามจริง ถ้าเชื่อมต่อได้จะพบ prompt ของ psql ถ้าไม่ได้ อ่าน error เพื่อแยกปัญหา

   หากเชื่อมต่อได้แต่เข้าใช้ฐานข้อมูลหรือ table ไม่ได้ อาจต้อง grant สิทธิแก่ผู้ใช้นั้น เช็ค role ด้วย:

   -- พิมพ์ใน psql
   \du

   อาจต้องใช้ผู้ใช้ postgres หรือ superuser แก้ไขสิทธิ์

3. ประสิทธิภาพช้า

แม้ PostgreSQL จะรันได้และเชื่อมต่อสำเร็จ แต่พบว่า query ช้าผิดปกติหรือทำงานติดขัด

สาเหตุที่เป็นไปได้

• คำสั่ง SQL ไม่ถูก optimized หรือซับซ้อนเกินไป
• โครงสร้างฐานข้อมูลไม่เหมาะสม
• ตั้งค่าหน่วยความจำ/แคชไม่เหมาะกับงาน
• ไม่มี index ใน column ที่ใช้เงื่อนไขบ่อย
• เครื่องมีทรัพยากรไม่พอ (CPU, RAM, Disk I/O)
• สถิติฐานข้อมูลไม่ถูกอัปเดต

วิธีแก้ไข

1. วิเคราะห์และปรับ query: ใช้ EXPLAIN หรือ EXPLAIN ANALYZE ดูแผนการทำงานของ query เพื่อหาคอขวด

   -- รันใน psql หรือ SQL client
   EXPLAIN ANALYZE SELECT * FROM your_table_name WHERE column_name = 'value';

   จาก output จะช่วยปรับแต่ง query สร้าง index หรือปรับโครงสร้างฐานข้อมูล

2. ปรับ parameter ใน postgresql.conf: มีพารามิเตอร์หลายตัวที่กระทบประสิทธิภาพ โดยเฉพาะ:

   • shared_buffers: หน่วยความจำสำหรับ cache ข้อมูลฐานข้อมูล (ค่าที่ดีแนะนำไม่เกิน 25% ของ RAM)
   • work_mem: หน่วยความจำที่จะถูกใช้ในแต่ละ thread สำหรับ sort/join ต่าง ๆ

   ปรับค่าตามทรัพยากรเครื่อง เช่น

   shared_buffers = 1GB # เช่น หาก RAM 4GB
   work_mem = 64MB # ปรับตามขนาดงาน query

3. สร้าง index ที่เหมาะสม: เพิ่ม index ในคอลัมน์ที่ใช้ใน WHERE/JOIN/ORDER BY บ่อย ๆ จะช่วยให้ query เร็วกว่ามาก

   CREATE INDEX idx_column_name ON your_table_name(column_name);

   หมายเหตุ: อย่าสร้าง index มากเกินไป เพราะจะเพิ่ม overhead ตอน insert/update

4. อัปเดตสถิติ: PostgreSQL ใช้ข้อมูลทางสถิติตัดสินใจแผนการทำงานของ query หากไม่อัปเดตอาจเลือกแผน suboptimal ใช้คำสั่งนี้อัปเดต:

   ANALYZE;
   ANALYZE your_table_name;

   ปกติ ServBay จะเปิด autovacuum อยู่แล้ว แต่ manual analyze มีประโยชน์เวลาวิเคราะห์ปัญหา

5. ตรวจสอบทรัพยากรบนเครื่อง: แม้จะเป็น dev environment แต่ถ้าฐานข้อมูลขนาดใหญ่หรือมี query ซับซ้อน device ก็อาจ bottleneck ได้ ตรวจสอบผ่าน Activity Monitor ว่ามีการใช้ CPU, RAM, Disk หนักหรือไม่

4. การล่มของฐานข้อมูล

PostgreSQL หยุดทำงานทันทีหรือไม่มีการตอบสนองอย่างกะทันหัน

สาเหตุที่เป็นไปได้

• ฮาร์ดแวร์โอเวอร์โหลด (RAM/ Disk เสียหาย)
• OS เกิดปัญหาหรือจำกัดทรัพยากร
• Bug ภายใน PostgreSQL (เจอได้น้อย)
• โฟลเดอร์ข้อมูลเสียหาย
• คอนฟิกผิดจน resource หมด (เช่น ตั้ง max connection เยอะเกินไป)

วิธีแก้ไข

1. ตรวจสอบ error log ของ PostgreSQL: ขณะล่ม PostgreSQL จะบันทึกข้อความ error ไว้ใน log ที่ /Applications/ServBay/logs/postgresql/<version>/postgresql-<version>.log ค้นหาว่าเกิดอะไรขึ้น โดยเฉพาะบรรทัดที่มี FATAL หรือ ERROR ใกล้กับเวลาที่ล่ม

2. ตรวจสอบ log ของระบบ: Log ของ macOS (Console app) อาจมีข้อมูลเกี่ยวกับ hardware หรือ OS ที่เกี่ยวข้อง เช่นการจัดการหน่วยความจำ ฯลฯ

3. ตรวจสุขภาพฮาร์ดแวร์: ใช้เครื่องมือภายใน macOS หรือแอป third-party เช็ค RAM และ Disk ทำงานปกติหรือไม่

4. ซ่อมหรือ rebuild โฟลเดอร์ข้อมูล (ใช้ความระมัดระวัง): ถ้าพบความเสียหาย อาจใช้เครื่องมือ low-level เช่น pg_resetwal (รีเซ็ต WAL) แต่มีความเสี่ยงสูง อาจทำให้ข้อมูลหายแนวทางที่แนะนำ: a. สำรองข้อมูลก่อน (ถึงเป็นโฟลเดอร์ที่เสียหายก็ให้ copy สำรองไว้ก่อน) b. init โฟลเดอร์ข้อมูลใหม่: หยุดแพ็คเกจ PostgreSQL ย้ายโฟลเดอร์ข้อมูลออก ใช้ initdb สร้างโฟลเดอร์ใหม่ (หรือ reinstall PostgreSQL ผ่าน ServBay) c. กู้ข้อมูลจาก backup: ใช้ pg_restore หรือ psql กู้ข้อมูลจากไฟล์ backup ล่าสุด

5. กู้ข้อมูลจาก backup: หากโฟลเดอร์ข้อมูลซ่อมไม่ได้ ให้กู้ข้อมูลผ่าน backup ของ ServBay ที่ปกติจะเก็บไว้ที่ /Applications/ServBay/backup/postgresql/<version>/

5. ปัญหาการสำรอง/กู้คืนข้อมูล

ServBay มีระบบ backup อัตโนมัติและ manual หากพบปัญหาในการสำรองหรือกู้ข้อมูล ดูแนวทางดังนี้

สาเหตุที่เป็นไปได้

• ไฟล์ backup เสียหายหรือไม่สมบูรณ์
• คำสั่ง/พารามิเตอร์ restore ไม่ถูกต้อง
• ไม่มี database หรือ user ที่สิทธิ์พอจะทำ restore
• พื้นที่ดิสก์ไม่พอ
• กระบวนการ backup/restore ถูกขัดจังหวะ

วิธีแก้ไข

1. ตรวจสอบความสมบูรณ์ของ backup: เช็คขนาดไฟล์ backup (pg_dump หรือ ServBay backup) ว่าถูกต้อง ดูว่าไฟล์ .sql มีส่วนหัวและท้ายครบถ้วนหรือไม่ หากใช้แบบ custom/directory format ดู error ตอน pg_restore

   /Applications/ServBay/backup/postgresql/13/your_backup_file.dump

   ใช้ ls -lh เช็คขนาดไฟล์

2. เรียกใช้คำสั่ง restore ให้ถูกต้อง (pg_restore/psql):

   • plaintext (สร้างโดย pg_dump -Fp): ใช้ psql ทำ restore

     psql -U your_username -d your_database -h localhost -p 5432 -f /path/to/your_backup_file.sql

     ฐานข้อมูล your_database ต้องถูกสร้างก่อน
   • custom/directory format (สร้างโดย pg_dump -Fc หรือ -Fd): ใช้ pg_restore

     pg_restore -U your_username -d your_database -h localhost -p 5432 /path/to/your_backup_file.dump

     ตรวจสอบว่า user มีสิทธิ์ใน database

3. สร้าง database เป้าหมายล่วงหน้า: ต้องสร้าง database ก่อนใช้ psql -f หรือ pg_restore

   createdb -U your_username -h localhost -p 5432 your_database

   หรือสร้างผ่าน GUI ServBay

4. เช็คพื้นที่ดิสก์: ตรวจสอบให้แน่ใจว่ามีพื้นที่เพียงพอสำหรับคืนข้อมูล

5. ตรวจสอบตั้งค่า ServBay และ log backup: หากใช้ระบบ backup อัตโนมัติของ ServBay แล้วเกิดปัญหา ตรวจสอบว่า configuration ถูกต้อง และอ่าน log ของ ServBay เพื่อตรวจสอบสาเหตุ

คำถามที่พบบ่อย (FAQ)

• ถาม: จะหาโฟลเดอร์ข้อมูลของ PostgreSQL ใน ServBay ได้อย่างไร? ตอบ: ฐานข้อมูล PostgreSQL จะอยู่ที่ /Applications/ServBay/db/postgresql/<version>/data (เช่น 13) ส่วน postgresql.conf และ pg_hba.conf จะอยู่ที่ /Applications/ServBay/db/postgresql/<version>/

• ถาม: ตั้งค่ารหัสผ่านใหม่ให้ user postgres ทำอย่างไร? ตอบ: หากลืมรหัสผ่าน superuser postgres หรือจะรีเซ็ต user ใด ๆ ให้ทำตามนี้ (ต้องสามารถเชื่อมต่อแบบ trust หรือเป็น superuser อื่นได้)

  1. หยุด PostgreSQL บน ServBay
  2. แก้ไขไฟล์ pg_hba.conf เช่น /Applications/ServBay/db/postgresql/13/pg_hba.conf เปลี่ยนวิธีติดต่อภายในเครื่องเป็น trust ชั่วคราว เช่น:

     # TYPE  DATABASE        USER            ADDRESS                 METHOD
     local   all             all                                     peer  # หรือ md5
     host    all             all             127.0.0.1/32            md5   # หรือ scram-sha-256 ฯลฯ

     เปลี่ยนเป็น:

     # TYPE  DATABASE        USER            ADDRESS                 METHOD
     local   all             all                                     trust
     host    all             all             127.0.0.1/32            trust
     host    all             all             ::1/128                 trust

  3. เริ่ม PostgreSQL ผ่าน ServBay
  4. ใช้ psql เชื่อมต่อเป็น postgres (โดยไม่ต้องใช้รหัสผ่าน)

     psql -U postgres -h localhost -p 5432

  5. ใน psql ใช้คำสั่งนี้รีเซ็ตรหัสผ่าน:

     ALTER USER postgres PASSWORD 'new_secure_password';

     เปลี่ยน 'new_secure_password' เป็นรหัสใหม่ หรือเปลี่ยนชื่อ user หากต้องการ
  6. พิมพ์ \q ออกจาก psql
  7. สำคัญ: หยุด PostgreSQL แล้วเปลี่ยน pg_hba.conf คืนกลับเป็นการรับรองวิธีเดิม (เช่น md5 หรือ scram-sha-256) จากนั้น restart หรือ reload PostgreSQL

• ถาม: ServBay รองรับ High Availability หรือ Replica ของ PostgreSQL หรือไม่? ตอบ: ServBay เน้นใช้งานพัฒนาและทดสอบในเครื่อง ไม่ได้ออกแบบสำหรับ High Availability หรือการบริหารจัดการ Replica ผ่าน GUI แต่สามารถตั้งค่าฟีเจอร์ replication ของ PostgreSQL เองได้ด้วยคำสั่ง เพียงแต่ต้องมีความรู้ขั้นสูง

• ถาม: อัพเกรด PostgreSQL version ใน ServBay อย่างไร? ตอบ: คุณสามารถติดตั้ง PostgreSQL หลายเวอร์ชันใน ServBay ได้ การ upgrade ให้ติดตั้งเวอร์ชันใหม่แล้วใช้ pg_upgrade โอนข้อมูลจาก directory เดิมมายัง directory ใหม่ กระบวนการนี้ต้องหยุดทั้งสองเวอร์ชันในระหว่าง migrate แล้วจึง start ตัวใหม่ รายละเอียดโปรดดูในเอกสารอย่างเป็นทางการ PostgreSQL (เนื่องจาก ServBay จัดเก็บ directory แต่ละเวอร์ชันแยกกันอยู่แล้ว ขั้นตอน migration จึงง่ายกว่าสภาพแวดล้อมอื่น)