CN

Author: niponzz

  • Database Cluster (Galera) ป้องกันข้อมูลแตกคนละชุด

    คำว่า “Galera พัง” หลายคนเข้าใจผิดครับ

    จริง ๆ แล้วต้องแยกเป็น 2 เรื่อง

    1. DNS Service (PowerDNS)
    2. Database Cluster (Galera)

    เคสที่ 1: DNS1 พัง 1 เครื่อง

    จาก 3 Nodes

    DNS1 ❌
DNS2 ✅
DNS3 ✅

    Galera ยังมี 2 เสียงจาก 3 เสียง

    Quorum = ผ่าน

    ผลลัพธ์

    ✅ DNS ตอบได้ปกติ

    ✅ เพิ่ม Zone ได้

    ✅ แก้ Record ได้

    ✅ DNSSEC ทำงานได้

    ผู้ใช้แทบไม่รู้สึกอะไร

    เคสที่ 2: DNS1 และ DNS2 พัง

    เหลือ

    DNS1 ❌
DNS2 ❌
DNS3 ✅

    ตอนนี้เหลือ 1 เสียง

    Galera มองว่า

    “ฉันไม่รู้ว่าอีก 2 เครื่องตายจริง หรือเครือข่ายขาด”

    เพื่อป้องกันข้อมูลเพี้ยน

    Galera จะหยุดรับ Write

    แต่ DNS ใช้งานได้ไหม?

    ขึ้นกับการออกแบบ

    แบบที่เจอบ่อย

    PowerDNS อ่านข้อมูลใน MariaDB

    ข้อมูลเก่ายังอยู่ครบ

    DNS3
 ├─ PowerDNS ✅
 └─ MariaDB ✅

    ผู้ใช้ยัง Query ได้

    www.mbu.ac.th

    mail.mbu.ac.th

    ยังตอบได้ตามปกติ

    ตัวอย่าง

    ลูกค้าทั่วโลก

    dig www.mbu.ac.th @ns3.mbu.ac.th

    ยังได้

    171.5.xxx.xxx

    ปกติ

    แต่ Admin จะเจอปัญหา

    สมมุติคุณต้องการเพิ่ม

    vpn.mbu.ac.th

    หรือ

    test.mbu.ac.th

    แล้วรัน

    INSERT INTO records …

    Galera จะตอบประมาณ

    WSREP has not yet prepared node for application use

    หรือ

    No quorum

    หรือ

    NON-PRIMARY state

    สรุปคือ

    ❌ แก้ไขข้อมูลไม่ได้

    ✅ อ่านข้อมูลเดิมได้

    ยกตัวอย่างในชีวิตจริง

    นึกถึงกลุ่มไลน์กรรมการ 3 คน

    A
B
C

    กฎคือ

    ต้องมีคนมากกว่าครึ่งเห็นด้วยก่อนถึงจะแก้ไขเอกสารได้

    เหลือ A คนเดียว

    A ✅
B ❌
C ❌

    A ไม่รู้ว่า

    • B กับ C ตาย
    • หรือ Internet ขาด

    ถ้า A แก้เอกสารต่อ

    แล้ววันหนึ่ง B กับ C กลับมา

    ข้อมูลจะขัดกันทันที

    ดังนั้น Galera จึงบอกว่า

    “อ่านได้ แต่ห้ามแก้”

    เคสที่อันตรายที่สุด

    Network Split (Split Brain)

    สมมุติ

    DNS1 <-> DNS2

    คุยกันได้

    แต่คุยกับ

    DNS3

    ไม่ได้

    มุมมองของ DNS1/DNS2

    DNS3 หาย

    มุมมองของ DNS3

    DNS1 DNS2 หาย

    Galera จะเลือกฝั่งที่มีเสียงมากกว่า

    DNS1 + DNS2 = 2 เสียง

    ทำงานต่อ

    ✅ Write
✅ Read

    ส่วน

    DNS3 = 1 เสียง

    ถูกบังคับเป็น

    Non-primary

    ✅ Read
❌ Write

    ป้องกันข้อมูลแตกคนละชุด

    ในระบบ DNS จริงของคุณ

    สมมุติ

    ns1.mbu.ac.th
ns2.mbu.ac.th
ns3.mbu.ac.th

    ผูกกับ

    DNS1
DNS2
DNS3

    แล้ว DNS1 กับ DNS2 พัง

    จะเหลือ

    ns3.mbu.ac.th

    ถ้า Registrar มี NS ทั้ง 3 ตัว

    Resolver ทั่วโลกจะลอง

    ns1 > ไม่ตอบ

    ลอง

    ns2 > ไม่ตอบ

    ลอง

    ns3 > ตอบ

    เว็บไซต์ยังเข้าได้, อีเมลยังเข้าได้, DNS ยังทำงานได้

    แต่ช่วงนั้นคุณจะ

    ❌ เพิ่ม Zone ไม่ได้

    ❌ เปลี่ยน IP ไม่ได้

    ❌ แก้ Record ไม่ได้

    จนกว่าอีก Node จะกลับมาอย่างน้อย 1 ตัว

    วิธีแก้ในเหตุฉุกเฉิน

    ถ้าคุณมั่นใจว่า

    DNS1
