ApsaraDB RDS:Migrer les données de sauvegarde incrémentielle (pour SQL Server 2008 R2 avec disques cloud et SQL Server 2012 ou version ultérieure)

Fonctionnement

Le processus se déroule en deux phases distinctes :

1. Migration des données complètes : sauvegardez la base source, téléchargez le fichier obtenu dans un compartiment OSS, puis restaurez-le sur l'instance RDS depuis la console ApsaraDB RDS.

2. Phase incrémentielle : répétez les opérations de sauvegarde et de téléchargement des journaux ou des sauvegardes différentielles afin de combler progressivement l'écart de données. Dès que la dernière sauvegarde de journal pèse moins de 500 Mo, interrompez les écritures sur la base source, transférez ce dernier fichier, puis ouvrez la base de destination.

Prérequis

Instance SQL Server autogérée :

• Le modèle de récupération doit être défini sur FULL. Le modèle SIMPLE ne prend pas en charge les sauvegardes du journal des transactions, indispensables pour une migration incrémentielle.

• Exécutez DBCC CHECKDB sur la base source et assurez-vous qu'aucune erreur d'allocation ou de cohérence n'est signalée :

  CHECKDB found 0 allocation errors and 0 consistency errors in database 'xxx'.
  DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Instance RDS :

• L'instance exécute SQL Server 2012 ou une version ultérieure, ou bien SQL Server 2008 R2 avec des disques cloud.

• Aucune base existante sur l'instance RDS ne doit porter le même nom que la base source, et aucun fichier de base détaché portant ce nom ne doit subsister. Un conflit de nommage entraînerait l'échec de la restauration.

• L'espace de stockage disponible doit être supérieur à la taille des fichiers de données à migrer. Si nécessaire, augmentez la capacité de stockage avant de commencer.

Authorization:

Le compte de service ApsaraDB RDS doit disposer d'un accès à votre compartiment OSS. Pour vérifier et accorder cette autorisation :

1. Sur la page Backup and Restoration de votre instance RDS, cliquez sur Migrate OSS Backup Data to RDS.

2. Dans l'assistant Import Guide, cliquez deux fois sur Next pour atteindre l'étape 3. Import Data.

3. Vérifiez le coin inférieur gauche de la page. Si le message You have authorized RDS official service account to access your OSS s'affiche, l'autorisation est effective. Sinon, cliquez sur le lien Authorization URL pour l'accorder.

Si vous utilisez un utilisateur Resource Access Management (RAM), les exigences supplémentaires suivantes s'appliquent :

• L'utilisateur RAM dispose des autorisations AliyunOSSFullAccess et AliyunRDSFullAccess. Consultez les rubriques Gérer les autorisations OSS avec RAM et Gérer les autorisations ApsaraDB RDS avec RAM.

• Votre compte Alibaba Cloud a créé une stratégie d'accès personnalisée et l'a attachée à l'utilisateur RAM :

  {
      "Version": "1",
      "Statement": [
          {
              "Action": [
                  "ram:GetRole"
              ],
              "Resource": "acs:ram:*:*:role/AliyunRDSImportRole",
              "Effect": "Allow"
          }
      ]
  }

Remarques d'utilisation

Exemple de chronologie de migration

L'exemple suivant montre comment réaliser la migration avec moins de cinq minutes d'interruption pour l'application.

Étape 1 : Sauvegarder la base de données source

1. Téléchargez le script de sauvegarde et ouvrez-le dans SQL Server Management Studio (SSMS).

2. Définissez les paramètres suivants :

   Paramètre	Description
   @backup_databases_list	Nom de la base de données source. Séparez plusieurs noms de bases par des points-virgules (;) ou des virgules (,).
   @backup_type	Type de sauvegarde : FULL (complète), DIFF (différentielle) ou LOG (journal).
   @backup_folder	Répertoire de l'instance autogérée où stocker les fichiers de sauvegarde. Le répertoire est créé automatiquement s'il n'existe pas.
   @is_run	1 pour effectuer la sauvegarde ; 0 pour exécuter uniquement une vérification.

3. Exécutez le script de sauvegarde. Un fichier .bak est généré, quel que soit le type de sauvegarde choisi.

Étape 2 : Télécharger les fichiers de sauvegarde vers OSS

Les fichiers de sauvegarde doivent résider dans un compartiment OSS situé dans la même région que votre instance RDS. Le transfert intra-région emprunte le réseau interne, ce qui évite les frais de sortie Internet et améliore la vitesse de téléchargement.

