Penghijrahan pangkalan data yang lancar: Menggunakan perkhidmatan migrasi pangkalan data GCP untuk melancarkan awan MySQL
Dalam evolusi struktur syarikat Internet, tugas yang paling mendebarkan dan berjalan di atas ais nipis pastinya bukan "penghijrahan pangkalan data".
Penghijrahan pangkalan data tradisional seperti menukar tayar untuk kereta Cyclonus di lebuh raya. Untuk memastikan konsistensi data, pendekatan lama biasanya memilih untuk menutup pengumuman penutupan pada pukul tiga pagi, memotong semua lalu lintas depan, dan kemudian menggunakan
mysqldump
Eksport fail SQL besar dengan puluhan GB, dan kemudian perlahan-lahan memindahkan dan mengimportnya ke awan. Hasilnya sering kali disebabkan oleh gangguan rangkaian atau kelajuan import yang perlahan, yang menyebabkan pengaliran tidak selesai pada waktu subuh. Pada akhirnya, semua pekerja terpaksa terpaksa kembali di bawah tekanan tinggi, yang tidak hanya menyebabkan pasukan R & D kehilangan rambutnya, tetapi juga mempengaruhi syarikat secara serius Perniagaan teras.
Dalam ekologi moden Google Cloud(GCP, Google Cloud), terdapat artifak pengurangan dimensi yang direka untuk memecahkan kebuntuan ini, yang disebut
Perkhidmatan Migrasi Pangkalan Data (Perkhidmatan Migrasi Pangkalan Data, DMS)
。
Logik terasnya sangat murni:
Hosting penuh, penutupan sifar, penyegerakan masa nyata yang lancar
。 Dengan menggabungkan teknologi replikasi Binlog asli MySQL, DMS dapat membuka pintu untuk mengambil pelanggan seperti biasa dalam perniagaan dalam talian, dan pada masa yang sama terus memindahkan data pangkalan data lama ke awan seperti air mengalir di latar belakang. Setelah data di kedua-dua belah pihak diselaraskan sepenuhnya, anda hanya perlu memilih petang yang tenang dan menghabiskan beberapa saat untuk menukar rentetan sambungan hujung depan dengan ringan untuk menyelesaikan "awan lancar" peringkat kilang besar.
Hari ini kita tidak membincangkan formula kriptografi yang rumit, dan menolak omong kosong. Langsung dari pertempuran sebenar tegar, bawa anda dari MySQL buatan sendiri tempatan ke Google Cloud
Cloud SQL untuk MySQL
Latihan penghijrahan yang lancar.
Tahap pertama: pembongkaran mendalam, "model dunia fizikal dua peringkat" migrasi masa nyata DMS
Sebelum pergi ke konsol untuk mengklik tetikus, anda mesti membuat model operasi fizikal yang mendasari DMS dalam fikiran anda, jika tidak, anda pasti akan terpegun dengan rangkaian dan konfigurasi kebenaran yang kompleks.
Penghijrahan masa nyata kenaikan penuh DMS pada dasarnya adalah pembinaan saluran penghantaran data yang sangat tersedia di bahagian bawah intranet Google. Keseluruhan kitaran hidup terbahagi kepada dua peringkat teras:
Tahap pertama: Permulaan pasaran inventori (Full Dump): Apabila anda memulakan tugas migrasi, DMS akan mengemas dan mengklon semua struktur jadual dan data inventori semasa perpustakaan sumber tanpa mempengaruhi pembacaan dan penulisan normal perpustakaan sumber. Salinan dengan cepat dihantar ke perpustakaan sasaran Cloud SQL di awan.
Tahap kedua: penangkapan aliran tambahan (replikasi CDC/Binlog): DMS akan beralih ke mod tangkapan data berterusan (CDC) dengan lancar apabila stok dipindahkan. Ia akan berubah menjadi MySQL Slave standard (perpustakaan hamba), menatap Binlog (log binari) perpustakaan sumber. Selagi pengguna dalam talian membuat pesanan baru dan menukar kata laluan, DMS akan meletakkannya dalam milisaat
Pengubahsuaian tambahan "menangkap" dan memainkannya semula di perpustakaan sasaran awan.
Kesimpulan seni bina teras: Dalam dua tahap ini, pangkalan data lama anda akan terus beroperasi sepanjang keseluruhan proses, tanpa henti walaupun sesaat. Perpustakaan awan baru seperti bayangan perpustakaan lama, dan ia mengikuti langkah yang sama sehingga perbezaan waktu antara kedua-dua belah pihak (Hukum Pelaporan) menjadi sifar.
Tahap kedua: menjelang pertempuran sebenar-menarik "pas" di pangkalan data sumber yang dibina sendiri
Agar DMS masuk dan memindahkan batu bata secara sah, kita mesti kembali ke kampung halaman kita (perpustakaan sumber MySQL buatan tempatan) untuk membuat beberapa konfigurasi yang mendasari.
1. Buka log Binlog (suntikan jiwa salinan masa nyata)
Buka perpustakaan sumber anda
my.cnf
Atau
My. ini
Fail konfigurasi, pastikan baris berikut tidak diberi komen, dan parameternya betul:
Ini, TOML
[Mysqld]
Log-bin = mysql-bin
Binlog_format = ROW # mestilah dalam format ROW, DMS bergantung pada ini untuk mengenal pasti perubahan setiap baris data dengan tepat
Pelayan-id = 100001 # Tentukan ID identiti kluster unik ke perpustakaan sumber
Expire_logs_days = 7 # Binlog disimpan sekurang-kurangnya 7 hari untuk mengelakkan DMS dihapuskan secara automatik oleh sistem sebelum dapat dibaca
Selepas perubahan, ingatlah untuk memulakan semula MySQL yang dibina sendiri untuk menjadikan konfigurasi berkesan.
2. Buat akaun "penyambung" eksklusif DMS
Sambungkan ke perpustakaan sumber, ketik arahan SQL berikut yang diatur oleh pengeluar utama untuk membuat akaun selamat dengan kebenaran salinan eksklusif untuk GCP DMS:
SQL
-- Buat akaun yang disebut gcp_dms, yang membolehkannya menyambung dari mana-mana tempat (atau menentukan segmen intranet GCP)
CREATE USER 'gcp _ dms' @ '%' IDENTIFIED BY 'YourHardPassword123! ';
-- Berikan kebenaran membaca data asas dan penyalinan kluster (prinsip kebenaran minimum untuk pengeluar utama)
GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'gcp _ dms' @ '% ';
-- Refresh kebenaran untuk menjadikan kod rahsia berkesan serta merta
FLUSH PRIVILEGES;
Tahap ketiga: latihan praktikal-konfigurasi langsung barisan pemasangan migrasi DMS
Persekitaran sudah siap, kami log masuk
Konsol GCP
, cari dan masuk
Pangkalan Data Migration (Penghijrahan pangkalan data)
Halaman.
Langkah 1: Mewujudkan Pekerjaan Migrasi (Migration Job)
Klik "Buat Kerja Migrasi" di bahagian atas:
Nama kerja: mysql-to-cloudsql-prod.
Enjin Pangkalan Data Sumber: Pilih MySQL.
Enjin Pangkalan Data Sasaran: Pilih Cloud SQL untuk MySQL.
Jenis penghijrahan: Jangan teragak-agak untuk memilih "Continuous". Catatan: Hanya dengan memilih Continuous adalah migrasi yang lancar dan lancar dengan penyegerakan tambahan; jika anda memilih One-time (satu kali), data akan berhenti secara tiba-tiba setelah pemindahan, dan tidak ada penutupan sifar.
Langkah 2: Tentukan Profil Sambungan Sumber (Profil Sambungan Sumber)
Di sini, kami ingin memberitahu Google mengenai parameter fasa kedua di kampung halaman kami:
Nama profil jenis sambungan: sumber-lokal-mysql.
Nama hos/IP dan port: Isi IP rangkaian awam MySQL tempatan anda atau IP intranet khusus, port lalai ke 3306.
Nama pengguna dan kata laluan: Isi gcp_dms dan kata laluan yang baru dibina dengan tepat.
Langkah 3: Tentukan Perpustakaan Sasaran Awan (Destination)
Di mana anda memindahkan data anda? DMS menyediakan fungsi yang sangat tidak terkalahkan di sini --
Satu klik di latar belakang untuk membantu anda membuat perpustakaan sasaran Cloud SQL baru secara langsung
。
Masukkan ID contoh pangkalan data awan yang ingin anda buat (seperti cloudsql-mysql-prod).
Pilih versi MySQL (disyorkan untuk selaras dengan perpustakaan sumber, seperti 8.0).
Pilih wilayah (seperti asia-east1 Taiwan).
Tetapkan kata laluan yang kuat untuk akaun root awan, dan pilih spesifikasi mesin (seperti memori 4GB 2 teras, ingat untuk memeriksa "ketersediaan tinggi dan pertahanan tinggi" di persekitaran pengeluaran untuk membolehkan pemulihan bencana berganda di seluruh kawasan yang boleh digunakan).
Langkah 4: Kaedah Sambungan-Memotong Perisik Peretas
Ini adalah tempat paling mudah untuk memijak lubang. Bagaimana DMS Google Cloud melalui firewall untuk menyambung ke mesin tempatan anda? DMS menyediakan tiga kaedah sambungan standard:
Penyelesaian cadangan lanjutan: Reverse SSH Tunnel (Reverse SSH Tunnel):DMS akan menghasilkan mesin maya VMM perantaraan yang sangat ringan di latar belakang dan memberi anda serangkaian perintah SSH. Anda hanya perlu menjalankan siri arahan ini di pelayan tempatan untuk menarik terowong sehala rahsia yang disulitkan sepenuhnya dan menembusi firewall antara intranet tempatan dan GCP. Anda tidak perlu membuka 3306 port ke dunia di firewall syarikat, dan faktor keselamatan langsung penuh.
Alternatif: Senarai dibenarkan IP: Letakkan alamat IP rangkaian awam rasmi yang meminta GCP DMS anda dan kunci ke dalam senarai putih firewall perkakasan paling luar di ruang komputer tempatan anda.
Setelah lulus ujian penyambungan, klik di bahagian bawah
"Buat dan mulakan kerja rumah (Buat &
Amp; Start Job)"
。
Tahap keempat: momen menyaksikan pengejaran masa nyata dalam talian keajaiban dan pemotongan arus utama semuanya berubah
Setelah mengklik untuk memulakan, daya pengkomputeran DMS yang diedarkan secara fleksibel akan segera terbangun. Kembali ke senarai pekerjaan migrasi, anda akan melihat bar status untuk menyaksikan evolusi kitaran hayatnya yang ajaib:
Status berubah dari Penciptaan ke Permulaan, dan kemudian memasuki Program Penuh (ini bermaksud bahawa ia sangat membawa data lama yang telah anda miliki dalam beberapa tahun terakhir).
Setelah stok dipindahkan, status akan menjadi CDC hijau dalam proses (terus menyalin).
Pada ketika ini, pergi ke konsol untuk melihat
"Kelewatan Replikasi (Replication Lag)"
Penunjuk. Pada mulanya, kerana perubahan baru yang dihasilkan semasa pengendalian stok, penundaan mungkin beberapa minit; tetapi tidak lama lagi, kerana lebar jalur intranet Google yang kuat penuh dengan kekuatan,
Replication Lag akan menjadi sifar sepenuhnya (0 second)
。
Ini bermaksud bahawa pada masa ini, setiap data di perpustakaan lama tempatan anda dan data di perpustakaan baru Google Cloud Cloud SQL telah mencapai
Penyegerakan masa nyata tahap piksel sepenuhnya
。
Kaedah lima langkah operasi "aliran pemotongan emas" standard peringkat kilang besar:
Apabila kelewatan stabil pada 0 saat, kita dapat memilih tempoh perniagaan yang rendah (misalnya, ketika akses pengguna paling sedikit pada pukul 4 petang), dan melakukan semua perubahan pada penutupan aliran terakhir. Seluruh proses hanya mengambil masa 10 saat:
Bahagian depan menggantung hanya baca sementara: jalankan SET GLOBAL read_only = 1 di latar belakang aplikasi web anda, atau di perpustakaan sumber MySQL; untuk memaksa perpustakaan lama menjadi "hanya baca". Tindakan ini digunakan untuk memastikan bahawa dalam beberapa saat pertukaran, tidak akan ada pesanan baru yang dapat ditulis secara rahsia ke dalam perpustakaan lama, yang akan menyebabkan data di kedua-dua belah pihak terputus.
Tunggu akhir untuk memeriksa jurang dan menebus kebocoran: menatap konsol DMS dan tunggu selama 5 saat, sehingga ekor Binlog terakhir yang dihantar sepenuhnya dimainkan semula di awan untuk memastikan bahawa data di kedua-dua belah pihak tidak buruk dalam satu tempoh.
Klik butang besar "Promote": Pada konsol GCP DMS, klik "Promote" dengan tegas di bahagian atas. Kisah dalam yang mendasari: Tindakan ini akan segera memutuskan hubungan replikasi hamba antara perpustakaan baru awan dan perpustakaan lama. Perpustakaan sasaran Cloud SQL akan melepaskan diri dari identiti perpustakaan dalam sekelip mata, dan berkembang menjadi perpustakaan utama (Master) yang benar-benar bebas, boleh dibaca dan ditulis.
Ganti rentetan sambungan: Sambungkan pangkalan data dalam semua aplikasi web dan konfigurasi perkhidmatan mikro di bahagian belakang anda ke IP, dari IP perpustakaan lama yang dibina sendiri, dan arahkan ke IP awam/intranet Cloud SQL yang baru.
Mulakan semula aplikasi dan hidupkan semula sepenuhnya: Aplikasi front-end disambungkan semula ke perpustakaan awan baru untuk menghilangkan baca sahaja. Pesanan baru mula jatuh liar di Google Cloud dengan prestasi yang sangat tinggi.
Selesai dengan sempurna!
Selepas keseluruhan pertempuran, pelanggan hanya mengalami permintaan "tidak dapat membuat pesanan/melaporkan kesalahan" yang sangat kecil dan pendek antara langkah 1 dan 4. Laman web tidak pernah menutup pengumuman rumah hitam kecil secara keseluruhan, dan data hilang. Shangyun memperoleh kemenangan besar.
Tahap kelima: sejarah mengelakkan darah dan air mata di bawah struktur pangkalan data transnasional
Penyelesaian penghijrahan yang dikendalikan sepenuhnya ini sangat elegan. Tetapi untuk bertahan dalam persekitaran pengeluaran serentak tinggi peringkat perusahaan yang sebenar, sebagai ketua arkitek data, anda mesti menjaga dua lubang besar yang tidak kelihatan berikut yang berasal dari perbezaan perincian teknikal yang mendasari:
1. "Zon waktu dan set watak (Kerohanian) yang mematikan"
Setelah banyak pasukan berpindah, mereka mendapati bahawa kod lama yang telah berjalan dalam talian selama setengah tahun, setelah menyambung ke Cloud SQL, semua waktu Cina dan waktu tempatan hilang 8 jam. Atau beberapa komen pengguna yang mengandungi kata-kata yang jarang berlaku dan ungkapan Emoji secara langsung menjadi kacau atau melaporkan kesalahan.
Pembongkaran sebab: Zon waktu lalai MySQL yang dibina sendiri secara tempatan biasanya mengikuti hos (misalnya, ditetapkan sebagai CST zon waktu sistem), sementara GCP Cloud SQL lalai untuk pematuhan global, dan zon waktu utama yang mendasari dikunci secara paksa ke UTC waktu standard antarabangsa. Lalai set watak juga mungkin sedikit berbeza dengan perpustakaan lama anda.
Operasi penghindaran lubang standard pengeluar utama: Sebelum mengklik DMS untuk memulakan migrasi, pergi ke "Perubahan Konfigurasi" Cloud SQL, cari Bendera Pangkalan Data, dan tambahkan default_time_zone = '08: 00 '(atau zon waktu utama yang sesuai dengan perniagaan anda), dan secara paksa menyelaraskan set watak ke utf8mb4. Parameter yang mendasari tersekat di sumbernya adalah konsisten, yang merupakan undang-undang besi pertama untuk mengelakkan kesalahan kod dalam talian.
2. "Perangkap terbiar jam pasir" setelah penghijrahan DMS
Banyak pemula dengan senang hati pergi bekerja dan makan periuk panas setelah membuat peningkatan pangkalan data dan perniagaan yang sempurna di awan. Akibatnya, saya melihat rang undang-undang pada akhir bulan dan mendapati bahawa bayaran pekerjaan sumber DMS yang tidak dapat dijelaskan dan mahal telah dihasilkan.
Cadangan stop loss tegar: Apabila anda mengklik "Promote", operasi migrasi DMS belum dimusnahkan sepenuhnya secara fizikal. Ia masih menggunakan sumber pengkomputeran sementara dan antara muka rangkaian rangkaian di latar belakang awan, dan jam pasir masih beroperasi dengan liar..
Postur yang betul: Sahkan bahawa perpustakaan baru di awan berjalan lancar selama 24 jam. Setelah mengesahkan bahawa tidak perlu kembali, anda mesti segera kembali ke konsol DMS, pilih kerja migrasi yang telah selesai, dan klik "Delete" tanpa otak. Jangan risau, menghapus pekerjaan tidak akan memberi kesan sedikit pun pada pangkalan data Cloud SQL yang telah anda berkembang dengan jayanya. Hanya dengan cara ini pemotongan dapat dihentikan sepenuhnya.
Ringkasan
Dengan menggunakan Perkhidmatan Migrasi Pangkalan Data GCP untuk penghijrahan pangkalan data yang lancar, inti inti industri terletak pada enam belas perkataan:
Konfigurasikan kunci,
Terowong dibuka, Binlog mengejar, menaik taraf dan memotong
。
Anda mengucapkan selamat tinggal kepada eksport dan pengendalian manual gaya bengkel pada pukul tiga pagi. Semua komunikasi rangkaian, pembungkusan data pasaran, dan penyegerakan status masa nyata diserahkan kepada otak keselamatan terurus Google untuk mengklon. Mengelas aset pangkalan data teras dengan lancar dan halus pada asas pertahanan tinggi di awan adalah postur pelepasan arkitek yang paling elegan dan sahih di era awan moden.