DNS2

    ตายจริง

    และเหลือ

    DNS3

    เครื่องเดียว

    สามารถสั่ง

    galera_new_cluster

    หรือ bootstrap node ใหม่

    ให้ DNS3 กลายเป็น Primary Cluster ชั่วคราวได้

    หลังจากนั้น

    Write ได้
Read ได้

    แต่ต้องทำด้วยความเข้าใจ เพราะหากอีก 2 เครื่องยังไม่ตายจริง อาจเกิดข้อมูลขัดแย้งได้

    สรุปสั้นที่สุด

    เมื่อ Galera 3 Nodes เหลือ 1 Node

    ความสามารถใช้งานได้
    ตอบ DNS Query✅
    เปิดเว็บไซต์✅
    รับอีเมล✅
    อ่านข้อมูลในฐานข้อมูล✅
    เพิ่ม Zone❌
    แก้ไข Record❌
    ทำ DNSSEC Key Update❌
    เขียนข้อมูลใหม่❌

    ดังนั้นคำว่า “Galera พัง” ในกรณีเหลือ 1 Node ไม่ได้หมายความว่า DNS ล่มทั้งระบบ แต่หมายถึง Cluster สูญเสีย Quorum จึงหยุดการเขียนข้อมูลใหม่เพื่อป้องกันข้อมูลเสียหาย ครับ।

  • DNS แบบ Galera Cluster 3 Nodes

    ถ้าจะอธิบาย Galera Cluster 3 Nodes สำหรับ DNS (PowerDNS + MariaDB Galera) แบบง่ายที่สุด ให้นึกถึงว่า

    DNS Server ปกติ (เครื่องเดียว)

    DNS1
┌─────────────┐
│ PowerDNS    │
│ MariaDB     │
└─────────────┘

    ข้อเสียคือ

    • เครื่องพัง = DNS ดับ
    • HDD เสีย = ข้อมูลหาย
    • อัปเดตระบบ = ต้องหยุดบริการ

    DNS แบบ Galera Cluster 3 Nodes

    มี 3 เครื่อง

    DNS1
DNS2
DNS3

    ทุกเครื่องมี

    • PowerDNS
    • MariaDB

    เหมือนกันทั้งหมด

    ┌────────┐      ┌────────┐      ┌────────┐
│ DNS1   │◄────►│ DNS2   │◄────►│ DNS3   │
│Galera  │      │Galera  │      │Galera  │
└────────┘◄────►└────────┘◄────►└────────┘

    ทุกเครื่องคุยกันตลอดเวลา

    ตัวอย่างข้อมูล

    สมมุติมี Zone

    mbu.ac.th

    กับ Record

    www.mbu.ac.th A 171.5.xxx.xxx

    เมื่อเพิ่มที่ DNS1

    INSERT INTO records …

    Galera จะส่งข้อมูลไป

    DNS1
 ↓
DNS2
 ↓
DNS3

    ทันที

    ผลคือ

    DNS1 มีข้อมูล
DNS2 มีข้อมูล
DNS3 มีข้อมูล

    เหมือนกันทุกเครื่อง

    เปรียบเทียบง่าย ๆ

    นึกถึง Google Docs

    มี 3 คนเปิดไฟล์เดียวกัน

    คน A
คน B
คน C

    คน A พิมพ์

    Hello

    คน B เห็นทันที

    คน C เห็นทันที

    Galera ทำงานคล้ายกัน

    ทำไมต้อง 3 Nodes

    Galera มีแนวคิดเรื่อง

    Quorum

    ต้องมีเสียงข้างมาก

    สำหรับ

    3 เครื่อง

    จำนวนเสียง

    DNS1 = 1
DNS2 = 1
DNS3 = 1

    รวม

    3 เสียง

    ต้องเหลือมากกว่า

    3/2 = 1.5

    คืออย่างน้อย

    2 เสียง

    กรณี DNS1 พัง

    เหลือ

    DNS2
DNS3

    มี 2 เสียง

    Cluster ยังทำงานได้

    ✅ เขียนข้อมูลได้
✅ อ่านข้อมูลได้

    กรณี DNS1 และ DNS2 พัง

    เหลือ

    DNS3

    มี 1 เสียง

    ไม่ถึง Quorum

    Galera จะหยุดเขียนข้อมูล

    ❌ ไม่รับ Write