import com.aliyun.oss.*;
import com.aliyun.oss.common.auth.*;
import com.aliyun.oss.common.comm.SignVersion;
import com.aliyun.oss.internal.Mimetypes;
import com.aliyun.oss.model.*;
import java.io.File;
import java.io.FileInputStream;
import java.io.InputStream;
import java.util.ArrayList;
import java.util.List;

public class Demo {

    public static void main(String[] args) throws Exception {
        // Replace with the endpoint for your bucket's region.
        String endpoint = "https://oss-cn-hangzhou.aliyuncs.com";
        // Credentials are read from environment variables OSS_ACCESS_KEY_ID and OSS_ACCESS_KEY_SECRET.
        EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
        String bucketName = "examplebucket";
        // Full object path within the bucket, excluding the bucket name.
        String objectName = "exampledir/exampleobject.txt";
        // Full local path of the backup file to upload.
        String filePath = "D:\\localpath\\examplefile.txt";
        // Region identifier for the bucket, for example "cn-hangzhou".
        String region = "cn-hangzhou";

        ClientBuilderConfiguration clientBuilderConfiguration = new ClientBuilderConfiguration();
        clientBuilderConfiguration.setSignatureVersion(SignVersion.V4);
        OSS ossClient = OSSClientBuilder.create()
                .endpoint(endpoint)
                .credentialsProvider(credentialsProvider)
                .clientConfiguration(clientBuilderConfiguration)
                .region(region)
                .build();

        try {
            // Initiate the multipart upload.
            InitiateMultipartUploadRequest request = new InitiateMultipartUploadRequest(bucketName, objectName);
            ObjectMetadata metadata = new ObjectMetadata();
            if (metadata.getContentType() == null) {
                metadata.setContentType(Mimetypes.getInstance().getMimetype(new File(filePath), objectName));
            }
            request.setObjectMetadata(metadata);
            InitiateMultipartUploadResult upresult = ossClient.initiateMultipartUpload(request);
            String uploadId = upresult.getUploadId();

            List<PartETag> partETags = new ArrayList<PartETag>();
            // Each part is 1 MB; adjust based on your file size and network conditions.
            final long partSize = 1 * 1024 * 1024L;

            final File sampleFile = new File(filePath);
            long fileLength = sampleFile.length();
            int partCount = (int) (fileLength / partSize);
            if (fileLength % partSize != 0) {
                partCount++;
            }

            // Upload each part sequentially.
            for (int i = 0; i < partCount; i++) {
                long startPos = i * partSize;
                long curPartSize = (i + 1 == partCount) ? (fileLength - startPos) : partSize;
                UploadPartRequest uploadPartRequest = new UploadPartRequest();
                uploadPartRequest.setBucketName(bucketName);
                uploadPartRequest.setKey(objectName);
                uploadPartRequest.setUploadId(uploadId);
                InputStream instream = new FileInputStream(sampleFile);
                instream.skip(startPos);
                uploadPartRequest.setInputStream(instream);
                // The last part can be smaller than 100 KB; all other parts must be at least 100 KB.
                uploadPartRequest.setPartSize(curPartSize);
                // Part numbers range from 1 to 10,000.
                uploadPartRequest.setPartNumber(i + 1);
                UploadPartResult uploadPartResult = ossClient.uploadPart(uploadPartRequest);
                partETags.add(uploadPartResult.getPartETag());
                instream.close();
            }

            // Complete the upload. OSS assembles all parts in order.
            CompleteMultipartUploadRequest completeMultipartUploadRequest =
                    new CompleteMultipartUploadRequest(bucketName, objectName, uploadId, partETags);
            CompleteMultipartUploadResult completeMultipartUploadResult = ossClient.completeMultipartUpload(completeMultipartUploadRequest);
            System.out.println("Upload successful, ETag: " + completeMultipartUploadResult.getETag());

        } catch (OSSException oe) {
            System.out.println("OSS rejected the request: " + oe.getErrorMessage()
                    + " (Code: " + oe.getErrorCode() + ", Request ID: " + oe.getRequestId() + ")");
        } catch (ClientException ce) {
            System.out.println("Client error communicating with OSS: " + ce.getMessage());
        } finally {
            if (ossClient != null) {
                ossClient.shutdown();
            }
        }
    }
}

Étape 3 : Créer une tâche de migration

1. Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région de votre instance RDS, puis cliquez sur l'ID de l'instance.

