Sistem pengelompokan basis data untuk penskalaan horizontal MySQL

Database


Ada ide. Sebuah ide untuk membuat Vitess mandiri. Ide untuk menghilangkan gesekan antara Vitess dan alat diagnostik dan perbaikan eksternal. Ide yang melahirkan VTORc…

Baik VTORc dan Orchestrator adalah alat untuk mengelola instance MySQL. Jika saya menggambarkan alat-alat ini menggunakan metafora, saya akan mengatakan bahwa mereka seperti monitor untuk kelas siswa. Mereka bertanggung jawab untuk memantau instance MySQL dan memperbaikinya jika mereka berperilaku tidak semestinya, seperti halnya monitor memastikan bahwa tidak ada kerusakan yang terjadi di dalam kelas.

VTOrc dimulai sebagai garpu Orchestrator, yang kemudian diinstal secara khusus pada kasus penggunaan Vitess yang berjalan sebagai komponen asli Vitess. VTORc dan Orchestrator seperti kembar, jika Anda melihat mereka dari kejauhan, Anda mungkin berpikir mereka sama dan melakukan hal yang sama, tetapi semakin dekat Anda melihat, semakin banyak perbedaan dalam arsitektur, kinerja, dan fleksibilitas menjadi jelas. Jika Anda tertarik untuk menghargai perbedaan antara kedua kembar ini, maka Anda berada di tempat yang tepat. Mari kita melompat ke dalamnya.

Sebagian besar perbedaan antara keduanya terutama berasal dari fakta bahwa VTORc dapat mengomentari banyak hal karena hanya harus menyelesaikan satu kasus penggunaan, yaitu kasus penggunaan Vitess, tetapi Orchestrator dibangun untuk bekerja dengan MySQL apa pun. Topologi Misalnya, Vitess saat ini tidak mendukung replikasi hierarkis. Anda memiliki 1 tablet asli dalam keadaan utuh dan salinan dari yang asli. Tidak ada replikasi cascading. Tidak ada replika yang mereplikasi replika lain dalam mode statis. Tapi Orchestrator mengizinkan konfigurasi ini. Dengan demikian, VTORc tidak perlu khawatir tentang topologi hierarkis dan dapat mengabaikan fleksibilitas yang diberikan Orchestrator demi kode yang lebih sederhana yang berinteraksi dengan komponen Vitess lainnya seperti vtcltd.

Titik perbedaan pertama antara keduanya adalah bahwa Orchestrator adalah alat yang lengkap, sementara VTORc adalah bagian dari kerangka kerja yang jauh lebih besar, Vitess. Jadi VTORc dapat mengandalkan komponen Vitess lainnya untuk menyederhanakan desainnya. Mari kita lihat penemuan sampel MySQL untuk lebih memahami hal ini.

Dari dokumentasi Orchestrator di Discovery, Orchestrator actively crawls through your topologies and maps them. It reads basic MySQL info such as replication status and configuration. VTORc, di sisi lain, mengambil pendekatan yang sama sekali berbeda di sini. Di Vitess, semua instance MySQL memiliki sidecar yang terkait dengannya yang disebut VTTablet. Tablet VTT ini mendaftarkan diri di server topologi. Jadi VTORc dapat melanjutkan dan meminta server topologi untuk daftar lengkap tablet VTT untuk pecahan miliknya, dan menggunakan catatan tersebut untuk menemukan dan polling instance MySQL yang mendasarinya.

Ada dimensi lain untuk ditemukan yang melampaui situasi saat ini. Ini adalah topologi instance MySQL diasumsikan Dari sudut pandang VTORc, kita sudah tahu bahwa Vitess hanya mendukung satu hierarki replikasi MySQL tanpa skenario utama bersama, jadi diasumsikan bahwa hanya ada satu primer per shard dan semua instance MySQL lainnya di shard pasti ada. untuk diulang darinya. Adapun siapa masternya, informasi itu disimpan di server topologi. Namun, untuk orkestra, tidak ada lokasi pusat untuk menyimpan topologi yang diinginkan, ia harus menyimpulkan bahwa berdasarkan konfigurasi topologi saat ini dan perubahan apa pun yang mungkin dilakukan pengguna di masa mendatang. Dengan kata lain, penemuan dan pemeliharaan topologi VTORc agak bersifat deklaratif, sedangkan orkestra bekerja dengan cara yang lebih imperatif.

Sama seperti memiliki topologi server yang sangat menyederhanakan penemuan MySQL, ini juga membantu sinkronisasi.

Saat memelihara dan mencoba memperbaiki topologi MySQL, penting untuk memastikan bahwa hanya satu aktor yang mencoba mengubah topologi, jika tidak, masalah dapat terjadi dengan sangat cepat. Misalnya, Anda memiliki cluster yang sedang berjalan yang primernya telah gagal dan Anda memiliki beberapa orkestrasi yang sedang berjalan. Jika, secara kebetulan, dua orkestra memutuskan untuk mempromosikan primitif yang berbeda, ini akan menghasilkan konfigurasi topologi yang rusak, dengan beberapa replika menunjuk ke satu contoh dan yang lain menunjuk ke contoh lain. Otak yang terbelah dari posisi ini sangat mungkin terjadi dan dapat menyebabkan sakit kepala yang parah.

