Bagaimana mysql menangani kelambatan replikasi?

select unix_timestamp(now(6)) - unix_timestamp(ts) as replication_delay from heartbeat order by ts desc limit 1

MySQL adalah salah satu penyimpanan data transaksional paling populer dan tepercaya di dunia dan tidak mengherankan jika Flipkart mengelola salah satu armada MySQL terbesar di India karena e-commerce sebagai domain, yang sangat berat dalam pemrosesan data transaksional

Siapa pun yang telah bekerja dengan MySQL sangat menyadari kelambatan replikasi saat sistem mengalami skala tinggi. Meskipun tidak jarang terjadi kelambatan replikasi, ukuran, skala, dan frekuensi data yang ditangani sepanjang tahun dan terutama selama penjualan, kami tidak dapat mengesampingkan dampak fungsional, operasional, dan bisnis yang disebabkan oleh kelambatan replikasi. Selama Big Billion Day Sales Flipkart, sejumlah klaster selalu digunakan untuk membuat kelambatan replikasi pada replika, dan tim Altair membangun kembali node untuk memperbaiki masalah tersebut. Kami mengidentifikasi cluster yang menghadapi masalah kelambatan replikasi tinggi dan alasan yang sama

Dalam kapasitas kami sebagai platform pusat, kami menganalisis berbagai jenis beban kerja, skema, dan pola kueri untuk menghasilkan panduan terdokumentasi dengan baik tentang pengelolaan kelambatan Replikasi

Artikel ini adalah laporan investigasi, analisis, pengujian, hasil, dan rekomendasi untuk mengelola kelambatan replikasi sebagai bagian dari armada MySQL yang dikelola secara terpusat di Flipkart

Altair adalah DBaaS untuk layanan MySQL yang dibangun di atas konstruksi Flipkart Cloud Platform yang menawarkan pengalaman penyediaan/pemeliharaan/pengelolaan klaster MySQL yang lancar dan penyediaan infrastruktur abstrak dengan integrasi layanan platform lengkap

Altair (DBaaS Flipkart) mengelola sekitar 700 klaster mulai hari ini dan dari jumlah tersebut, 450 klaster aneh berjalan di MySQL v5. 7 dan 250 cluster ganjil masih berjalan di MySQL v. 5. 6. Cluster ini menjalankan beban kerja yang berbeda, misalnya, sistem manajemen Pemesanan, Pengiriman dan Gudang, sistem Akuntansi. Adapun ukuran data, cluster ini berkisar dari 500GB hingga 3TB

Kami memulai analisis dengan mengumpulkan kelambatan replikasi yang diamati selama 3 bulan terakhir pada semua kluster di Altair. Seiring dengan lag replikasi, kami mengumpulkan versi MySQL cluster dan format log biner yang digunakan dalam cluster dan juga mengamati QPS pada cluster ketika lag replikasi tinggi (> 1000 detik)

Jumlah cluster. 700

Lag Replikasi Tinggi MySQL 5. 6 Cluster. 26

Lag Replikasi Tinggi MySQL 5. 7 Gugus. 3

Kelambatan replikasi paling tinggi dalam contoh replika diamati di MySQL versi 5. 6. Di cluster pada MySQL versi 5. 7, QPS tinggi pada Master

MySQL mendukung replikasi data ke beberapa node lain (VM atau Pod) yang disebut replika untuk mendapatkan keandalan dan ketersediaan yang lebih baik. Node tempat data direplikasi ini dikenal sebagai Replika. Mereka menyimpan seluruh data dan bukan hanya sebagian data (tidak seperti beberapa sistem terdistribusi lainnya) — namun, data ini bisa sepenuhnya sinkron (atau konsisten) dengan node Sumber atau asinkron (atau akhirnya konsisten) dengan node Sumber

Ada berbagai aspek replikasi data

1. Menggunakan file/penunjuk yang disebut Binary Logs atau Global Transaction Identifier
2. Menggunakan mode ASYNC atau SEMI-SYNC atau SYNC untuk menyinkronkan data ini (masing-masing memiliki pro dan kontra)

Replikasi ini dilakukan dalam dua fase biasanya untuk menjaga integritas data

1. Transfer jaringan — juga disebut utas IO — menarik data dari Sumber ke Replika ke dalam file yang disebut log relai
2. Terapkan di MySQL — juga disebut utas SQL — membaca dari log relai dan menulis ke MySQL untuk mempertahankan urutan

MySQL5. 5 memiliki satu utas SQL untuk menerapkan peristiwa log relai, dan MySQL 5. 6 memperkenalkan replikasi paralel (beberapa utas SQL) untuk menerapkan log relai pada tingkat database/skema. Di MySQL5. 7, kita dapat memiliki beberapa utas SQL pada replika untuk menerapkan peristiwa log relai untuk komit grup yang sama