2. Dans le volet de navigation de gauche, cliquez sur Backup and Restoration.

3. En haut de la page, cliquez sur Migrate OSS Backup Data to RDS.

4. Dans l'assistant Import Guide, cliquez deux fois sur Next pour atteindre l'étape Import Data.

   Si vous utilisez l'assistant de migration pour la première fois, cliquez sur Authorization et suivez la procédure d'autorisation. Sans cette étape, la liste déroulante OSS Bucket restera vide.

5. Configurez les paramètres suivants, puis cliquez sur OK.

   Paramètre	Description
   Database name	Nom de la base de données de destination sur votre instance RDS. Il ne doit entrer en conflit avec aucune base existante ni avec aucun fichier de base détaché sur l'instance.
   OSS bucket	Compartiment OSS contenant votre fichier de sauvegarde complète.
   OSS file	Cliquez sur l'icône de loupe pour rechercher le fichier de sauvegarde par préfixe de nom. Les résultats affichent le nom du fichier, sa taille et sa date de dernière modification.
   Cloud migration method	Sélectionnez Access Pending (Incremental Backup). Cette option maintient la base en état de restauration afin d'appliquer les sauvegardes incrémentielles (BackupMode = UPDF, IsOnlineDB = False). Ne choisissez pas Immediate Access (Full Backup) : celle-ci ouvre la base immédiatement après la sauvegarde complète et n'accepte pas les sauvegardes incrémentielles (BackupMode = FULL, IsOnlineDB = True).

6. Cliquez sur Refresh pour suivre l'avancement de la tâche. En cas d'échec, consultez la section Dépannage.

Étape 4 : Importer les fichiers de sauvegarde de journal ou différentiels

Une fois la sauvegarde complète restaurée, appliquez les sauvegardes incrémentielles pour combler l'écart de données.

1. Accédez à la page Instances, sélectionnez votre région et cliquez sur l'ID de l'instance.

2. Dans le volet de navigation de gauche, cliquez sur Backup and Restoration, puis sur l'onglet Cloud Migration Records of Backup Data.

3. Repérez la base de données de destination et cliquez sur Upload Incremental Files dans la colonne Task actions. Sélectionnez le fichier incrémentiel et cliquez sur OK.

Répétez cette opération pour chaque fichier de sauvegarde de journal, en respectant l'ordre chronologique.

Veillez à ce que la dernière sauvegarde de journal ou différentielle pèse moins de 500 Mo. Interrompez toutes les écritures sur la base source avant de générer la sauvegarde finale afin de garantir la cohérence des données.

Étape 5 : Ouvrir la base de données

Une fois tous les fichiers de sauvegarde importés, ouvrez la base de données de destination pour la rendre accessible en lecture et en écriture.

1. Accédez à la page Instances, sélectionnez votre région et cliquez sur l'ID de l'instance.

2. Dans le volet de navigation de gauche, cliquez sur Backup and Restoration, puis sur l'onglet Cloud Migration Records of Backup Data.

3. Repérez la base de données de destination et cliquez sur Open Database dans la colonne Task actions.

4. Sélectionnez un mode de vérification de cohérence et cliquez sur OK.

   Mode	Comportement	Cas d'utilisation
   Asynchronous DBCC	Ouvre la base immédiatement, puis exécute DBCC CHECKDB en arrière-plan. Minimise l'interruption de service. (CheckDBMode = AsyncExecuteDBCheck)	L'application est sensible aux interruptions, mais le résultat de la vérification de cohérence n'est pas critique dans l'immédiat.
   Synchronous DBCC	Exécute DBCC CHECKDB avant d'ouvrir la base. Allonge le délai d'ouverture. (CheckDBMode = SyncExecuteDBCheck)	Les résultats de la vérification de cohérence sont requis avant la mise en production de la base.

Étape 6 : Consulter les enregistrements de migration

Accédez à Backup and Restoration > Cloud Migration Records of Backup Data pour passer en revue toutes les tâches de migration. Cliquez sur View File Details dans la colonne Task actions pour afficher l'état et les détails de chaque fichier de sauvegarde associé à une tâche.

Une fois la migration terminée, ApsaraDB RDS sauvegarde automatiquement la base selon la politique de sauvegarde automatique configurée pour votre instance. Pour déclencher une sauvegarde immédiate, effectuez une sauvegarde manuelle.

Dépannage