Untuk menghindari node orkestra menginjak kaki satu sama lain, solusi yang mungkin adalah hanya memiliki satu orkestra yang mempertahankan sebuah cluster. Tetapi ini tidak mungkin karena, seperti aplikasi lainnya, orkestra dapat mengalami kegagalan, beberapa di antaranya berada di luar kendali mereka, seperti mengeluarkan node di lingkungan Kubernetes, kehabisan CPU yang dialokasikan untuknya, dll. Oleh karena itu, Anda harus menerapkan lebih dari satu node orkestra per cluster untuk ketersediaan tinggi.

Orkestra menyediakan dua cara untuk menyediakan ketersediaan tinggi, yang pertama menggunakan algoritma konsensus Raft, dan yang kedua menggunakan penyimpanan cadangan bersama untuk node orkestra.

VTORc, di sisi lain, bergantung pada fungsi kunci pecahan yang ada yang digunakan Vitess untuk menyinkronkan antara aktor yang berbeda. Karena server topologi adalah penyimpanan nilai kunci tepercaya yang menjalankan beberapa algoritme konsensus di bawah kap, VTORc dapat mengandalkannya untuk fungsi ini yang memungkinkan hanya satu aktor untuk memperoleh kunci pecahan dan dengan demikian Pastikan sinkronisasi. Hal ini memungkinkan beberapa contoh VTORc untuk memantau sebuah cluster tanpa mengetahui atau peduli tentang keberadaan cluster lain.

Di Vitess, server topologi bertanggung jawab untuk menyimpan data yang stabil dan tahan lama seperti struktur topologi, kebijakan ketahanan, dll. Ini memungkinkan VTORc berfungsi dengan hanya menyimpan data sementara. Itu tidak memerlukan data apa pun untuk bertahan di seluruh reboot, membuat VTORc benar-benar komponen berbasis cloud karena dapat di-boot ulang sesuka hati dan datanya akan diisi ulang dari server topologi.

Orchestrator hadir dengan antarmuka pengguna yang menarik yang berfungsi sebagai bagian terakhir dari alat yang sudah mengesankan. Ini memungkinkan pengguna untuk melihat struktur topologi saat ini, memeriksa pengaturan semua node MySQL dan bahkan mengubahnya, langsung dari UI!

Namun, di Vitess, antarmuka pengguna tidak hanya tentang menjalankan instance MySQL, tetapi juga perlu mengakomodasi komponen Vitess lainnya seperti vttablets dan vtgates. Ini akan memungkinkan pengguna untuk melihat konfigurasi Vitess mereka saat ini seperti VSchema dan juga memungkinkan mereka untuk mengubahnya dengan mulus. Di sinilah komponen Vitess lain datang untuk menyelamatkan kami, VTAdmin. Ini adalah alat manajemen yang disediakan oleh Vitess yang menyediakan API dan antarmuka web. Tim bekerja untuk menggabungkan semua data dan fungsionalitas yang disediakan UI VTORc (diwarisi dari Orchestrator) ke dalam VTAdmin, di mana VTORc UI mandiri akan ditinggalkan dan dihapus.

Mengintegrasikan orkestra bawaan ke dalam Vitess tidak praktis dan telah menyebabkan bug di masa lalu. Menjadikan VTORc sebagai komponen Vitess asli yang mengetahui komponen Vitess lainnya memungkinkan kami untuk tidak bergantung pada integrasi yang rapuh. Ini juga memberikan peluang untuk menghapus kode yang tidak lagi diperlukan. Misalnya, tablet VTT memiliki kemampuan untuk mencadangkan atau memulihkan dari cadangan sebelumnya. Dengan integrasi Vitess-Orchestrator, tablet VTT harus masuk ke mode pemeliharaan sebelum mulai mencadangkan. Ini diperlukan karena replikasi berhenti selama pencadangan dan kami tidak ingin orkestra memperbaikinya. Ini berarti bahwa VTTablets harus mengetahui setidaknya satu node orkestra untuk meminta mode pemeliharaan. VTORc, di sisi lain, memiliki akses ke metadata VTTablet bersama dengan instance MySQL, yang memungkinkannya untuk menyimpulkan bahwa VTTtablet sedang dicadangkan dan bahwa replikasi tidak boleh dibuktikan tanpa tindakan eksplisit dari VTTablet.

Ada beberapa kemungkinan VTORc untuk menangani skenario kegagalan yang dapat ditanganinya dibandingkan dengan Orchestrator. VTORc juga dapat menangani kerusakan yang terkait dengan tablet VTT, bukan hanya instance MySQL. Untuk melakukan hal yang sama, seseorang dapat berlangganan pemeriksaan kesehatan VTTablet. Kemungkinannya tidak terbatas dan benar-benar menarik.

Dengan VTORc yang akan segera hadir di GA, sekarang adalah waktu yang tepat bagi Anda untuk mencobanya. Jika ya, beri kami umpan balik tentang pengalaman Anda melalui GitHub atau Slack.



Source link

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.