✅ อ่านได้

    เพื่อป้องกันข้อมูลแตกเป็นหลายชุด (Split Brain)

    ในงาน DNS จริง

    มักจะเป็นแบบนี้

              Internet
               │
 ┌─────────────┼─────────────┐
 │             │             │
 ▼             ▼             ▼

ns1         ns2         ns3
DNS1        DNS2        DNS3

PowerDNS    PowerDNS    PowerDNS
Galera      Galera      Galera

    ตัวอย่าง

    ns1.mbu.ac.th

    ns2.mbu.ac.th

    ns3.mbu.ac.th

    Registrar จะประกาศ NS ทั้ง 3 ตัว

    NS ns1.mbu.ac.th
NS ns2.mbu.ac.th
NS ns3.mbu.ac.th

    เวลาเพิ่ม Zone ใหม่

    เช่น

    test.mbu.ac.th

    คุณสั่งเพิ่มแค่เครื่องเดียว

    pdnsutil create-zone test.mbu.ac.th

    ข้อมูลจะถูกบันทึกลง MariaDB

    Galera จะ Sync

    DNS1 → DNS2
DNS1 → DNS3

    ทันที

    PowerDNS ทุกตัวจึงเห็น Zone ใหม่พร้อมกัน

    เชื่อมโยงกับ DNSSEC

    ตอนนี้ที่คุณทำอยู่

    Root
 ↓
th
 ↓
ac.th
 ↓
mbu.ac.th

    เป็น Chain of Trust

    ส่วน Galera Cluster ทำหน้าที่

    เก็บข้อมูล DNSSEC

    เช่น

    • DNSKEY
    • DS
    • RRSIG
    • NSEC

    ไว้เหมือนกันทั้ง 3 เครื่อง

    ดังนั้นเมื่อมี Key Rollver

    pdnsutil add-zone-key mbu.ac.th

    หรือ

    pdnsutil rectify-zone mbu.ac.th

    ข้อมูล DNSSEC ที่ถูกสร้างขึ้น จะถูก Sync ไปทุก Node อัตโนมัติ

    DNS1
DNS2
DNS3

    ไม่ต้องสร้างซ้ำทีละเครื่อง

    สรุปสั้น ๆ

    • DNSSEC = ทำให้ข้อมูล DNS เชื่อถือได้ ไม่ถูกปลอมแปลง
    • Galera Cluster = ทำให้ฐานข้อมูล DNS มีหลายสำเนาและ Sync กันตลอดเวลา
    • 3 Nodes = รองรับเครื่องเสียได้ 1 เครื่องโดยยังทำงานต่อได้
    • เพิ่ม/แก้ไข Zone ที่ Node ใด Node หนึ่ง ข้อมูลจะกระจายไปทุก Node
    • ใช้งานร่วมกับ PowerDNS ได้ดีมาก เพราะ PowerDNS ทุกเครื่องอ่านข้อมูลจาก MariaDB Galera ชุดเดียวกัน

    เปรียบเทียบง่าย ๆ:

    DNSSEC = ลายเซ็นรับรองเอกสาร

Galera = เครื่องถ่ายเอกสาร 3 เครื่อง
         ที่มีเอกสารเหมือนกันตลอดเวลา

    สองอย่างนี้ทำคนละหน้าที่ แต่เมื่อใช้ร่วมกันจะได้ทั้ง ความถูกต้องของข้อมูล (DNSSEC) และ ความทนทานต่อความเสียหายของระบบ (High Availability) ครับ।

  • Chain of Trust ของ DNSSEC หรือ “สายโซ่ความน่าเชื่อถือ”

    ภาพนี้คือ Chain of Trust ของ DNSSEC หรือ “สายโซ่ความน่าเชื่อถือ” ตั้งแต่ Root Zone ลงมาจนถึงโดเมน mbu.ac.th

    จากภาพสามารถแบ่งออกเป็น 4 ชั้น:

    . (Root)
   ↓
th
   ↓
ac.th
   ↓
mbu.ac.th

    1. Root Zone ( . )

    กรอบบนสุดคือ Root DNS ของโลก

    จะเห็น DNSKEY อยู่ 3 ตัว

    • DNSKEY id=38696 (วงรีสองชั้น)
    • DNSKEY id=8763
    • DNSKEY id=20326

    วงรีสองชั้นหมายถึง

    ✅ KSK (Key Signing Key)

    ส่วนวงรีชั้นเดียวคือ

    ✅ ZSK (Zone Signing Key)

    หน้าที่คือ

    • KSK ใช้เซ็น ZSK
    • ZSK ใช้เซ็นข้อมูลใน Zone

    แนวคิดง่าย ๆ

    KSK = ผู้จัดการ
