Apabila pelayan MySQL baru menyertai atau menyertai semula kluster MGR, ia mesti mengejar urus niaga yang berbeza dalam kluster untuk memastikan data nod ini disegerakkan dengan data terkini dalam gugusan daripada. Proses di mana nod yang baru ditambah mengejar data dalam kluster atau nod yang menyertai semula kluster mengejar data transaksi yang berbeza dari masa ia meninggalkan kluster hingga kini dipanggil pemulihan teragih.
Nod yang digunakan untuk menyertai kluster terlebih dahulu menyemak log geganti dalam saluran groupreplicationapplier untuk menyemak data transaksi nod yang masih belum disegerakkan daripada kluster. Jika ia adalah nod yang menyertai semula kluster, nod akan mencari data urus niaga yang belum dimainkan semula sejak ia meninggalkan kluster dan data terkini dalam kluster Dalam kes ini, nod akan menggunakan urus niaga tidak segerak ini. Untuk nod yang baru ditambahkan pada kluster, pemulihan data penuh boleh dilakukan terus dari nod but.
Selepas itu, nod yang baru ditambah mewujudkan sambungan dengan nod dalam talian sedia ada (nod but) dalam kelompok untuk pemindahan keadaan. Nod yang baru ditambah menyegerakkan data yang belum disegerakkan sebelum menyertai kluster atau selepas meninggalkan kluster daripada nod but dalam kluster ini disediakan oleh nod but dalam kluster. Seterusnya, nod yang baru ditambah menggunakan transaksi yang tidak digunakan yang disegerakkan daripada nod bootstrap dalam kelompok. Pada masa ini, nod yang memohon untuk menyertai kluster akan menggunakan data yang ditulis oleh transaksi baharu dalam kluster semasa proses pemindahan negeri. (Pada masa ini, data yang ditulis oleh perkara baharu dalam kelompok disimpan sementara dalam baris gilir cache, dan data tidak ditulis pada cakera.) Selepas menyelesaikan proses ini, data nod yang baru ditambah berada pada tahap yang dibandingkan dengan data keseluruhan gugusan, dan nod ditetapkan kepada status dalam talian.
Nota: Nod baharu yang menyertai kluster, sama ada ia pernah berada dalam kluster ini sebelum ini atau tidak, terlebih dahulu akan memilih nod dalam talian secara rawak untuk menyegerakkan urus niaga berbeza antara nod dan kluster.
Replikasi kumpulan menggunakan kaedah berikut untuk melaksanakan pemindahan keadaan semasa pemulihan yang diedarkan:
Gunakan fungsi pemalam klon untuk operasi pengklonan jauh, yang boleh dimuat turun dari Disokong bermula dari MySQL 8.0.17. Untuk menggunakan kaedah ini, pemalam pengklonan mesti dipasang terlebih dahulu pada nod but dan nod yang baru dicantumkan. Replikasi Kumpulan secara automatik mengkonfigurasi tetapan pemalam klon yang diperlukan dan menguruskan operasi klon jauh.
Salin data daripada log perduaan nod but dan gunakan transaksi ini pada nod yang baru disertai. Kaedah ini memerlukan saluran replikasi tak segerak piawai yang dipanggil groupreplicationrecovery yang ditubuhkan antara nod but dan nod bercantum.
Selepas melaksanakan STARTGROUP_REPLICATION pada nod gabungan, Replikasi Kumpulan akan secara automatik memilih gabungan terbaik kaedah di atas untuk pemindahan keadaan. Untuk melakukan ini, Replikasi Kumpulan akan menyemak nod sedia ada dalam kluster yang sesuai untuk digunakan sebagai nod bootstrap, berapa banyak transaksi yang diperlukan oleh nod gabungan daripada nod bootstrap dan sama ada sebarang transaksi tidak lagi terdapat dalam fail log binari mana-mana nod dalam kelompok. Jika terdapat jurang urus niaga yang besar antara nod penyambung dan nod but, atau jika beberapa urus niaga yang diperlukan tiada dalam fail log perduaan nod but, Replikasi Kumpulan akan memulakan pemulihan yang diedarkan melalui operasi klon jauh. Jika tiada jurang transaksi yang besar, atau pemalam klon tidak dipasang, Replikasi Kumpulan akan memindahkan keadaan terus daripada log binari nod but.
Semasa operasi klon jauh, data sedia ada pada nod penyambung dipadamkan dan digantikan dengan salinan data nod but. Apabila operasi pengklonan jauh selesai dan nod yang baru dicantumkan telah dimulakan semula, pemindahan keadaan daripada log binari nod but akan terus mendapatkan data tambahan yang ditulis oleh kluster semasa operasi pengklonan jauh.
Semasa pemindahan keadaan daripada log binari nod but, nod yang baru bergabung menyalin dan menggunakan urus niaga yang diperlukan daripada log binari nod but dan menggunakan urus niaga semasa ia diterima sehingga log binari merekodkan yang baharu Nod gabungan bergabung dengan kelompok. (Apabila nod gabungan berjaya menyertai kluster, peristiwa perubahan paparan yang sepadan akan direkodkan dalam log binari.) Semasa proses ini, nod gabungan akan menimbal data transaksi baharu yang digunakan pada kluster. Selepas pemindahan keadaan daripada log binari selesai, nod yang baru dicantumkan akan menggunakan transaksi buffer.
Apabila nod penggabungan dikemas kini dengan semua transaksi untuk kluster, nod akan ditetapkan dalam talian dan boleh menyertai kluster sebagai nod biasa, dan pemulihan yang diedarkan selesai.
ps: Pemindahan keadaan daripada log binari ialah mekanisme asas untuk pemulihan teragih dengan replikasi kumpulan, dan jika nod but dan nod penyambung dalam kumpulan replikasi tidak disediakan untuk menyokong pengklonan. Memandangkan pemindahan keadaan daripada log binari adalah berdasarkan replikasi tak segerak klasik, jika pelayan MySQL yang menyertai kluster tidak mempunyai data untuk kluster sama sekali, atau data diperoleh daripada sandaran yang sangat lama, ia mungkin mengambil masa yang lama untuk pulih. Data terkini. Oleh itu, dalam kes ini, adalah disyorkan bahawa sebelum menambah pelayan MySQL pada kluster, anda harus menyediakannya dengan data kluster dengan memindahkan syot kilat nod yang sudah ada dalam kluster. Ini meminimumkan masa yang diperlukan untuk pemulihan yang diedarkan dan mengurangkan kesan pada nod but, yang mesti mengekalkan dan memindahkan lebih sedikit fail log binari.
Apabila nod cantum bersambung ke nod bootstrap dalam nod sedia ada untuk pemindahan keadaan semasa pemulihan teragih, Nod cantuman bertindak sebagai pelanggan, manakala nod bootstrap bertindak sebagai pelayan. Apabila pemindahan keadaan berlaku daripada log binari nod but melalui sambungan ini (menggunakan saluran replikasi tak segerak GroupReplicationRecovery), nod gabungan bertindak sebagai replika dan nod but bertindak sebagai sumber. Apabila melakukan operasi pengklonan jauh melalui sambungan ini, nod yang baru ditambah bertindak sebagai penerima data penuh dan nod but bertindak sebagai pembekal data penuh. Tetapan konfigurasi yang digunakan pada peranan di luar konteks Replikasi Kumpulan juga digunakan untuk Replikasi Kumpulan melainkan ia ditindih oleh tetapan atau gelagat konfigurasi khusus Replikasi Kumpulan.
Sambungan yang disediakan oleh nod sedia ada kepada nod yang baru bergabung untuk pemulihan teragih adalah berbeza daripada sambungan yang digunakan Replikasi Kumpulan untuk komunikasi antara nod dalam kelompok.
Enjin komunikasi kumpulan digunakan untuk replikasi kumpulan (XCom, varian Paxos), sambungan yang digunakan untuk komunikasi TCP antara tika XCom jauh ditentukan oleh pembolehubah sistem groupreplicationlocal_address. Sambungan ini digunakan untuk pemesejan TCP/IP antara nod dalam talian dalam kelompok. Komunikasi dengan tika tempatan berlaku melalui penggunaan saluran pengangkutan kongsi dalam memori.
Untuk pemulihan yang diedarkan, sehingga MySQL 8.0.20, nod dalam kluster menyediakan sambungan klien SQL standard mereka kepada nod gabungan, seperti yang ditentukan oleh nama hos MySQL Server dan pembolehubah sistem port. Jika pembolehubah sistem report_port menentukan nombor port ganti, nombor port itu digunakan sebaliknya.
Bermula dengan MySQL 8.0.21, ahli kumpulan boleh menggunakan senarai alternatif titik akhir pemulihan yang diedarkan sebagai sambungan pelanggan khusus untuk menyertai ahli, membenarkan sambungan bebas daripada pengguna pelanggan tetap ahli digunakan untuk mengawal pemulihan gaya pengedaran. Senarai ini boleh ditentukan menggunakan pembolehubah sistem groupReplicationAdvertiseRecoveryEndpoints dan ahli memindahkan senarai titik akhir pemulihan yang diedarkan kepada kumpulan apabila mereka menyertai kumpulan. Lalai adalah untuk ahli terus menyediakan sambungan klien SQL standard yang sama seperti dalam versi terdahulu.
PS:
Pemulihan teragih mungkin gagal jika nod yang bergabung tidak dapat mengenal pasti nod lain dengan betul menggunakan nama hos yang ditakrifkan oleh pembolehubah sistem MySQLServer. Adalah disyorkan bahawa sistem pengendalian yang menjalankan MySQL mempunyai nama hos unik yang dikonfigurasikan dengan betul menggunakan DNS atau tetapan setempat. Nama hos yang digunakan oleh pelayan untuk sambungan klien SQL boleh disahkan dalam lajur Memberhost pada jadual ReplicationgroupMembers di bawah pustaka "performanceschema". Jika berbilang ahli kumpulan membuat luaran nama hos lalai yang ditetapkan oleh sistem pengendalian, terdapat kemungkinan nod yang bergabung tidak akan menyelesaikannya ke alamat yang betul dan tidak akan dapat menyambung untuk pemulihan yang diedarkan. Dalam kes ini, pembolehubah sistem report_host Pelayan MySQL boleh digunakan untuk mengkonfigurasi nama hos unik yang diluarkan oleh setiap pelayan.
Langkah-langkah untuk menyertai nod untuk mewujudkan sambungan bagi pemulihan teragih adalah seperti berikut:
Apabila nod bergabung dengan kluster, ia menggunakan nod benih yang disertakan dalam senarai dalam pembolehubah sistem groupreplicationgroupseeds Buat sambungan, pada mulanya menggunakan groupreplicationlocaladdress yang dinyatakan dalam senarai ini. Nod benih mungkin merupakan subset data kluster.
Melalui sambungan ini, nod benih menggunakan perkhidmatan keahlian Replikasi Kumpulan untuk menyediakan nod gabungan dengan senarai semua nod dalam talian dalam kelompok dalam bentuk paparan. Maklumat keahlian termasuk butiran titik akhir pemulihan teragih atau sambungan klien SQL standard yang disediakan oleh setiap ahli untuk pemulihan teragih.
Join nod memilih nod dalam talian yang sesuai daripada senarai ini sebagai nod butnya untuk pemulihan teragih
Join nod cuba untuk menyambung ke nod but menggunakan titik akhir pemulihan teragih nod but dan tekan senarai Sambungan ke setiap titik akhir dicuba secara bergilir-gilir dalam susunan yang dinyatakan dalam . Jika nod but tidak menyediakan titik akhir, nod penyambung akan cuba menyambung menggunakan sambungan klien SQL standard nod but. Keperluan SSL untuk sambungan ditentukan oleh pilihan groupreplicationrecoveryssl*.
Jika nod penyambung tidak dapat menyambung ke nod but yang ditentukan, ia akan mencuba semula sambungan dengan nod but lain yang sesuai. Jika nod sambung kehabisan senarai siaran titik akhir tanpa membuat sambungan, ia tidak akan kembali kepada sambungan klien SQL standard nod but, sebaliknya beralih ke nod but lain untuk cuba mewujudkan semula sambungan.
Apabila nod penyambungan mewujudkan sambungan pemulihan yang diedarkan dengan nod but, ia akan menggunakan sambungan untuk pemindahan keadaan Log nod penyambungan menunjukkan hos dan port sambungan yang digunakan. Jika operasi klon jauh digunakan, apabila nod sambung dimulakan semula pada penghujung operasi, ia akan mewujudkan sambungan dengan nod but baharu, melakukan pemindahan keadaan daripada log binari nod but. Ini mungkin sambungan yang berbeza daripada nod but yang digunakan untuk operasi klon jauh, atau ia mungkin sambungan yang sama seperti nod but. Walau apa pun, pemulihan yang diedarkan akan mewujudkan sambungan ke nod but dengan cara yang sama.
Pembolehubah sistem groupreplicationadvertiserecoveryendpoints berfungsi sebagai alamat IP yang disediakan oleh hujung pemulihan yang diedarkan dan tidak perlu dikonfigurasikan untuk Pelayan MySQL (iaitu, ia tidak perlu dikonfigurasikan oleh pembolehubah sistem adminaddress atau yang dinyatakan dalam senarai pembolehubah sistem bindaddress).
Konfigurasikan port yang disediakan untuk akhir pemulihan diedarkan Pelayan MySQL, yang mesti ditentukan oleh pembolehubah sistem port, reportport atau adminport. Sambungan TCP/IP mesti didengari pada port ini. Jika adminport ditentukan, pengguna replikasi yang digunakan untuk pemulihan diedarkan memerlukan kebenaran SERVICECONNECTIONADMIN untuk menyambung. Memilih adminport memastikan sambungan pemulihan yang diedarkan berasingan daripada sambungan klien MySQL biasa.
Nod gabungan mencuba setiap titik akhir mengikut urutan yang dinyatakan dalam senarai. Jika groupreplicationadvertiserecoveryendpoints ditetapkan kepada DEFAULT dan bukannya senarai titik akhir, sambungan klien SQL standard akan disediakan. Sambungan klien SQL standard tidak disertakan secara automatik dalam senarai titik akhir pemulihan yang diedarkan dan tidak akan digunakan sebagai sandaran jika senarai titik akhir nod but kehabisan tanpa sambungan. Jika anda ingin menyediakan sambungan klien SQL standard sebagai salah satu daripada berbilang titik akhir pemulihan yang diedarkan, anda mesti memasukkannya secara eksplisit dalam senarai yang ditentukan oleh groupreplicationadvertiseadvertiserecovery_endpoints. Anda boleh meletakkan ini di penghujung sebagai sambungan pilihan terakhir.
Tidak perlu menambah titik akhir pemulihan teragih ahli kumpulan (atau sambungan klien SQL standard jika tiada titik akhir disediakan) ke senarai dibenarkan replikasi kumpulan yang ditentukan oleh groupreplicationipallowlist (daripada MySQL 8.0.22) atau pembolehubah sistem groupreplicationipwhitelist . Senarai kebenaran hanya digunakan pada alamat yang ditentukan oleh groupreplicationlocal_address untuk setiap nod. Nod yang bercantum mesti mempunyai sambungan awal ke gugusan yang dibenarkan oleh senarai yang dibenarkan untuk mendapatkan satu atau lebih alamat untuk pemulihan yang diedarkan.
Selepas menetapkan pembolehubah sistem dan melaksanakan pernyataan STARTGROUP_REPLICATION, titik akhir pemulihan teragih yang disenaraikan akan disahkan. Jika senarai tidak dapat dihuraikan dengan betul, atau jika sebarang titik akhir tidak dapat dicapai pada hos kerana perkhidmatan tidak mendengar dalam senarai, Replikasi Kumpulan akan log ralat dan gagal dimulakan.
Dalam MySQL 8.0.18, anda boleh mengkonfigurasi pemampatan untuk pemulihan teragih menggunakan kaedah pemindahan keadaan dalam log binari nod but. Mampatan boleh memanfaatkan pemulihan yang diedarkan dalam situasi di mana lebar jalur rangkaian terhad dan nod pemimpin mesti memindahkan banyak transaksi ke nod yang bercantum. Pembolehubah sistem groupreplicationrecoverycompressionalgorithm dan groupreplicationrecoveryzstdcompression_level mengkonfigurasi algoritma mampatan yang dibenarkan dan tahap mampatan zstd yang digunakan semasa melakukan pemindahan keadaan daripada log binari nod but.
Tetapan mampatan ini tidak digunakan pada operasi klon jauh. Apabila operasi klon jauh digunakan untuk pemulihan teragih, tetapan cloneenablecompression pemalam klon digunakan.
Pemulihan teragih memerlukan pengguna replikasi dengan kebenaran yang betul supaya Replikasi Kumpulan boleh mewujudkan saluran replikasi nod-ke-nod langsung. Pengguna replikasi juga mesti mempunyai kebenaran yang betul Jika pengguna replikasi juga bertindak sebagai pengguna klon dalam operasi klon jauh, pengguna replikasi juga mesti mempunyai kebenaran berkaitan klon jauh (kebenaran BACKUP_ADMIN) dalam nod but untuk bertindak sebagai klon. pengguna pada nod but Klonkan pengguna untuk operasi pengklonan jauh. Di samping itu, pengguna replikasi yang sama mesti digunakan untuk pemulihan yang diedarkan pada setiap nod dalam kelompok.
SSL yang digunakan untuk pemulihan teragih dikonfigurasikan secara berasingan daripada SSL yang digunakan untuk komunikasi kumpulan biasa, yang ditentukan oleh tetapan SSL pelayan dan pembolehubah sistem groupreplicationssl_mode. Untuk sambungan pemulihan teragih, anda boleh menggunakan pembolehubah sistem SSL Pemulihan Teragih Replikasi Kumpulan khusus untuk mengkonfigurasi penggunaan sijil dan kunci khusus untuk pemulihan teragih.
Secara lalai, SSL tidak digunakan untuk sambungan pemulihan yang diedarkan. Tetapkan groupreplicationrecoveryusessl=ON untuk mendayakannya, kemudian konfigurasikan pembolehubah sistem SSL pemulihan teragih replikasi kumpulan dan tetapkan pengguna replikasi untuk menggunakan SSL.
Apabila pemulihan teragih dikonfigurasikan untuk menggunakan SSL, Replikasi Kumpulan menggunakan tetapan ini pada operasi klon jauh dan pemindahan keadaan daripada log binari nod but. Replikasi Kumpulan secara automatik mengkonfigurasi pilihan SSL klon (clonesslca, clonesslcert dan clonesslkey) untuk memadankan tetapan pilihan pemulihan diedarkan Replikasi Kumpulan yang sepadan (groupreplicationrecoverysslca, groupreplicationrecoverysslcert dan groupreplicationrecoverysslkey).
Jika SSL tidak digunakan untuk pemulihan teragih (groupreplicationrecoveryusessl ditetapkan kepada MATI) dan akaun pengguna replikasi untuk replikasi kumpulan disahkan menggunakan pemalam cachingsha2password (lalai dalam MySQL 8.0) atau pemalam sha256password, kunci RSA pasangan digunakan untuk pertukaran kata laluan. Dalam kes ini, gunakan pembolehubah sistem groupreplicationrecoverypublickeypath untuk menentukan fail kunci awam RSA, atau gunakan pembolehubah sistem groupreplicationrecoverygetpublic_key untuk meminta kunci awam. Jika tidak, keseluruhan balasan yang diedarkan akan gagal disebabkan pelaporan ralat.
Pemalam klon untuk MySQLServer tersedia daripada MySQL8.0.17. Jika anda ingin menggunakan operasi klon jauh untuk pemulihan yang diedarkan dalam kelompok, nod sedia ada dan bercantum mesti disediakan terlebih dahulu untuk menyokong ciri ini. Jangan sediakan ini jika anda tidak mahu menggunakan ciri ini dalam kluster anda, yang mana Replikasi Kumpulan hanya menggunakan pemindahan keadaan dalam log binari.
Untuk menggunakan pemalam pengklonan, sekurang-kurangnya satu nod kluster sedia ada dan nod penyambungan mesti dipra-sediakan untuk menyokong operasi pengklonan jauh. Sekurang-kurangnya, pemalam pengklonan mesti dipasang pada but dan nod penyambungan, kebenaran BACKUPADMIN mesti diberikan kepada pengguna replikasi untuk pemulihan diedarkan dan pembolehubah sistem groupreplicationclonethreshold mesti ditetapkan pada tahap yang sesuai. (Secara lalai, ia adalah nilai maksimum yang dibenarkan oleh jujukan GTID, yang bermaksud bahawa dalam keadaan biasa, penghantaran status berdasarkan log binari sentiasa diutamakan, melainkan transaksi yang diminta oleh nod pencantum tidak wujud dalam mana-mana ahli kumpulan . Pada masa ini, jika ia ditetapkan Jika fungsi pengklonan dinyahdayakan, tidak kira apa nilai pembolehubah sistem ditetapkan, pemulihan yang diedarkan melalui pengklonan akan dicetuskan sebagai contoh, apabila pelayan yang baru dimulakan digunakan untuk menyertai kumpulan, lakukan tidak memasangnya jika anda tidak mahu menggunakan fungsi dan konfigurasi pengklonan) Untuk memastikan ketersediaan maksimum nod but, disyorkan untuk menyediakan semua nod kluster semasa dan masa hadapan untuk menyokong operasi pengklonan jauh. Supaya apabila pelayan menyertai kluster kemudian, operasi pengklonan jauh boleh digunakan untuk mengejar data terkini dalam kluster dengan cepat.
Operasi klon jauh memadamkan ruang jadual dan data ciptaan pengguna pada nod penyambung sebelum memindahkan data daripada nod but ke nod penyambung. Jika operasi ditamatkan secara tiba-tiba di pertengahan jalan, nod penyambung mungkin mempunyai data separa atau tiada lagi. Isu ini boleh dibetulkan dengan melaksanakan semula operasi klon jauh yang Replikasi Kumpulan secara automatik lakukan.
Ini terutamanya untuk kes di mana laluan penjimatan data ditentukan menggunakan sub-pilihan DATADIRECTORY semasa pengklonan jauh Apabila laluan ditentukan, data akan disimpan dalam direktori yang ditentukan, iaitu data selepas pengklonan tidak berkaitan dengan contoh yang diklonkan, anda perlu memulakan secara manual dan menentukan datadir ke direktori tempat data klon disimpan Sudah tentu, pemalam MGR boleh melakukan operasi cuba semula alat kawalan jauh secara automatik klon (anda perlu memastikan bahawa operasi klon tidak menyatakan sub-pilihan DATA DIRECTORY. Dalam kes ini, klon jauh Data akan menimpa data pelayan yang mengendalikan klon jauh. Selepas operasi pengklonan jauh selesai, pelayan yang mengendalikan klon jauh akan dimulakan semula secara automatik berdasarkan data klon). Di samping itu, walaupun pemalam pengklonan digunakan bersama dengan replikasi kumpulan untuk menjadikan pengurusan dan penyelenggaraan replikasi kumpulan lebih automatik, pemalam pengklonan tidak memerlukannya untuk dijalankan dalam kelompok (tetapi pemalam MGR mesti dipasang).
Untuk replikasi kumpulan, anda perlu memberi perhatian kepada perkara dan perbezaan berikut apabila menggunakan pemalam klon untuk pemulihan yang diedarkan:
Nod kluster sedia ada dan nod yang bergabung mesti memasang pemalam klon dan aktif.
Nod but dan nod penyambung mesti berjalan pada sistem pengendalian yang sama dan mesti mempunyai versi Pelayan MySQL yang sama (Mestilah MySQL 8.0.17 atau lebih tinggi untuk menyokong pemalam klon). Oleh itu, pengklonan tidak berfungsi untuk kluster yang ahlinya menjalankan versi MySQL yang berbeza.
Nod but dan nod cantuman mesti mempunyai pemalam "Replikasi Kumpulan" yang dipasang dan diaktifkan, dan mana-mana pemalam lain yang diaktifkan pada nod but (cth. pemalam keyring) juga mesti aktif pada nod penyambung.
Jika pemulihan teragih dikonfigurasikan untuk menggunakan SSL (groupreplicationrecoveryusessl=ON), Replikasi Kumpulan menggunakan tetapan ini pada operasi klon jauh. Replikasi Kumpulan secara automatik mengkonfigurasi tetapan pilihan SSL klon (clonesslca, clonesslcert dan clonesslkey) untuk memadankan tetapan pilihan pemulihan yang diedarkan Replikasi Kumpulan yang sepadan (groupreplicationrecoverysslca, groupreplicationrecoverysslcert dan groupreplicationrecoverysslkey).
Tidak perlu menetapkan senarai nod but yang sah dalam pembolehubah sistem clonevaliddonor_list pada nod gabungan untuk menyertai kluster. Replikasi Kumpulan secara automatik mengkonfigurasi tetapan ini selepas MGR secara automatik memilih nod but daripada nod kluster sedia ada. Ambil perhatian bahawa operasi pengklonan jauh menggunakan nama dan port hos protokol SQL pelayan, bukan alamat dan port untuk komunikasi dalaman antara ahli kluster.
Pemalam pengklonan mempunyai beberapa pembolehubah sistem untuk mengurus beban rangkaian dan kesan prestasi operasi pengklonan jauh. Tetapan ini tidak dikonfigurasikan dengan Replikasi Kumpulan, jadi anda boleh melihatnya dan menetapkannya jika perlu, atau anda boleh menetapkannya sebagai lalai Apabila menggunakan operasi klon jauh untuk pemulihan teragih, tetapan klon boleh dimampatkan pemalam klon akan digunakan pada. sebaliknya memberi kesan kepada tetapan mampatan Replikasi Kumpulan yang sedia ada.
Untuk menggunakan operasi klon jauh pada nod pencantuman, Replikasi Kumpulan menggunakan pengguna mysql.session dalaman, yang sudah mempunyai keistimewaan CLONE_ADMIN, jadi tiada persediaan khas diperlukan.
Sebagai pengguna klon pada nod but untuk operasi klon jauh, Replikasi Kumpulan menggunakan pengguna replikasi yang disediakan untuk pemulihan yang diedarkan. Oleh itu, pengguna replikasi ini mesti diberi keistimewaan BACKUP_ADMIN pada semua nod kluster berkeupayaan pengklonan. Apabila mengkonfigurasi nod untuk replikasi kumpulan, jika terdapat nod cantuman, anda juga harus memberikan kebenaran ini kepada pengguna replikasi pada nod itu kerana selepas nod cantuman itu menyertai kluster, mereka boleh bertindak sebagai nod but untuk nod cantuman yang lain. Pengguna replikasi yang sama digunakan untuk pemulihan yang diedarkan pada setiap nod kluster. Untuk memberikan kebenaran ini kepada pengguna replikasi pada nod sedia ada, laksanakan pernyataan ini secara individu pada setiap nod kelompok dengan pengelogan binari dilumpuhkan atau pada nod utama kelompok dengan pengelogan binari didayakan Ayat berikut:
GRANT BACKUP_ADMIN ON *.* TO *rpl_user*@'%';
Jika anda menggunakan CHANGE MASTER TO untuk menentukan kelayakan pengguna replikasi pada pelayan yang memberikan bukti kelayakan pengguna sebelum menggunakan STARTGROUPREPLICATION, pastikan anda memadamkan bukti kelayakan pengguna daripada repositori metadata replikasi sebelum melakukan sebarang operasi pengklonan jauh. Juga pastikan groupreplicationstartonboot=OFF ditetapkan pada ahli yang menyertai. Jika kelayakan pengguna tidak dinyahset, ia dipindahkan kepada ahli yang menyertai semasa operasi klon jauh. Saluran GroupReplicationRecovery kemudiannya boleh dimulakan secara tidak sengaja menggunakan bukti kelayakan yang disimpan pada ahli asal atau ahli yang diklon daripadanya. Memulakan Replikasi Kumpulan secara automatik apabila pelayan bermula (termasuk selepas operasi klon jauh) akan menggunakan bukti kelayakan pengguna yang disimpan, dan juga akan menggunakan bukti kelayakan pemulihan yang diedarkan jika ia tidak dinyatakan pada perintah START GROUPREPLICATION.
Selepas menetapkan ahli kumpulan untuk menyokong pengklonan, pembolehubah sistem ambang pengklonan kumpulan akan menentukan ambang, dinyatakan sebagai bilangan transaksi, untuk menggunakan operasi pengklonan jauh dalam pemulihan yang diedarkan. Jika bilangan urus niaga antara nod bootstrap dan nod sambung lebih besar daripada nombor ini, operasi klon jauh akan digunakan untuk memindahkan keadaan ke nod sambung apabila boleh dilaksanakan secara teknikal. Replikasi Kumpulan mengira sama ada ambang telah melebihi berdasarkan set gtidexecuted ahli kumpulan sedia ada. Menggunakan operasi klon jauh apabila jurang transaksi adalah besar, ahli baharu boleh ditambah pada kluster tanpa perlu memindahkan data kluster secara manual ke pelayan terlebih dahulu, dan ia juga boleh mendayakan nod ketinggalan untuk mengejar data dengan lebih cekap.
Tetapan lalai pembolehubah sistem replikasi kumpulan groupreplicationclone_threshold adalah sangat tinggi (bilangan jujukan maksimum yang dibenarkan bagi transaksi dalam GTID), jadi ia secara berkesan melumpuhkan pengklonan apabila mungkin untuk memindahkan keadaan daripada log binari. Untuk membolehkan Replikasi Kumpulan memilih operasi klon jauh yang lebih sesuai untuk pemindahan keadaan, tetapkan pembolehubah sistem yang menentukan bilangan urus niaga yang harus digunakan sebagai selang urus niaga untuk pengklonan.
PS:
Jangan gunakan tetapan yang lebih rendah untuk groupreplicationclone_threshold dalam kelompok aktif. Jika lebih daripada transaksi ambang berlaku dalam kluster semasa operasi klon jauh sedang dijalankan, ahli yang menyertai akan mencetuskan operasi klon jauh sekali lagi selepas dimulakan semula dan boleh diteruskan selama-lamanya. Untuk mengelakkan perkara ini, pastikan anda menetapkan ambang kepada nombor yang boleh dipercayai yang lebih besar daripada bilangan urus niaga yang dijangka berlaku dalam kelompok dalam tempoh masa yang diambil oleh operasi klon jauh.
Apabila pemindahan keadaan daripada log binari nod but tidak boleh dilakukan, Replikasi Kumpulan cuba melakukan operasi klon jauh tanpa mengira ambang pada masa itu, contohnya, kerana transaksi yang diperlukan untuk menyertai ahli tidak tersedia pada mana-mana ahli kumpulan sedia ada tidak tersedia dalam log binari. Replikasi kumpulan mengenal pasti ini berdasarkan set gtidpurged ahli kumpulan sedia ada. Pembolehubah sistem groupreplicationclonethreshold tidak boleh digunakan untuk menyahaktifkan pengklonan apabila urus niaga yang diperlukan tidak tersedia dalam fail log perduaan mana-mana ahli, kerana dalam kes ini pengklonan adalah satu-satunya pilihan untuk memindahkan data secara manual ke nod penggabungan
Selepas menyediakan nod kluster dan menyertai nod untuk pengklonan, Replikasi Kumpulan akan menguruskan operasi pengklonan jauh. Operasi klon jauh mengambil sedikit masa untuk diselesaikan, bergantung pada saiz data.
Jadual performanceschema.cloneprogress merekodkan setiap peringkat keseluruhan operasi pengklonan dan maklumat peringkatnya yang sepadan Setiap peringkat akan menjana satu baris rekod (perhatikan bahawa hanya satu maklumat proses operasi pengklonan direkodkan dalam jadual ini. seperti berikut) Apabila melakukan operasi klon, maklumat terakhir akan ditimpa)
select * from clone_progress; +------+-----------+-----------+---------------------------- +----------------------------+---------+------------+-------- ----+------------+------------+---------------+ | ID | STAGE | STATE | BEGIN_TIME | END_TIME | THREADS | ESTIMATE | DATA | NETWORK | DATA_SPEED | NETWORK_SPEED | +------+-----------+-----------+---------------------------- +----------------------------+---------+------------+------- -----+------------+------------+---------------+ | 1 | DROP DATA | Completed | 2019-10-08 16:46:58.757964 | 2019-10-08 16:46:59.128436 | 1 | 0 | 0 | 0 | 0 | 0 | | 1 | FILE COPY | Completed | 2019-10-08 16:46:59.128766 | 2019-10-08 16:47:16.857536 | 8 | 8429731840 | 8429731840 | 8430190882 | 0 | 0 | | 1 | PAGE COPY | Completed | 2019-10-08 16:47:16.857737 | 2019-10-08 16:47:17.159531 | 8 | 0 | 0 | 785 | 0 | 0 | | 1 | REDO COPY | Completed | 2019-10-08 16:47:17.159748 | 2019-10-08 16:47:17.460516 | 8 | 2560 | 2560 | 3717 | 0 | 0 | | 1 | FILE SYNC | Completed | 2019-10-08 16:47:17.460788 | 2019-10-08 16:47:20.926184 | 8 | 0 | 0 | 0 | 0 | 0 | | 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 |
| 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 | 2019-10-08 16:47:28.623732 | 0 | 0 | 0 | 0 | 0 | 0 | | 1 | RECOVERY | Completed | 2019-10-08 16:47:28.623732 | 2019-10-08 16:47:34.898453 | 0 | 0 | 0 | 0 | 0 | 0 | +------+-----------+-----------+---------------------------- +----------------------------+---------+------------+------- -----+------------+------------+---------------+ 7 rows in set (0.00 sec) select * from clone_status\G *************************** 1. row *************************** ID: 1 PID: 0 STATE: Completed BEGIN_TIME: 2019-10-08 16:46:58.758 END_TIME: 2019-10-08 16:47:34.898 SOURCE: 10.10.30.162:3306 DESTINATION: LOCAL INSTANCE ERROR_NO: 0 ERROR_MESSAGE: BINLOG_FILE: mysql-bin.000022 BINLOG_POSITION: 222104704 GTID_EXECUTED: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4, aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494 1 row in set (0.01 sec)
PS:
Selepas pemindahan negeri selesai, kumpulan replikasi akan dimulakan semula Sertai nod untuk menyelesaikan proses. Jika groupreplicationstartonboot=OFF ditetapkan pada nod penyambungan, contohnya kerana bukti kelayakan pengguna replikasi ditentukan pada pernyataan START GROUPREPLICATION, START GROUPREPLICATION mesti diterbitkan secara manual sekali lagi selepas dimulakan semula. Jika groupreplicationstartonboot=ON dan tetapan lain yang diperlukan untuk memulakan replikasi kumpulan ditetapkan dalam fail konfigurasi atau menggunakan pernyataan SET PERSIST, proses akan diteruskan secara automatik dengan nod penyambungan dalam talian tanpa campur tangan.
Operasi pengklonan jauh akan mengklon pelbagai fail data dalam direktori data nod but kepada nod penyambung (jadual mungkin mengandungi beberapa maklumat konfigurasi dan data pengguna, dsb.). Walau bagaimanapun, tetapan keahlian Replikasi Kumpulan yang disimpan dalam fail konfigurasi (seperti konfigurasi alamat setempat Replikasi Kumpulan, dsb.) tidak akan diklonkan dan sebarang perubahan tidak akan dibuat pada nod gabungan. Iaitu, konfigurasi yang berkaitan dengan replikasi kumpulan perlu dikonfigurasikan sendiri dan tidak boleh bercanggah dengan ahli sedia ada dalam kelompok Operasi pengklonan jauh hanya bertanggungjawab untuk pengklonan fail data dan tidak akan mengklon maklumat konfigurasi (sudah tentu, jika beberapa maklumat konfigurasi disimpan dalam jadual, untuk Untuk operasi pengklonan, ia juga akan diklonkan sebagai data).
如果远程克隆过程花费很长时间，则在MySQL 8.0.22之前的发行版中，在该时间段内为该集群累积的一组认证信息可能会变得太大而无法传输给加入成员。在这种情况下，加入成员会记录一条错误消息，并且不会加入该集群。从MySQL 8.0.22开始，组复制以不同的方式管理应用事务的垃圾收集过程，以避免发生这种情况。在早期版本中，如果确实看到此错误，则在远程克隆操作完成之后，请等待两分钟，以允许进行一轮垃圾收集，以减小集群的认证信息的大小。然后在加入成员上发出以下声明，以使其停止尝试应用先前的认证信息集：
RESET SLAVE FORCHANNEL group_replication_recovery; RESET REPLICA FOR CHANNEL group_replication_recovery;（从8.0.22开始）
引导节点中用于组复制专用通道groupreplicationrecovery的用户凭证（复制用户和密码），在克隆操作完成之后，会被新成员使用，所以，该用户和密码及其权限必须在新成员中也有效。因此，所有组成员才能够使用相同的复制用户和密码通过远程克隆操作接收状态传输进行分布式恢复。但是，组复制会保留与使用SSL相关的组复制通道设置，这些设置对单个成员来说可以是惟一的（即，每个组成员使用不同的复制用户和密码）。如果使用了PRIVILEGECHECKSUSER帐户来帮助保护复制应用线程（从MySQL8.0.18开始，可以创建一个具有特定权限的用户账号，然后将其指定为PRIVILEGECHECKSUSER帐户，这样可以防止将未经授权或意外将具有特权的账号用于组复制通道），则在克隆操作完成之后新加入成员不会使用该用户帐户作为组复制通道的用户。此时必须为组复制通道手工指定合适的复制用户。
如果引导节点用于groupreplicationrecovery复制通道的复制用户凭据已使用CHANGE MASTER TO语句存储在复制元数据存储库中，则在克隆后将它们转移到加入成员并由其使用，并且它们在此处必须有效。因此，使用存储的凭据，所有通过远程克隆操作接收状态转移的组成员都会自动接收复制用户和密码，进行分布式恢复。如果在START GROUPREPLICATION语句上指定了复制用户凭据，则这些凭据将用于启动远程克隆操作，但是在克隆后它们不会传输到加入节点并由其使用。如果不希望将凭据转移到新的server上并记录在那里，确保在进行远程克隆操作之前取消设置它们，并使用START GROUPREPLICATION代替提供它们。
ps:如果已使用PRIVILEGECHECKSUSER帐户来帮助保护复制应用程序，则从MySQL 8.0.19开始，会将PRIVILEGECHECKSUSER帐户以及来自引导节点的相关设置克隆出来。如果将加入节点设置为在启动时启动组复制，它将自动使用该帐户在相应的复制通道上进行权限检查。（在MySQL 8.0.18中，由于许多限制，建议不要将PRIVILEGECHECKSUSER帐户用于组复制通道。）
组复制启动并管理用于分布式恢复的克隆操作。设置为支持克隆的组成员也可以参与用户手动启动的克隆操作。例如，可能希望通过从组成员作为引导节点来进行克隆来创建新的MySQL实例，但是不希望新的服务器实例立即加入或可能永远不会加入该集群。
在所有支持克隆的发行版中，可以手动启动涉及停止了组复制的组成员的克隆操作。由于克隆要求引导节点和接收数据的节点上的克隆插件必须匹配，因此即使不希望该实例加入集群，也必须在另一个实例上安装并激活组复制插件。可以通过发出以下语句来安装插件：
INSTALL PLUGIN group_replication SONAME'group_replication.so';
在MySQL 8.0.20之前的发行版中，如果操作涉及正在运行“组复制”的组成员，则无法手动启动克隆操作。从MySQL8.0.20开始，只要克隆操作不会删除和替换接收者上的数据，就可以执行此操作。因此，如果正在运行组复制，则用于启动克隆操作的语句必须包含DATA DIRECTORY子句。
Atas ialah kandungan terperinci Analisis contoh pemulihan yang diedarkan MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