Pour les erreurs survenant lors de la migration par sauvegarde complète, consultez la section Dépannage de cette rubrique.

Les erreurs suivantes sont spécifiques à la migration par sauvegarde incrémentielle.

Échec de l'ouverture de la base de données de destination

L'édition SQL Server source est-elle supérieure à l'édition RDS cible ?

Message d'erreur : Failed to open database xxx.

L'instance SQL Server autogérée utilise des fonctionnalités (telles que la compression de données ou le partitionnement de tables) non prises en charge par l'édition SQL Server de RDS cible. Par exemple, si la source exécute l'édition Enterprise et la destination l'édition Web, les fonctionnalités réservées à Enterprise provoquent cette erreur.

Solutions :

• Désactivez les fonctionnalités non prises en charge sur l'instance autogérée, sauvegardez à nouveau la base et relancez la migration.

• Basculez vers une instance RDS exécutant la même édition SQL Server que la source. Consultez les rubriques Créer et utiliser une instance ApsaraDB RDS for SQL Server et Fonctionnalités prises en charge par les différentes versions et éditions de SQL Server.

Incohérence des numéros de séquence de journal (LSN) dans la chaîne de sauvegarde

Les sauvegardes incrémentielles ont-elles été téléchargées dans le désordre ?

Message d'erreur : The log in this backup set begins at LSN XXX, which is too recent to apply to the database. RESTORE LOG is terminating abnormally.

Les numéros de séquence de journal (LSN) du fichier de sauvegarde incrémentielle ne font pas suite à ceux de la sauvegarde précédente. Cela se produit lorsque des fichiers incrémentiels sont appliqués à la mauvaise sauvegarde de base ou téléchargés dans le désordre.

Solution : Téléchargez les fichiers de sauvegarde incrémentielle dans un ordre chronologique strict, correspondant à la séquence de leur création.

Erreurs de cohérence détectées après Asynchronous DBCC

DBCC CHECKDB a-t-il signalé des erreurs de cohérence sur la base de destination ?

Message d'erreur : asynchronously DBCC checkdb failed: CHECKDB found 0 allocation errors and 2 consistency errors in table 'XXX' (object ID XXX).

La vérification de cohérence en arrière-plan a détecté des erreurs dans la base de destination, indiquant une corruption des données sources.

Solutions :

• Exécutez la commande suivante sur la base de destination pour réparer les erreurs (cela peut entraîner une perte de données) :

  Important

  Cette instruction peut provoquer une perte de données. Utilisez-la uniquement si cela est acceptable.

  DBCC CHECKDB (DBName, REPAIR_ALLOW_DATA_LOSS)

• Autre solution : corrigez d'abord la base source, puis relancez la migration :

  DBCC CHECKDB (DBName, REPAIR_ALLOW_DATA_LOSS)

Un fichier de sauvegarde complète a été sélectionné alors qu'un fichier incrémentiel était attendu

Avez-vous sélectionné un fichier de sauvegarde complète lors de l'étape Upload Incremental Files ?

Message d'erreur : Backup set (xxx) is a Database FULL backup, we only accept transaction log or differential backup.

Après la restauration de la sauvegarde complète, seule l'étape Upload Incremental Files accepte les fichiers de sauvegarde de journal ou différentiels.

Solution : Sélectionnez un fichier de sauvegarde de journal ou différentiel.

Limite du nombre de bases de données dépassée

L'instance RDS a-t-elle atteint son nombre maximal de bases de données ?

Message d'erreur : The database (xxx) migration failed due to databases count limitation.

Solution : Migrez vers une autre instance RDS ou supprimez les bases de données dont vous n'avez plus besoin.

Problèmes d'autorisations liés à un utilisateur RAM

Le bouton OK est-il grisé lors de la configuration de la tâche de migration ?

L'utilisateur RAM ne dispose probablement pas des autorisations requises. Vérifiez que les stratégies AliyunOSSFullAccess, AliyunRDSFullAccess et la stratégie personnalisée AliyunRDSImportRole lui sont bien attribuées (voir la section Prérequis).

*L'utilisateur RAM reçoit-il une erreur no permission lors de l'attribution de l'autorisation AliyunRDSImportRole ?*

Accordez temporairement à l'utilisateur RAM l'autorisation AliyunRAMFullAccess via le compte Alibaba Cloud. Consultez la rubrique Utiliser RAM pour gérer les autorisations ApsaraDB RDS. Retirez cette autorisation une fois la configuration terminée.

Référence API