Isi semula akaun Google Cloud: GCP Cloud SQL master-sc sync interrupt dan Read Replica panduan penyelesaian kelewatan ultra tinggi
Pada pukul 3 tengah malam minggu lalu, nada dering penggera PagerDuty memecah keheningan: Read Replica dari perniagaan teras dalam talian ditangguhkan hingga 3,600 saat (1 jam), dan nod baca sahaja sering melaporkan kesalahan, dan master-sms akan terputus sepenuhnya.
Bagi pasukan yang bergantung pada Google Cloud Cloud SQL (sama ada MySQL atau PostgreSQL) untuk membina seni bina pemisahan membaca dan menulis, Read Replica Kelewatan Lonjakan atau Gangguan Penyegerakan (Replication Lag / Broken) pastinya merupakan salah satu masalah yang paling menyusahkan.
Sebagai SRE yang telah berada di GCP selama bertahun-tahun, saya akan membawa anda untuk memulihkan pemandangan melalui artikel ini dan menyusun satu set
Penyelesaian dan pengoptimuman kelewatan replikasi Cloud SQL yang nyata dan boleh dilaksanakan
。
1. Pemulihan fenomena: Bagaimana kegagalan berlaku?
Secara amnya, lonjakan kelewatan replikasi mempunyai dua manifestasi khas berikut:
Jenis katak rebus air suam: Pada panel pemantauan Cloud SQL Google Cloud Console, penunjuk replica_lag terus meningkat pada sudut 45 darjah.
Jenis longsoran tebing: Perpustakaan utama melakukan kemas kini kumpulan yang sangat lama, dan penyegerakan dari perpustakaan tiba-tiba berhenti, atau WAL/Binlog dari nod baca sahaja tidak dapat mengejar perpustakaan utama, yang secara langsung menyebabkan rantai salinan terganggu.
Untuk menyelesaikan masalah ini, kita perlu mengetahui logik replikasi GCP yang mendasari.
2. Analisis ringkas prinsip teras: mekanisme penyegerakan Cloud SQL
Cloud SQL untuk MySQL: Replikasi peringkat baris berdasarkan GTID (Row-Based Replication). Perpustakaan utama menulis rekod ke Binlog, IO Thread dari perpustakaan bertanggungjawab untuk menarik Binlog, dan SQL Thread (atau Pekerja Parallel) bertanggungjawab untuk bermain semula secara tempatan.
Cloud SQL untuk PostgreSQL: Berdasarkan Streaming Replication (replikasi aliran). Perpustakaan utama menulis WAL, yang diterima dari WAL Receiver di perpustakaan dan diproses oleh proses WAL Startup/Replay.
Apabila penulisan dan serentak perpustakaan utama sangat tinggi, atau perpustakaan hamba tidak dapat menerapkan perubahan ini tepat pada waktunya, kelewatan berlaku.
Kaedah penyiasatan tiga langkah empat langkah: cari pelakunya yang menyebabkan kelewatan penyegerakan
Menghadapi kelewatan beberapa ribu saat, jangan mulakan semula perpustakaan secara membuta tuli. Memulakan semula nod baca sahaja akan menyebabkan kehilangan Buffer tempatan, dan Replay semula dapat memperburuk kelewatan. Ikuti langkah di bawah untuk menyiasat langkah demi langkah:
1. Periksa masalah sumber: Adakah spesifikasi tuan dan hamba sama?
Ini adalah lubang paling mudah bagi 80% pemula untuk melangkah. Untuk menjimatkan wang, banyak orang suka memadankan perpustakaan utama
16vCPU / 64G, manakala perpustakaan hamba hanya memberikan 2vCPU/8G.
Masalah: Perpustakaan utama dapat dengan mudah memproses penulisan besar-besaran dengan CPU serentak yang tinggi, tetapi perpustakaan hamba tidak dapat memainkan semula Binlog/WAL dengan satu utas (atau multithreading terhad) apabila sumber daya terhad, dan CPU sering memukul secara langsung 100%.
Penyelesaian: Lihat penggunaan CPU dan Disk I/O Utilitation di Cloud Monitoring.
2. Cari urus niaga besar di perpustakaan utama dan "tiada jadual kunci utama"
Transaksi Besar: Seseorang menjalankan DELETE FROM orders WHERE status = 0 di perpustakaan utama dan menghapus 5 juta data. Di MySQL, keseluruhan transaksi ini akan dihantar ke perpustakaan hamba setelah perpustakaan utama diserahkan. Semasa tempoh transaksi besar dimainkan semula dari perpustakaan hamba, semua penyegerakan berikutnya akan disekat.
Tidak ada kunci utama (Jadual Utama Tidak Utama): Dalam mod replikasi Row-Based, jika jadual besar tidak mempunyai kunci utama, pangkalan data utama hanya perlu mengimbas keseluruhan jadual untuk mengemas kini rekod, tetapi setiap baris perubahan harus dilakukan ketika memainkan semula dari perpustakaan Imbasan penuh! Apabila terdapat 10,000 baris kemas kini, 10,000 imbasan meja penuh perlu dilakukan dari perpustakaan, dan kelewatannya terus ke langit.
3. Adakah terdapat konflik kunci pertanyaan yang panjang dari perpustakaan?
Node baca sahaja tidak hanya menyegerakkan data, tetapi juga bertindak balas terhadap permintaan Read perniagaan.
Dalam PostgreSQL, jika anda menjalankan SQL analisis 10 minit dari perpustakaan, dan WAL yang dihantar dari perpustakaan utama hanya mengubah jadual yang dibaca oleh SQL, konflik akan berlaku. Menurut konfigurasi parameter max_standby_streaming_delay PostgreSQL, perpustakaan hamba akan menunggu pertanyaan selesai, sehingga menggantung aplikasi WAL.
Di MySQL, pertanyaan besar dari perpustakaan mungkin memegang kunci meja atau kunci tersirat, menyekat penulisan SQL Thread.
4. Periksa rangkaian dan kelewatan rentas rantau
Sekiranya Read Replica anda dikerahkan di tempat yang berbeza (seperti perpustakaan utama di Tokyo
Asia-northeast1
, Dari perpustakaan di Singapura
Asia-southeast1
), Jitter rangkaian rentas rantau dan kelewatan fizikal akan memanjang secara langsung
Network_lag
。
Keempat, program hemostasis dan penyembuhan radikal yang sangat cepat
Untuk punca-punca yang dikenal pasti di atas, kita dapat menangani dengan cepat dengan cara berikut:
1. Hemostasis kecemasan: peningkatan dinamik dan proses pembunuhan pertanyaan
Peningkatan sementara satu klik ke perpustakaan hamba: Tidak perlu mengubah suai perpustakaan utama, masukkan vCPU Read Replica/secara langsung di GCP Console
Memori ditingkatkan agar selaras dengan perpustakaan utama (bahkan sedikit lebih tinggi daripada perpustakaan utama), yang menyediakan sumber CPU dan I/O yang mencukupi untuk mengikuti perkembangan.
Kill Pertanyaan lambat dari perpustakaan: Sekiranya anda mendapati bahawa perpustakaan mempunyai SQL analisis yang kompleks yang menggunakan sumber daya, bunuh dengan tegas.
Pastikan kestabilan akaun pengeluaran: Semasa melakukan pengembangan kecemasan dan penyesuaian contoh spesifikasi tinggi di awan, adalah perlu untuk memastikan bahawa sumber awan dan pemotongan berada dalam keadaan normal. Oleh kerana proses kelulusan kewangan yang rumit, banyak syarikat sering gagal beroperasi kerana had kad kredit yang tidak mencukupi atau tunggakan akaun ketika mereka menghadapi lalu lintas tiba-tiba dan perlu mengembangkan sumber daya mereka dengan cepat. Untuk mengelakkan rasa malu ini, banyak pasukan operasi dan penyelenggaraan dan kewangan akan memilih untuk mengisi semula akaun Google Cloud melalui penyedia perkhidmatan awan profesional, dan secara fleksibel menambah kuota melalui pembayaran awam, pembayaran pendahuluan atau mengeluarkan invois domestik untuk memastikan tindak balas kegagalan. Konfigurasi dapat dinaikkan pada bila-bila masa pada saat-saat kritikal.
2. Pengoptimuman khas MySQL: buka Salinan Parallel (Parallel Replication)
Cloud SQL MySQL mungkin tidak memaksimumkan prestasi ulangan selari secara lalai. Anda boleh mengaktifkan replikasi selari dengan mengubah suai Flag:
Tetapkan replica_parlel_workers (atau slave_parallel_workers) ke nilai yang konsisten dengan bilangan vCPU dari perpustakaan hamba.
Dengan tetapan replica_paralllel_type = LOGICAL_CLOCK, kecekapan aplikasi pustaka Binlog bertambah baik.
3. Pengoptimuman khas PostgreSQL: menimbang pertanyaan dan penyegerakan
Sekiranya kelewatan PG Read Replica anda sangat tinggi kerana konflik pertanyaan, anda boleh mencuba menyesuaikan parameter berikut dari Pangkalan Data Flags di perpustakaan:
Laraskan (mis. Tetapkan ke 30s), yang bermaksud bahawa apabila konflik penyegerakan berlaku, sistem akan memberi keutamaan untuk membatalkan pertanyaan baca sahaja (melaporkan status membaca dengan pemulihan) untuk memastikan masa nyata penyegerakan.
4. Perubahan lapisan perniagaan: elakkan transaksi tunggal berskala besar
Potong operasi UPDATE atau DELETE yang besar ke dalam kumpulan kecil (Pemprosesan Batch) dan serahkan secara berkumpulan.
Mengatur dengan ketat spesifikasi pembinaan jadual pangkalan data: Semua jadual mesti mengandungi kunci utama.
Lima, ringkasan
Penyiasatan Kelewatan Read Replica dari GCP Cloud SQL pada dasarnya adalah
Sumber, serentak dan kunci
Permainan. Apabila menghadapi penggera kelewatan, ikuti"
Periksa spesifikasi-> Sahkan urus niaga besar/kunci utama-> Hilangkan konflik kunci dari pangkalan data-> Laraskan pangkalan data Flag/Peningkatan sementara
"Dalam set pukulan gabungan ini, kebanyakan masalah penyegerakan dapat diselesaikan.
Sangkar
Sifat saintifik pembinaan, sumber operasi dan penyelenggaraan yang banyak, dan spesifikasi pangkalan data yang ketat adalah satu-satunya cara untuk membuat perniagaan tidak perlu risau.