ZSK = พนักงาน

    ผู้จัดการเซ็นรับรองว่าพนักงานคนนี้เป็นของจริง

    2. Root เซ็นรับรอง th

    ใต้ Root จะมี

    DS digest alg=2

    DS Record คือ

    ใบรับรองว่าโดเมนลูกใช้กุญแจอะไร

    Root จะเก็บ DS ของ .th

    ภาพแสดงลูกศรจาก Root ลงไปยัง th

    หมายความว่า

    Root รับรองว่า .th ของจริง

    3. th เซ็นรับรอง ac.th

    กรอบกลาง

    th

    มี

    DNSKEY id=19117
DNSKEY id=5040

    เหมือนกัน

    • KSK
    • ZSK

    จากนั้นสร้าง DS

    DS digest alg=2

    แล้วส่งไปไว้ที่ Parent

    คือ

    Root

    เพื่อให้ Root รับรอง

    หลังจากนั้น

    th

    จะเก็บ DS ของ

    ac.th

    แทน

    จึงเห็นลูกศรลงต่อไป

    th
 ↓
ac.th

    4. ac.th เซ็นรับรอง mbu.ac.th

    ในกรอบ

    ac.th

    มี

    DNSKEY id=12799
DNSKEY id=22794

    แล้วสร้าง

    DS record

    เพื่อรับรอง

    mbu.ac.th

    5. mbu.ac.th

    ส่วนล่างสุด

    mbu.ac.th

    มี DNSKEY

    id=21417
alg=13
512 bits

    และใช้เซ็นข้อมูล

    • NS
    • MX
    • A
    • SOA
    • TXT

    ที่เห็นเป็นกล่องด้านล่าง

    เช่น

    mbu.ac.th/A
mbu.ac.th/MX
mbu.ac.th/NS

    แปลว่า Record เหล่านี้ถูก Digital Signature ป้องกันการปลอมแปลง

    ตัวอย่างง่าย ๆ

    สมมุติ

    www.mbu.ac.th
→ 203.0.113.10

    ผู้ใช้เปิดเว็บไซต์

    Browser → Resolver

    Resolver จะตรวจสอบดังนี้

    ขั้นที่ 1

    ถาม Root

    ac.th อยู่ไหน

    Root ตอบกลับพร้อม DS

    ฉันรับรอง .th แล้ว

    ขั้นที่ 2

    ถาม th

    mbu.ac.th อยู่ไหน

    th ตอบ

    ฉันรับรอง ac.th แล้ว

    ขั้นที่ 3

    ถาม ac.th

    mbu.ac.th อยู่ไหน

    ac.th ตอบ

    ฉันรับรอง mbu.ac.th แล้ว

    ขั้นที่ 4

    ถาม mbu.ac.th

    www.mbu.ac.th = 203.0.113.10

    พร้อมลายเซ็นดิจิทัล

    Resolver ตรวจสอบลายเซ็น

    ✅ ตรงกับ DNSKEY

    ✅ DNSKEY ตรงกับ DS

    ✅ DS ตรงกับ Parent

    ✅ Parent ตรงกับ Root

    จึงเชื่อได้ว่า

    203.0.113.10

    เป็นข้อมูลจริง ไม่ใช่ DNS Spoofing

    เปรียบเทียบกับชีวิตจริง

    นึกภาพว่า

    รัฐบาล
  ↓
กระทรวงศึกษา
  ↓
มหาวิทยาลัย
  ↓
คณะ

    ถ้ามีเอกสารจากคณะ

    เราจะตรวจย้อนกลับ

    คณะ
→ มหาวิทยาลัยรับรอง

มหาวิทยาลัย
→ กระทรวงรับรอง

กระทรวง
→ รัฐบาลรับรอง

    ถ้าทุกชั้นตรวจสอบผ่าน

    เอกสารนั้นเชื่อถือได้

    DNSSEC ก็ทำงานแบบเดียวกัน

    Root