Lag Replikasi adalah penambahan penundaan yang disebabkan oleh utas — dalam hal waktu — perbedaan antara waktu kueri dieksekusi di Sumber MySQL dan waktu dieksekusi di Replika MySQL

Berikut adalah contoh sederhana tentang apa yang dapat terjadi jika sistem dirancang tanpa mempertimbangkan kelambatan replikasi

Mari pertimbangkan situs web e-niaga yang terlalu sederhana dengan sistem manajemen pesanan sederhana (OMS) yang diberdayakan oleh MySQL — setiap kali seseorang memesan item dari situs web, item tersebut ditulis ke database ini. Dan ketika seseorang ingin mengetahui status pesanannya, itu dibaca dari database ini. Menurut tim, yang terbaik adalah mengarahkan pembacaan ke node lain untuk mengurangi beban pada Primer

Jadi secara teknis, penulisan pesanan terjadi pada Pratama sementara detail pesanan dibaca dari Replika dan ditampilkan di situs web. Sepertinya hal yang adil untuk dilakukan ketika tidak ada banyak skala; . e. — hampir setiap hari / BAU — namun, inilah yang dapat terjadi, jika ada skala yang signifikan dan replika kelambatan

Mari kita asumsikan ada satu sistem lagi di sini — Sistem Manajemen Gudang (WMS), yang memproses pesanan dari gudang

Sekarang bayangkan ada obral dan karena beban besar pada sistem, Replika tertinggal 10 jam. Ini berarti ini akan mencerminkan keadaan pesanan hampir 10 jam yang lalu, dalam hal ini, beginilah tampilannya sekarang

1. Seseorang yang melakukan pemesanan di situs web tidak langsung melihatnya di halaman 'Pesanan Saya' — yang menyebabkan eskalasi layanan pelanggan yang tidak perlu
2. Jika pesanan telah dikirim, pelanggan masih melihat pembaruan 10 jam yang dipesan dan ini juga dapat menyebabkan eskalasi yang tidak perlu
3. Jika pesanan benar-benar dikirim dan kami menampilkannya sebagai pesanan, yang mungkin mendorong pelanggan untuk 'membatalkan' pesanan
4. Pembatalan semacam itu sangat merugikan organisasi karena produk telah dikirim

> Biaya pengangkutan produk kembali ke gudang

> Biaya pemeriksaan QA

> Biaya pengemasan

Biaya tambahan ini tidak hanya berupa uang, tetapi juga merupakan kerugian dalam upaya, waktu, dan kepuasan pelanggan, meskipun pelanggan menginginkan produk tersebut, dan alur kerja berjalan sesuai rencana.

Terkadang kasus penggunaan tidak terpengaruh oleh kelambatan Replika atau sistem juga dapat dirancang untuk konsistensi pada akhirnya. Sebagai contoh,

Mari kita bicara tentang pembaruan inventaris — jika 1000 kuantitas inventaris tertentu telah masuk ke gudang pada waktu t0 sementara pembaruan ke sistem manajemen pesanan terjadi dari Replika yang berjalan lambat beberapa jam, maka ada

Atau contoh lainnya adalah — jika laporan dibuat dari database yang biasanya berjalan dengan jeda replikasi beberapa jam, maka laporan tersebut tidak benar-benar terpengaruh karena diketahui bahwa mereka tidak menanyakan data terbaru tetapi lebih tertarik

Meskipun demikian, terkadang tim memulai dengan kasus penggunaan asli di mana hanya ada sedikit atau tidak ada dampak karena kelambatan replikasi pada kasus penggunaan tertentu, tetapi pada akhirnya juga mengaktifkan beberapa fitur yang masih oke dengan kelambatan terikat tetapi bukan kelambatan tak terbatas. Alasan lain tim melakukan ini adalah untuk mengurangi tekanan pada Primer dan mengalihkan sebagian lalu lintas ke beberapa Replika

Kami menjalankan eksperimen untuk memahami apakah ada peningkatan versi cluster dari 5. 6 sampai 5. 7 dapat membantu dalam mengurangi masalah kelambatan replikasi. Ini membantu kami menguji hipotesis kami tanpa membabi buta mempercayai tolok ukur eksternal apa pun

Kami menerapkan dua cluster MySQL, satu dengan MySQL 5. 6 dan lainnya dengan MySQL 5. 7, dengan masing-masing cluster berisi dua node, Master dan Hot Standby

Kami memilih beberapa konfigurasi perangkat keras yang paling sering digunakan untuk pengujian

Kami menyimpulkan dengan melakukan latihan dengan menyetel konfigurasi di bawah ini karena memengaruhi kelambatan replikasi

Di tim platform Flipkart, kami lebih suka menjalankan tolok ukur menggunakan berbagai alat tolok ukur yang tersedia untuk set validasi awal dan kemudian melibatkan tim fungsional untuk memvalidasi kasus penggunaan

Ada beberapa alat pembandingan yang tersedia di pasar yang membantu kami menguji banyak skenario basis data. Masing-masing alat ini menawarkan beban kerja yang berbeda yang dapat disesuaikan untuk kumpulan database yang berbeda dan kemampuannya

