Ejen awan Amazon: AWS RDS secara automatik membuat sandaran pangkalan data semasa tetingkap, diagnosis turun naik dan penyelidikan pertempuran sebenar
Banyak jurutera operasi dan penyelenggaraan dan DBA telah menghadapi senario yang menyusahkan: setiap hari pada waktu yang tetap pada awal pagi, kumpulan penggera sistem mulai "mengebom tanpa pandang bulu"-kadar penggunaan CPU pangkalan data telah meningkat dengan mendadak, dan jumlah pertanyaan lambat Melambung, sebilangan besar panggilan API sisi aplikasi, dan bahkan kumpulan sambungan pangkalan data penuh.
Melihat panel pemantauan RDS AWS Console, didapati bahawa jangka masa masalah itu bertepatan dengan tetingkap sandaran automatik RDS.
Sandaran automatik pada asalnya adalah fungsi "menyelamatkan nyawa" untuk memastikan keselamatan data dan melaksanakan pemulihan masa (PITR). Mengapa ia menjadi "pembunuh prestasi" sistem perniagaan semasa operasi? Artikel ini akan membawa anda untuk memahami dan menyelesaikan masalah ini secara menyeluruh dari empat dimensi mekanisme fizikal asas AWS RDS, kemacetan seni bina penyimpanan, jalan diagnosis dan penyelesaian, dan rancangan tadbir urus seni bina.
1. Menelusuri sumbernya: Apa yang berlaku di lapisan bawah tetingkap sandaran?
Untuk mendiagnosis masalah ini secara menyeluruh, anda perlu memahami prinsip kerja asas sandaran automatik AWS RDS. Sandaran snapshot RDS bukanlah pangkalan data yang mudah
Mysqldump
Atau eksport logik, tetapi berdasarkan lapisan bawah
Tangkapan tahap blok Amazon EBS(Elastic Block Store)
。
Apabila tetingkap sandaran automatik dimulakan, lapisan bawah AWS mencetuskan mekanisme snapshot. Sebab utama mengapa proses ini mempengaruhi prestasi pangkalan data adalah seperti berikut:
1. Kelewatan I/O disebabkan oleh penulisan salinan (Copy-on-Write, COW)
EBS menggunakan mekanisme snapshot tambahan ketika membuat snapshot. Walaupun snapshot pertama adalah jumlah penuh dan snapshot berikutnya adalah kenaikan, sistem penyimpanan perlu menandakan keadaan blok data pada saat snapshot dipicu.
Semasa pembuatan snapshot, jika aplikasi memulakan operasi menulis, lapisan penyimpanan perlu melakukan "Copy-on-Write" atau mengarahkan logik penulisan. Ini akan menyebabkan peningkatan penulisan, yang secara langsung meningkatkan kelewatan membaca/menulis cakera dan kedalaman barisan cakera.
2. Perbezaan mekanisme antara Single-AZ (Kawasan Tunggal) dan Multi-AZ (Kawasan Pelbagai)
Senibina Single-AZ: Contoh RDS hanya mempunyai satu nod utama, dan tangkapan gambar mesti dijalankan secara langsung pada volume penyimpanan EBS nod utama. Pada peringkat awal membuat snapshot, volume EBS akan mempunyai I/O tergantung seketika (I/O Suspension), yang memakan masa antara beberapa saat hingga puluhan saat. Untuk perkhidmatan penulisan serentak yang tinggi, penggantungan I/O dalam beberapa saat ini cukup untuk menyebabkan pengumpulan permintaan hulu dan kumpulan sambungan penuh.
Senibina Multi-AZ: AWS akan memuat turun sandaran automatik ke nod sandaran (Standby Instance)
Baiklah. Secara teori, membaca dan menulis I/O pada nod utama tidak terjejas secara langsung oleh snapshot. Walau bagaimanapun, jika nod sandaran menyebabkan prestasi I/O menurun kerana sandaran dan tidak dapat mengikuti log replikasi nod utama, nod utama mungkin tertakluk kepada replikasi segerak (seperti mekanisme semi-segerak atau penyekat log data) dan menghasilkan jitter prestasi.
3. Penyimpanan IOPS dan titik pecah (Burst Balance) habis
Sekiranya RDS menggunakan generasi yang lebih tua
GP2 (SSD sejagat)
Penyimpanan, prestasi IOPS bergantung pada "Burst Balance".
Semasa tetingkap sandaran, snapshot membaca data dan perniagaan itu sendiri membaca dan menulis, mudah untuk mengisi IOPS GP2 dengan cepat. Setelah titik tiba-tiba habis, IOPS EBS akan langsung jatuh ke tahap dasar seperti tebing (contohnya, garis dasar penyimpanan GP2 berkapasiti kecil hanya 100 IOPS), yang secara langsung menyebabkan pangkalan data tersekat. Walaupun
GP3
Penyimpanan, jika IOPS yang telah ditetapkan atau throughput perniagaan tidak mencukupi, ia juga akan memukul dinding prestasi semasa sandaran.
Kaedah diagnosis dua, empat langkah: bagaimana mencari punca kemacetan dengan tepat?
Apabila prestasi pangkalan data turun naik secara drastik di tetingkap sandaran, jangan berkembang secara membuta tuli. Dianjurkan untuk mencari alasan sebenar mengikut "kaedah diagnosis empat langkah" berikut:
[Langkah 1: Penjajaran garis masa CloudWatch] ───> [Langkah 2: Periksa peristiwa menunggu Prestasi Insights]
│
[Langkah 4: Periksa tugas masa perniagaan/urusan utama] <─── [Langkah 3: Periksa jenis penyimpanan dan kemacetan IOPS]
Langkah 1: Penjajaran garis masa (kontras silang pemantauan CloudWatch)
Masukkan panel pemantauan CloudWatch, skala jangka waktu hingga 2 jam sebelum dan sesudah berlakunya kelainan, dan perhatikan petunjuk teras berikut:
WriteLatency dan ReadLatency: Perhatikan sama ada kelewatan membaca dan menulis cakera mempunyai puncak curam ketika tetingkap sandaran dibuka (biasanya mestilah kurang dari 10ms, jika melambung hingga puluhan atau bahkan ratusan milisaat, ini menunjukkan bahawa kemacetan lapisan penyimpanan jelas).
ReadIOPS / WriteIOPS dan DiskQueueDepth: Periksa sama ada IOPS telah mencapai had atas kelantangan penyimpanan semasa, dan perhatikan sama ada kedalaman antrian cakera jauh melebihi nilai normal (biasanya disarankan agar kedalaman antrian dikekalkan pada sekitar IOPS / 500 yang telah ditetapkan, yang menunjukkan bahawa I/O mempunyai tunggakan yang serius).
EBSSurplusBalance / BurstBalance: Sekiranya anda menggunakan storan GP2, periksa sama ada penunjuk Burst Balance turun hingga 0%.
Langkah 2: Dengan Perfo
Rmance Insights (Analisis mendalam prestasi)
Membuka RDS Performance Insights dapat membantu kita melihat apa yang SQL melambatkan pangkalan data. Tumpuan utama
AAS(Average Active Sessions, purata sesi aktif)
Dan acara menunggu (Wait Events):
Sekiranya terdapat sebilangan besar io/file/innodb/innodb_data_file atau IO:DataFileRead / IO:DataFileWrite menunggu, ini bermaksud bahawa kemacetan utama tertumpu pada cakera fizikal I/O.
Sekiranya terdapat sebilangan besar wait/sych/sxlock/innodb/btr_search_latch atau kunci memori yang menunggu, ini bermaksud bahawa halaman data tidak dapat dileret tepat pada waktunya kerana halangan I/O, yang akan mencetuskan pertikaian kunci di dalam pangkalan data.
Langkah 3: Periksa seni bina contoh dan jenis penyimpanan
Sahkan konfigurasi atribut contoh RDS semasa:
Adakah Single-AZ atau Multi-AZ?
Adakah jenis storan GP2, GP3, atau IOPS Provisioned (io1/io2)?
Adakah mesin pangkalan data menghidupkan pembersihan Log Undo besar atau cakera berus berkadar tinggi Dirty Pages?
Langkah 4: Selesaikan konflik antara bahagian aplikasi dan tugas masa latar belakang
Banyak pasukan terbiasa menjalankan tugas berjadual seperti transaksi panjang, pengarkiban data, dan penjanaan laporan ETL pada waktu malam. Sekiranya tugas pemasaan perniagaan ini bertepatan dengan tetingkap sandaran automatik RDS AWS, ia akan membentuk kesan "menulis, memperbesar, membaca snapshot", yang secara langsung akan meletup cakera I/O.
3. Pelan pengoptimuman tadbir urus dan struktur yang menyeluruh
Setelah mencari punca masalah, kita dapat melakukan pemerintahan yang disasarkan dari empat aspek: "pemutusan struktur", "peningkatan penyimpanan", "penyesuaian konfigurasi" dan "jaminan operasi dan penyelenggaraan".
1. Peningkatan seni bina: zon tunggal ke zon berganda (Single-AZ ditingkatkan menjadi Multi-AZ)
Jika RDS dalam persekitaran pengeluaran masih menggunakan Single-AZ, ia sangat disyorkan untuk menaik taraf kepada penggunaan Multi-AZ.
Kesan: Selepas peningkatan, AWS secara automatik akan memindahkan tugas sandaran automatik harian ke nod sandaran Standby untuk dilaksanakan, dan sepenuhnya memotong kesan langsung penggantungan snapshot I/O pada perniagaan pengeluaran nod utama.
2. Transformasi penyimpanan: penghijrahan lancar dari GP2 ke GP3, atau IOPS yang telah ditetapkan
Ucapkan selamat tinggal kepada GP2:GP2 bergantung pada Burst Balance dan prestasinya sangat tidak stabil. GP3 menyediakan IOPS bebas dan kapasiti pratetap throughput, konfigurasi asas menyediakan 3,000 IOPS dan 125 MB/s
Throughput.
Gunakan io1/io2 untuk senario beban tinggi: Untuk pangkalan data teras dengan keperluan serentak dan latensi rendah yang sangat tinggi, disarankan untuk memilih storan IOPS(io1/io2) secara langsung, dan menetapkan nilai prabayar IOPS yang mencukupi mengikut keperluan pengkomputeran perniagaan.
3. Susun semula tetingkap sandaran dan tugas masa berperingkat
Tentukan semula Window Backup: Dalam tetapan RDS, sesuaikan tetingkap sandaran automatik ke jangka masa dengan lalu lintas perniagaan terendah sepanjang hari (misalnya, 03:00 - 04:00 pada waktu pagi).
Tugas masa berperingkat: mengejutkan tugas masa seperti pemprosesan kumpulan, pengarkiban data, refactoring indeks dalam sistem dan tetingkap sandaran automatik sekurang-kurangnya 1-2 jam untuk mengelakkan penumpukan lalu lintas.
4. Jaminan operasi dan penyelenggaraan: pengembangan sumber awan dan pengurusan anggaran
Sama ada menaik taraf Single-AZ ke Multi-AZ, menaik taraf GP2 ke GP3/io2, atau meningkatkan spesifikasi contoh dan pratetap IOPS, ia akan membawa perubahan tertentu dalam kos infrastruktur awan.
Semasa melakukan penyesuaian struktur dan perubahan sumber ini, perlu memastikan bahawa akaun AWS berada dalam keadaan sihat dan mempunyai kuota yang mencukupi. Bagi pengguna perniagaan, periksa status kewangan akaun secara berkala dan lengkapkan tepat pada waktunya
Mengecas akaun AWS
Ini adalah tindakan jaminan operasi dan penyelenggaraan utama. Sekiranya semasa tempoh puncak perubahan atau fasa pengembangan automatik, perkhidmatan terhad atau perubahan terganggu kerana tunggakan akaun, yang boleh menyebabkan kemalangan pengeluaran yang lebih serius. Oleh itu, memasukkan pengurusan kewangan dan belanjawan ke dalam Operasi Operasi Standard (SOP) operasi dan penyelenggaraan harian adalah bahagian penting untuk memastikan ketersediaan pangkalan data yang tinggi.
4. Ringkasan dan amalan terbaik Checklist
Turun naik prestasi yang disebabkan oleh sandaran automatik AWS RDS pada dasarnya
Penyimpanan fizikal sumber I/O mencapai hambatan di bawah tekanan snapshot
Perwujudan. Melalui reka bentuk seni bina dan penyesuaian parameter yang munasabah, "sandaran bukan induktif" dapat dicapai sepenuhnya.
Dalam operasi dan penyelenggaraan harian, disarankan untuk merujuk senarai semak amalan terbaik berikut:
Periksa dimensi
Keperluan Amalan Terbaik
Penjelasan
Senibina penyebaran
Pangkalan data pengeluaran mesti dihidupkan Multi-AZ
Letakkan tekanan I/O sandaran ke nod sandaran Standby
Jenis Penyimpanan
Tinggalkan GP2 dan tingkatkan sepenuhnya ke GP3 atau io1/io2
Berikan IOPS dan throughput yang dapat diramalkan untuk mengelakkan titik tiba-tiba jatuh ke sifar
Pengurusan tetingkap
Tetingkap sandaran mengelakkan puncak perniagaan
Pastikan tiada tugas berat ETL atau batch Delete/Update dalam tempoh masa sandaran
Penggera pemantauan
Konfigurasikan Penggera CloudWatch WriteLatency dan DiskQueueDepth
Tanda-tanda penurunan prestasi penyimpanan dikesan terlebih dahulu
Operasi dan penyelenggaraan kewangan
Simpan
Isi semula akaun AWS dan dana yang mencukupi
Memastikan kelancaran pelaksanaan pengembangan fleksibel, perubahan penyimpanan dan peningkatan Multi-AZ
Selagi anda memahami mekanisme operasi EBS Snapshot yang mendasari, digabungkan dengan langkah-langkah diagnosis dan penyelesaian yang jelas dan transformasi seni bina yang munasabah, anda dapat dengan mudah mengatasi masalah turun naik dramatik dalam prestasi semasa sandaran automatik RDS, dan mengawal kelancaran operasi perniagaan dalam talian.