→ th
→ ac.th
→ mbu.ac.th

    นี่คือสิ่งที่ภาพกำลังแสดงอยู่ทั้งหมด โดยโซ่ความน่าเชื่อถือ (Chain of Trust) ของ DNSSEC ของโดเมน mbu.ac.th เชื่อมต่อสมบูรณ์จาก Root ลงมาถึงโดเมนปลายทาง แสดงว่า DNSSEC ถูกตั้งค่าและตรวจสอบได้ถูกต้องตลอดสายโซ่ครับ।

  • สรุปค่าใช้จ่ายในการทำรถยนต์

    สรุปตารางรายการทั้งหมด (อัปเดตล่าสุด)

    ลำดับรายการราคา (บาท)
    1เปลี่ยนแหนบ (Japan)22,000
    2เปลี่ยน Torsion Bar16,500
    3เปลี่ยนถ่ายของเหลว+เปลี่ยนปั๊มน้ำ+สายพานหน้าเครื่อง13,500
    4เปลี่ยนยาง12,500
    5ติดตั้งเครื่องวัดบูสต์และตัว Monster เกจ12,400
    6อินเตอร์พร้อมติดตั้ง ตรงรุ่น8,500
    7เปลี่ยนเบาะพร้อมติดตั้ง7,000
    8ค่าทำคู่เกียร์ห้า6,500
    9เปลี่ยนโช้คอัพ (KYB)6,000
    10เปลี่ยนล้อแม็ก (เทิร์นของเก่า)6,000
    11ทำพื้น (หักเทิร์นเบาะเก่า)5,000
    12เซ็นทรัลล็อก+ประตูดูด5,000
    13ทำโช้คที่มงคลโช้อัพ ปรับน้ำมัน step หนึ่ง4,000
    14รีแมป3,500
    15กระจกบานทึบ3,000
    16เปลี่ยนลูกหมากคันชัก3,000
    17ค่าตั้งศูนย์ถ่วงล้อสองครั้ง3,000
    18ฟิล์ม2,800
    19ยางกันกระแทกหลัง (vanshop)2,000
    20บันไดข้าง1,790
    21เปลี่ยนกลอนประตูท้าย (ช่างเชียร สนามหลวง 2)1,500
    22ค่าติดตั้งกระจกบานทึบ1,200
    23อุด EGR500
    24ยางกันเปื้อนบันได350
    ยอดรวมสุทธิทั้งหมด150,040

  • สถาปัตยกรรรม Galera mariadb

    สถาปัตยกรรมของ MariaDB Galera Cluster เป็นโซลูชันฐานข้อมูลที่โดดเด่นในเรื่อง ความพร้อมใช้งานสูง (High Availability) และ การจำลองข้อมูลแบบซิงโครนัส (Synchronous Replication) โดยมีคุณสมบัติหลักที่เรียกว่า “Multi-Master Active-Active”

    นี่คือคำอธิบายสถาปัตยกรรมและส่วนประกอบหลัก:

    1. คุณสมบัติหลัก

    • Multi-Master (Active-Active):
      • คุณสามารถ อ่าน (Read) และ เขียน (Write) ข้อมูลไปยัง โหนดใดๆ ก็ได้ ในคลัสเตอร์
      • โหนดทุกตัวทำงานเป็น “Master” ได้พร้อมกัน ซึ่งแตกต่างจากการจำลองข้อมูลแบบดั้งเดิม (Master-Slave) ที่มี Master เพียงตัวเดียว
    • Synchronous Replication (การจำลองข้อมูลแบบซิงโครนัส):
      • เมื่อมีการทำธุรกรรม (Transaction) และผู้ใช้สั่ง COMMIT การเปลี่ยนแปลงข้อมูลจะถูกจำลองและยืนยันในโหนดอื่นๆ ทั้งหมด ก่อนที่จะแจ้งกลับไปยังผู้ใช้ว่าการทำธุรกรรมสำเร็จ
      • ทำให้มั่นใจได้ว่า ข้อมูลจะสอดคล้องกัน ในทุกโหนดเสมอ (ไม่มี Slave Lag) และ ไม่มีการสูญเสียข้อมูล ในกรณีที่โหนดล้มเหลว
    • Parallel Replication (การจำลองแบบขนาน):
      • Galera สามารถจำลองข้อมูลในระดับแถว (Row Level) และประยุกต์ใช้ (Apply) การเปลี่ยนแปลงแบบขนานกันได้ ซึ่งช่วยเพิ่มประสิทธิภาพการเขียนโดยรวมของคลัสเตอร์

    2. ส่วนประกอบสำคัญ

    MariaDB Galera Cluster ถูกสร้างขึ้นโดยการรวม MariaDB Server เข้ากับ Galera Replication Provider

    ส่วนประกอบคำอธิบาย
    MariaDB Serverเป็นเซิร์ฟเวอร์ฐานข้อมูลหลักที่รองรับการเชื่อมต่อของแอปพลิเคชัน โดยจำเป็นต้องกำหนดค่าให้ใช้ Storage Engine ที่รองรับ Transaction (เช่น InnoDB หรือ XtraDB) และตั้งค่า binlog_format=ROW
    wsrep API(Write Set REPlication API) เป็นอินเทอร์เฟซที่ MariaDB ใช้สื่อสารกับ Galera Replication Provider เพื่อส่งข้อมูลการทำธุรกรรม
    Galera Replication Providerเป็นไลบรารี (libgalera_smm.so) ที่ทำหน้าที่จัดการการจำลองข้อมูล การควบคุมสมาชิก และ Quorum เป็นหัวใจสำคัญของคลัสเตอร์
    Write Setคือกลุ่มของการเปลี่ยนแปลงข้อมูลที่เกิดขึ้นใน Transaction หนึ่งๆ ซึ่งจะถูกห่อหุ้มและส่งไปยังโหนดอื่นๆ เพื่อให้โหนดเหล่านั้นประยุกต์ใช้การเปลี่ยนแปลง (Apply)

    3. กลไกการทำงานของ Galera

    A. Certification-Based Replication (การจำลองข้อมูลตามการรับรอง)

    นี่คือวิธีที่ Galera จัดการการเขียน:

    1. การเขียนข้อมูล (Write): ไคลเอนต์เขียนข้อมูลไปยังโหนด A
    2. การเตรียม Write Set: โหนด A รวบรวมการเปลี่ยนแปลงในรูปแบบของ Write Set และส่งไปยังโหนดอื่นๆ ทั้งหมด
    3. การรับรอง (Certification): โหนดอื่นๆ แต่ละตัวจะตรวจสอบ Write Set ว่า ขัดแย้ง (Conflict) กับ Transaction อื่นๆ ที่กำลังดำเนินอยู่หรือไม่ (เช่น มีการพยายามแก้ไขแถวเดียวกันหรือไม่)
      • การตรวจสอบนี้ทำให้เกิด Deadlock ใน Galera ได้
    4. การสั่งงาน (Ordering): โหนดที่รับ Write Set จะให้ Global Transaction ID (GTID) ที่เป็นลำดับเดียวกัน (Global Ordering) เพื่อให้มั่นใจว่าทุกโหนดประยุกต์ใช้การเปลี่ยนแปลงในลำดับเดียวกัน
    5. การยืนยัน (Commit):
      • หาก ไม่มีความขัดแย้ง โหนดทั้งหมดจะยืนยัน (Commit) การเปลี่ยนแปลงนั้น
      • หาก มีความขัดแย้ง (Certification Failed) โหนด A จะต้องยกเลิก (Rollback) Transaction นั้น และแจ้งให้ไคลเอนต์ทราบ

    B. State Snapshot Transfer (SST) และ Incremental State Transfer (IST)

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

    • SST (State Snapshot Transfer):
      • เมื่อโหนดใหม่เข้าร่วมคลัสเตอร์ (หรือโหนดที่ตามหลังมากเกินไป) คลัสเตอร์จะเลือกโหนดหนึ่งเป็น Donor
      • Donor จะ ล็อก (Pause) การเขียน เพื่อสร้างสำเนาข้อมูลที่สมบูรณ์ (Snapshot) และส่งทั้งฐานข้อมูลไปยังโหนดใหม่
      • วิธีการ SST ที่นิยมใช้ เช่น rsync หรือ mariabackup
    • IST (Incremental State Transfer):
      • หากโหนดใดโหนดหนึ่งหลุดออกจากคลัสเตอร์ไปเพียงชั่วครู่ และ Write Set ที่พลาดไปนั้นยังอยู่ในแคชของโหนดอื่น (gcache)
      • โหนดนั้นจะสามารถดึงเฉพาะ ส่วนที่ขาดหายไป กลับคืนมาได้ทันทีโดยไม่ต้องทำการถ่ายโอนข้อมูลทั้งหมด (SST) ซึ่งเร็วกว่ามาก

    C. Quorum และ Membership Control

    • Quorum: คือการกำหนดเสียงข้างมาก (Majority) เพื่อรักษาความเสถียรของคลัสเตอร์ (นี่คือเหตุผลที่แนะนำให้ใช้จำนวนโหนดเป็นเลขคี่)
    • Membership Control: หากโหนดใดโหนดหนึ่งล้มเหลวหรือหยุดการตอบสนอง โหนดที่เหลือจะทำการลงคะแนนเพื่อ นำโหนดที่ล้มเหลวออกจากการเป็นสมาชิก โดยอัตโนมัติ เพื่อให้คลัสเตอร์ยังคงทำงานต่อได้โดยไม่หยุดชะงัก (Automatic Node Removal/Join)

  • Cluster Galera ทำไมต้องเป็นเลขคี่

    Galera Cluster แนะนำให้ใช้จำนวนโหนดเป็นเลขคี่ (เช่น 3, 5, 7) เพื่อให้แน่ใจว่าจะสามารถกำหนด Quorum (เสียงข้างมาก) ได้อย่างชัดเจนและหลีกเลี่ยงสถานการณ์ Split-Brain

    Quorum และเสียงข้างมาก (Majority)

    Galera Cluster ใช้หลักการของ Quorum เพื่อรักษาความสอดคล้องของข้อมูลและความพร้อมใช้งานสูง (High Availability)

    • Quorum หมายถึงจำนวนโหนดขั้นต่ำที่ต้องเชื่อมต่อกันและทำงานได้เพื่อให้คลัสเตอร์ถือว่าทำงานได้อย่างถูกต้อง
    • ใน Galera Cluster การได้ Quorum จะเกิดขึ้นเมื่อ โหนดที่เหลืออยู่มีจำนวนมากกว่า 50% (เสียงข้างมาก) ของจำนวนโหนดทั้งหมดที่ทราบในการเป็นสมาชิกครั้งสุดท้าย (Last known membership)

    เหตุผลที่ต้องเป็นเลขคี่:

    1. ป้องกัน Split-Brain:
      • Split-Brain คือสถานการณ์ที่เกิดความผิดพลาดของเครือข่าย (Network Partition) ทำให้คลัสเตอร์แบ่งออกเป็นสองกลุ่ม กลุ่มละเท่าๆ กัน (เช่น คลัสเตอร์ 4 โหนด แบ่งเป็น 2 กลุ่ม กลุ่มละ 2 โหนด)
      • ถ้าจำนวนโหนดเป็นเลขคู่ เมื่อเกิดการแบ่งกลุ่มแบบเท่ากัน จะไม่มีกลุ่มใดที่มีเสียงข้างมาก (เกิน 50%) ทำให้ทุกโหนดเข้าสู่สถานะไม่ทำงาน (Non-Primary state) เพื่อป้องกันไม่ให้ข้อมูลแยกจากกัน (Diverge)
      • ถ้าจำนวนโหนดเป็นเลขคี่ (เช่น 3 โหนด) เมื่อเกิดการแบ่งกลุ่ม จะมีกลุ่มหนึ่งที่ใหญ่กว่าเสมอ (เช่น 1 โหนด กับ 2 โหนด) กลุ่มที่ใหญ่กว่า (2 โหนด) จะมีเสียงข้างมาก (Quorum) และสามารถดำเนินการต่อไปได้ ทำให้คลัสเตอร์ยังคงทำงานอยู่ได้
    2. ทนทานต่อความล้มเหลว (Fault Tolerance):
      • ในคลัสเตอร์ 3 โหนด ต้องมี 2 โหนดถึงจะมี Quorum ทำให้สามารถทนทานต่อความล้มเหลวของ 1 โหนด
      • ในคลัสเตอร์ 4 โหนด ต้องมี 3 โหนดถึงจะมี Quorum ทำให้สามารถทนทานต่อความล้มเหลวของ 1 โหนด เช่นกัน
      • จะเห็นว่าการเพิ่มจาก 3 เป็น 4 โหนด ไม่ได้เพิ่มความสามารถในการทนทานต่อความล้มเหลว ดังนั้นการใช้จำนวนโหนดเป็นเลขคี่ (3 หรือ 5) จึงมีประสิทธิภาพมากกว่าในแง่ของ High Availability ต่อทรัพยากรที่ใช้

    กรณีพิเศษ: 2 โหนด

    ถ้าต้องการคลัสเตอร์ที่มีโหนดข้อมูล (Data Node) เพียง 2 โหนด สามารถใช้ Galera Arbitrator (garbd) ซึ่งเป็นกระบวนการที่มีน้ำหนักเบา (Lightweight process) ที่ทำหน้าที่เป็น โหนดลงคะแนนเสียง (Voting Member) เท่านั้น โดยไม่เก็บข้อมูลหรือประมวลผลการเชื่อมต่อของไคลเอนต์

    • การเพิ่ม Galera Arbitrator เข้าไป ทำให้จำนวนสมาชิกสำหรับการลงคะแนนเสียงรวมเป็น 3 โหนด (โหนดข้อมูล 2 + Arbitrator 1) ซึ่งเป็นเลขคี่
    • ด้วยวิธีนี้ ถ้าโหนดข้อมูลตัวใดตัวหนึ่งล้มเหลว โหนดข้อมูลที่เหลืออยู่กับ Arbitrator ก็ยังคงมีเสียงข้างมาก (2 ใน 3) ทำให้คลัสเตอร์ยังคงทำงานได้

    ดังนั้น โดยสรุปคือควรทำให้จำนวน สมาชิกสำหรับลงคะแนนเสียง (Voting Members) เป็นเลขคี่เสมอ ไม่ว่าจะเป็นโหนดข้อมูลจริงทั้งหมด หรือใช้ Arbitrator มาช่วยในกรณีที่มีโหนดข้อมูลเป็นเลขคู่

  • ว่ากันในเรื่องของ Chown

    ไม่จำเป็นต้องใช้ www-data:www-data เสมอไปครับ ขึ้นอยู่กับ บริบทของไฟล์หรือโฟลเดอร์ ที่คุณต้องการตั้งสิทธิ์:

    • www-data เป็น user/group ที่ Apache หรือ Nginx ใช้รันเว็บเซิร์ฟเวอร์ใน Ubuntu/Debian โดยปกติ
    • ถ้าคุณต้องการให้เว็บเซิร์ฟเวอร์ อ่านไฟล์เท่านั้น (เช่น HTML, CSS, JS) → ให้สิทธิ์ www-data แค่ read ก็พอ
    • ถ้าคุณต้องการให้เว็บเซิร์ฟเวอร์ เขียนไฟล์ (เช่น อัปโหลดไฟล์, แคช, log) → ต้องให้สิทธิ์ write ด้วย แต่ควรจำกัดเฉพาะโฟลเดอร์ที่จำเป็น เช่น /var/www/html/uploads

    ✅ แนวทางที่ปลอดภัย

    1. เจ้าของไฟล์เป็น user ของคุณเอง (เช่น thera:thera)
    2. ให้ group เป็น www-data เพื่อให้เว็บเซิร์ฟเวอร์เข้าถึงได้ 
    sudo chown -R thera:www-data /var/www/html
    1. ตั้ง permission ให้เหมาะสม
      • ไฟล์: 640 (owner read/write, group read)
      • โฟลเดอร์: 750 (owner rwx, group rx) 
    find /var/www/html -type d -exec chmod 750 {} \; 