• YCSB. Menyediakan beban kerja sederhana, paling cocok untuk evaluasi database NoSQL
• TPC-C. Mensimulasikan beban kerja OLTP. Ini memiliki jenis transaksi yang lebih kompleks dan mensimulasikan sistem pemasok grosir, lebih umum dalam sistem e-commerce. Pada dasarnya digunakan untuk mengukur throughput dan stabilitas sistem
• Sysbench. Menawarkan beban kerja yang paling sesuai untuk MySQL (DBMS) dan dapat disesuaikan, sesuai kebutuhan

Dalam pengujian kami, kami lebih suka menggunakan alat Sysbench karena menyediakan beban kerja transaksional dengan banyak tabel

sysbench --db-driver=mysql --mysql-user=sbtest --mysql-host=10.54.2.218 --mysql-password='test' --mysql-db=test --mysql_storage_engine=innodb --table_size=10000000 --tables=8 --threads=8  /usr/share/sysbench/oltp_write_only.lua --time=1200 run

• Menyebarkan MySQL v5. 6 dan v5. 7 cluster dengan detail perangkat keras yang disebutkan di atas
• Tambahkan konfigurasi yang disebutkan di atas dalam file konfigurasi dan mulai ulang server
• Gunakan beban kerja oltp_write_only Sysbench dan mulai pengujian dengan 8 utas, 8 tabel, dan 10 Juta rekaman
• Jalankan pengujian selama 1200 detik dan rekam QPS dan jeda replikasi pada replika

MySQL5. 6 Memuat QPS dan lag Replikasi

MySQL5. 7 Memuat QPS dan lag Replikasi

Dari grafik, kita melihat bahwa beban telah berjalan dengan durasi yang sama baik di 5. 7 dan 5. 6 cluster. Jeda replikasi 30 menit diamati pada 5. 6 cluster sedangkan jeda replikasi 3 menit terlihat pada 5. 7 cluster

Dalam analisis kami, kami juga memperhatikan bahwa beberapa kluster dengan masalah kelambatan replikasi tinggi juga menggunakan replikasi berbasis STATEMENT. Jadi kami ingin memahami jika replikasi multi-utas pada 5. 7 bekerja dengan baik dengan replikasi berbasis STATEMENT juga

Kami mengulangi test case menggunakan binlog_format = statement. Berikut adalah spesifikasi konfigurasi pengujian

Sysbench

Memerintah

sysbench --db-driver=mysql --mysql-user=sbtest --mysql-host=10.54.2.218 --mysql-password='test' --mysql-db=test --mysql_storage_engine=innodb --table_size=10000000 --tables=8 --threads=8  /usr/share/sysbench/oltp_write_only.lua --time=1200 runTest Results

MySQL5. 6 Memuat QPS dan lag Replikasi

MySQL5. 7 Memuat QPS dan lag Replikasi

Dari grafik, kita melihat bahwa beban telah berjalan dengan durasi yang sama baik di 5. 7 dan 5. 6 cluster. Jeda replikasi satu jam diamati pada 5. 6 kluster, sedangkan jeda replikasi 3 menit terlihat pada 5 kluster. 7 cluster

Sedangkan keduanya 5. 6 dan 5. 7 versi MySQL menawarkan replikasi multi-utas, MySQL 5. 6 hanya mendukung jenis replikasi "Database". Ini meningkatkan kinerja replikasi sampai batas tertentu hanya ketika cluster memiliki banyak database. MySQL5. 7 mendukung jenis replikasi "Database" dan "Logical_clock". Dalam tipe LOGICAL_CLOCK, transaksi yang merupakan bagian dari grup log biner yang sama yang dilakukan pada master diterapkan secara paralel ke replika. Tidak ada kendala lintas-database, dan data tidak perlu dipartisi ke dalam beberapa database

MySQL v8. 0 membawa beberapa peningkatan lagi dalam kinerja replikasi. Itu menambahkan applier paralel yang jauh lebih baik dengan mengandalkan WRITESET transaksi (kira-kira set baris berubah). Ini juga memungkinkan applier untuk menginstal perubahan secara paralel bahkan untuk beban kerja single-threaded yang berasal dari replikasi. Ada mekanisme sinkronisasi yang lebih baik antara penerima dan utas pemberi, yang berarti berkurangnya pertikaian antara penerima dan utas pemberi

Jika pengaturan Anda seperti yang disajikan dalam artikel ini, berikut adalah beberapa saran informasi yang mungkin berguna untuk menurunkan kelambatan replikasi secara signifikan

Apakah MySQL bagus untuk replikasi?

Apakah replikasi MySQL memengaruhi kinerja?

Bagaimana Anda menghentikan lag replikasi?

Permintaan apa yang dapat Anda gunakan untuk memeriksa kelambatan replikasi di MySQL?