Pelan migrasi data sejarah
1. Keperluan senario
Selepas penyulitan dalam talian meliputi semua pengguna, langkah penting seterusnya ialah menyulitkan semua data sejarah.
Kami meringkaskan pelan migrasi RDS dan data prestasi berdasarkan data ujian tekanan dalaman dan pengalaman kes untuk rujukan.
2 Project PENGENALAN
2.1 Data Migrasi, Penyediaan:
1) Sila sahkan bahawa logik kod bersesuaian dengan Plaintext dan Ciphertext.
2) Sahkan bahawa suis penyulitan dihidupkan.
3) Sahkan bahawa data yang baru masuk daripada RDS dan api TOP sudah disulitkan.
2.2Pelan migrasi data yang disyorkan
Berhijrah selepas mengesahkan bahawa logik toleransi kesalahan telah selesai. Selepas menjalankan sebilangan kecil ujian migrasi pelanggan, anda kemudian boleh menjalankan ujian migrasi penuh.
1) Pertama, ujian migrasi data pelanggan tunggal:
Ambil peluang untuk berhijrah seorang pelanggan untuk menguji pelan migrasi. Jumlah penghijrahan yang disyorkan <1 juta. Anda boleh bermula dengan nombor konkurensi yang lebih rendah. Contohnya: 5-10 utas serentak. (Anda boleh memilih berdasarkan data ujian tekanan di atas)
Rakam prestasi biasa terlebih dahulu
Rakam tempoh migrasi Kemudian rekod masa migrasi, IOPS/sambungan/CPU/CPU/ semasa proses penghijrahan, dsb. Bandingkan dengan prestasi biasa.
2) Pelan migrasi
Berdasarkan kelajuan penghijrahan yang dikira sebelum ini, hitung masa dan rancangan penghijrahan.
Mula-mula tentukan kebutiran minimum penghijrahan: contohnya, ISV yang digunakan secara bebas boleh menentukan kebutiran minimum untuk satu penempatan. Mengambil kira kebebasan fungsi dan jumlah tempoh penghijrahan (kawal dalam masa 3 jam).
Pada hari pertama hijrah, teruskan rekod volum data, masa...dll.
Jika proses penghijrahan berjalan lancar dan beban prestasi boleh ditanggung, anda boleh menambah bilangan utas secara beransur-ansur kemudian.
Selepas itu, anda boleh menambah bilangan benang dan bilangan migrasi serentak secara beransur-ansur berdasarkan hari pertama. Beri perhatian kepada pemantauan berterusan prestasi pangkalan data. sehingga hijrah selesai.
3) Nota pada logik kod:
• Sila ambil perhatian: Kunci hanya boleh diambil jika Sesi pengguna sah, atau tamat tempoh tidak lebih daripada 90 hari, dan status pengguna belum tamat tempoh.
Semasa proses penghijrahan, Sila kecualikan pengguna yang telah tamat tempoh melebihi 90hari dan tidak sah (iaitu: beku, dibersihkan, dsb.)
Jika tidak, ia akan menyebabkan sejumlah besar permintaan kunci gagal dan penyulitan akan gagal.
• Apabila menarik data pengguna daripada pangkalan data dan menyulitkannya, sila beri perhatian untuk mengawal saiz halaman. .
Information and Data: rds Push Database Prestasi: http://cloud.tmall.com/rdsselection.htm
the gambar di atas adalah konfigurasi pangkalan data senarai. Untuk ujian tekanan dalaman kami, kami memilih empat konfigurasi RDS dalam kotak merah untuk ujian. Lihat bahagian seterusnya untuk keputusan ujian.
Keputusan ujian tekanan:
1) Pangkalan data sederhana (IOPS = 1200) ujian tekanan: 4 mesin telah digunakan, 10 ujian telah dijalankan dan masing-masing 15 ujian dayakan , memindahkan 2 juta data, masa migrasi dan prestasi semasa proses migrasi adalah seperti berikut:
Masa pemindahan data:
| Kiraan benang||||
Masa | Ujian 1 | 200 w | ||
| 31min
| Ujian 2 | 4 | 15 | |
| Ujian 3
| 4 | 25 | 200w |
Prestasi penghijrahan:
| Bilangan utas | IOPS
| Sambungan aktif CPU | Puncak | CPU Puncak | |||||||||||||||||||||||||||||||||||||||||||||||
| urus niaga setiap saat Puncak) | Setiap SQL bilangan saat (QPS) ( | Puncak) | Ujian 1 | 10 | 27 | |||||||||||||||||||||||||||||||||||||||||||||||
| 20 12% | 3000 |
| Ujian 2 | 4 | 15 | 7500 | ||||||||||||||||||||||||||||||||||||||||||||||
Ujian 3 . | 32% | 7500 | 10000 |
2) Ujian tekanan pangkalan data besar (IOPS = 3000): 4 mesin telah digunakan, tiga ujian telah dijalankan, masing-masing 10, 15 dan 25 benang didayakan, 2 juta data telah dipindahkan, masa migrasi dan masa migrasi prestasi semasa proses adalah seperti berikut:
Masa pemindahan data:
|