find /var/www/html -type f -exec chmod 640 {} \;
    1. ถ้าต้องการให้เว็บเซิร์ฟเวอร์เขียนไฟล์ (เช่น uploads) → ให้สิทธิ์เฉพาะโฟลเดอร์นั้น 
    sudo chown -R www-data:www-data /var/www/html/uploads chmod 770 /var/www/html/uploads

    สรุป: ไม่ควรทำทั้งเว็บเป็น www-data:www-data เพราะเสี่ยงมาก ถ้าเว็บโดนเจาะ attacker จะเขียนไฟล์ได้ทุกที่

  • ขั้นตอนทำให้ docker ใช้งานได้โดยไม่ต้อง sudo

    1. สร้าง group docker (ถ้ายังไม่มี)
    sudo groupadd docker

    2. เพิ่ม user ปัจจุบันเข้า group docker

    sudo usermod -aG docker $USER

    3ออกจากระบบ (logout) แล้วเข้าใหม่
    เพื่อให้ group ใหม่ทำงาน (หรือใช้คำสั่งด้านล่างแทนการ logout)

    newgrp docker

    4. ทดสอบใช้งาน docker โดยไม่ต้อง sudo

    docker ps
docker run hello-world

    ทำไมต้องทำแบบนี้?

    • โดยปกติ docker ต้องรันด้วยสิทธิ์ root → เลยต้องใช้ sudo
    • การเพิ่ม user เข้ากลุ่ม docker จะให้สิทธิ์เหมือน root เฉพาะการใช้ docker เท่านั้น
    • ทำให้ใช้งานสะดวกขึ้น แต่ก็ต้องระวังเรื่องความปลอดภัย เพราะ user ที่อยู่ในกลุ่ม docker มีสิทธิ์ควบคุม system ได้พอสมควร

  • Ubuntu Server (หรือ Linux ทั่วไป) ว่ากันด้วยเรื่องของการตั้งค่า สิทธิ์ (permission)

    โฟลเดอร์ (Directory) → 755
    ไฟล์ (File) → 644

    find /path/to/your/folder -type d -exec chmod 755 {} \;
