Plan de migration des données historiques
1. Exigences du scénario
Une fois que le cryptage en ligne couvre tous les utilisateurs, la prochaine étape importante consiste à crypter toutes les données historiques.
Nous avons résumé le plan de migration RDS et les données de performances sur la base des données de tests de résistance internes et de l'expérience de cas à titre de référence.
2 Project Introduction
2.1 Data Migration, préparation:
1) Veuillez confirmer que la logique de code est compatible avec le texte brut et le texte chiffré.
2) Confirmez que le commutateur de cryptage est activé.
3) Confirmez que les nouvelles données entrantes de RDS et TOP api sont déjà cryptées.
2.2Plan de migration des données recommandé
Migrez après avoir confirmé que la logique de tolérance aux pannes a été complétée. Après avoir effectué un petit nombre de tests de migration client, vous pouvez ensuite effectuer un test de migration complet.
1) Premier test de migration des données d'un seul client :
Profitez de l'opportunité de migrer un client pour tester le plan de migration. Montant de migration recommandé <1 million. Vous pouvez commencer avec un nombre de concurrence inférieur. Par exemple : 5 à 10 threads simultanément. (Vous pouvez choisir en fonction des données du test de résistance ci-dessus)
Enregistrez les performances habituelles à l'avance ;
Enregistrez la période de migration Enregistrez ensuite le temps de migration, IOPS/connexion/CPU/TPS/QPS pendant le processus de migration, etc. Comparez avec les performances habituelles.
2) Plan de migration
En fonction de la vitesse de migration précédemment calculée, calculez le temps et le plan de migration.
Déterminez d'abord la granularité minimale de la migration : par exemple, un éditeur indépendant qui se déploie de manière indépendante peut déterminer une granularité minimale pour un déploiement. Tenir compte de l'indépendance des fonctions et de la durée totale de la migration (la contrôler dans les 3 heures).
Le premier jour de migration, continuez à enregistrer le volume de données, l'heure...etc.
Si le processus de migration se déroule sans problème et que la charge de performances est supportable, vous pouvez augmenter progressivement le nombre de threads plus tard.
Après cela, vous pouvez augmenter progressivement le nombre de threads et le nombre de migrations simultanées en fonction du premier jour. Faites attention à la surveillance continue des performances de la base de données. jusqu'à ce que la migration soit terminée.
3) Remarque sur la logique du code :
• Remarque : la clé ne peut être récupérée que si la session utilisateur est valide ou n'expire pas plus de 90 jours et que le statut d'utilisateur n'a pas expiré.
Pendant le processus de migration, Veuillez exclure les utilisateurs qui ont expiré depuis plus de 90jours et qui ne sont pas valides (c'est-à-dire : gelés, effacés, etc.).
Sinon, cela entraînera un grand nombre d'échecs de demandes de clés et le cryptage échouera.
• Lorsque vous extrayez les données utilisateur de la base de données et les chiffrez, veuillez faire attention au contrôle de la taille de la pagination.
2.3 Migration des données, référence des données clés :
Objectif : Recommander un plan de migration des données approprié de l'ISV en fonction de la taille de la base de données, de l'architecture de la base de données et des applications et des performances de la base de données sélectionnée.
Informations et données :
Performances de la base de données push RDS : http://cloud.tmall.com/rdsSelection.htm
L'image ci-dessus est la configuration de la base de données liste. Pour notre test de résistance interne, nous avons sélectionné les quatre configurations RDS dans la zone rouge pour les tester. Voir la section suivante pour les résultats des tests.
Résultats du test de stress :
1) Test de stress de la base de données moyenne (IOPS = 1200) : 4 machines ont été utilisées, trois tests ont été effectués, 10 et 15 ont été activés respectivement et 25 threads , migrant 2 millions de données, le temps de migration et les performances pendant le processus de migration sont les suivants :
Durée de migration des données :
Nombre de machines | Nombre | Quantité de données | Heure | |
Test 1 | 4 | 10 | 200 w | 31min |
| Test 2 | 4 | 15 | 200w | 19 min |
Test 3 | 4 | 25 | 200w | 13 min |
Performances de migration :
Nombre de machines | Nombre de fils | IOPS | Connexions actives | CPUPeak | Transactions moyennes par seconde (TPS) ( Pic) | Chaque SQLnombre de secondes (QPS) (Pic) | |
Test 1 | 4 | 10 | 27 | 20 | 12% | 3000 | 4500 |
| Test 2 | 4 | 15 | 40 | 45 | 20% | 5500 | 7500 |
Test 3 | 4 | 25 | 40 | 75 | 32% | 7500 | 10000 |
2) Test de stress de grande base de données (IOPS = 3000) : 4 machines ont été utilisées, trois tests ont été effectués, 10, 15 et 25 threads ont été activés respectivement, 2 millions de données ont été migrées, le temps de migration et le temps de migration Le les performances au cours du processus sont les suivantes :
Durée de migration des données :
| nombre de machines | Nombre de fils | Montant des données | Heure | ||||||||||||||||||||||||||||
Test 1 | 4 | 10 | 200w | 31 minutes 200w | ||||||||||||||||||||||||||||
| 19 min | Test 3 | 4 | 25 | 200w | ||||||||||||||||||||||||||||
| 13 min Performances de migration :
Remarque : La consommation de performances IOPS de la base de données est faible car la base de données elle-même contient une logique de mise en mémoire tampon du cache. Par conséquent, il n'y a pas beaucoup de différence dans le temps de migration final des bases de données avec des performances IOPS différentes. FAQ
|