find /path/to/your/folder -type f -exec chmod 644 {} \;

    คำอธิบาย

    1. find /path/to/your/folder → ค้นหาภายในโฟลเดอร์ที่ต้องการ (แทน /path/to/your/folder ด้วย path จริง เช่น /var/www/html)
    2. -type d → หมายถึงเลือกเฉพาะ Directory (โฟลเดอร์)
      • จากนั้น -exec chmod 755 {} \; → สั่งเปลี่ยนสิทธิ์ของทุกโฟลเดอร์เป็น 755
    3. -type f → หมายถึงเลือกเฉพาะ File (ไฟล์)
      • จากนั้น -exec chmod 644 {} \; → สั่งเปลี่ยนสิทธิ์ของทุกไฟล์เป็น 644

    📊 ความหมายของสิทธิ์

    • 755 → เจ้าของ (owner) อ่าน/เขียน/รัน ได้, กลุ่มและคนอื่น อ่าน/รัน ได้
      → เหมาะกับ โฟลเดอร์ (เพราะโฟลเดอร์ต้องมีสิทธิ์ execute x ถึงจะเปิดเข้าไปได้)
    • 644 → เจ้าของ อ่าน/เขียน ได้, กลุ่มและคนอื่น อ่านได้อย่างเดียว
      → เหมาะกับ ไฟล์ (ปกติไม่ต้อง execute ยกเว้นไฟล์ script หรือ binary)

    👉 ถ้าอยากรันทีเดียวจบแบบต่อเนื่อง ก็ใช้:

    find /path/to/your/folder -type d -exec chmod 755 {} \; -o -type f -exec chmod 644 {} \;

  • โครงการ GWP ของ สกมช.

    โครงการที่เสริมความปลอดภัยของ Website ราชการที่ป้องกันการโจมตีเรียกว่า WAF

    เป็นโครงการรับมือการโจมตี Website ของภาครัฐ