Preservação de dados na clonagem de instâncias de destino

  • Versão de lançamento: Washingtondc
  • Atualizado 1 de fev. de 2024
  • 11 min. de leitura
  • Você pode usar preservadores de dados para proteger os dados na instância de destino contra a substituição. Se você tiver aplicações personalizadas, também deverá preservar manualmente o conteúdo da aplicação não publicado.

    Preservadores de dados

    Às vezes, é necessário preservar alguns dados em uma instância destinada à clonagem. Por exemplo, se o destino for um MID Server, você não deverá substituir a tabela MID Server [ecc_agent]. Os dados preservados são armazenados na instância de destino antes do início da clonagem e são restaurados na instância de destino após a clonagem.
    Aviso:
    Você deve definir preservadores de dados na instância de origem. Defini-los na instância de destino não preserva os dados.
    Os preservadores de dados normalmente preservam as configurações e os temas do sistema, como:
    • Configurações de autenticação específicas da instância
    • Marcador [sys_ui_bookmark]
    • Seleção recente [sys_ui_recent_selection]
    • Preferência do usuário [sys_user_preference]
    Nota:
    Um clone não oferece suporte à preservação de dados de uma exibição de banco de dados.

    Não use preservadores de dados para transferir grandes conjuntos de dados, como grupos de usuários. Se você precisar preservar os dados da tabela, como usuários, grupos e funções, considere exportar os registros para um arquivo e importá-los após a clonagem.

    Preservadores de dados para Multi-SSO

    O sistema cria automaticamente os preservadores de dados necessários para clonagem quando você ativa a Integração de Single Sign-On de vários provedores.
    Nome Tabela Condições
    Certificado Certificados X.509 [sys_certificate] Nenhum(a)
    Propriedades da instância principal Propriedades do sistema [sys_properties]
    • [OR] [Name] [é um de] [glide.authenticate.external, glide.authenticate.external.logout_redirect]
    • [OR] [Name] [começa com] [com.snc.integration.saml_esig]
    • [OR] [Name] [é um de] [glide.smtp.port, glide.smtp.auth, glide.smtp.encryption]
    • [OR] [Name] [começa com] [glide.authenticate.multisso]
    • [OR] [Name] [is] [glide.authenticate.sso.redirect.idp]
    Nota:
    As propriedades glide.smtp.port, glide.smtp.authe glide.smtp.encryption estão obsoletas.
    Propriedades do resumo Propriedades de resumo [digest_properties] Nenhum(a)
    Provedores de Identidade Provedores de identidade [sso_properties] Nenhum(a)
    Propriedades de SAML2 Update1 Propriedades de SAML2 Update1 [saml2_update1_properties] Nenhum(a)
    Nota:
    Embora você possa modificar esses preservadores de dados, é uma prática recomendada não fazê-lo. As tabelas Propriedades de resumo [digest_properties], Provedores de identidade [sso_properties] e Propriedades de SAML2 Update1 [saml2_update1_properties] são necessárias para que o Single Sign-on (SSO) de várias origens funcione corretamente. Se o logon único de várias origens estiver desabilitado na instância de destino, você poderá remover com segurança todos os três preservadores de dados. Remova-as ao mesmo tempo, pois o sistema encerra o clone com uma mensagem de erro quando você tenta clonar com uma ou duas dessas tabelas sendo preservadas.

    Preservadores de dados para SAML

    Preservar as configurações relacionadas ao SSO do SAML pode impedir que a instância de destino use os parâmetros incorretos de emissor e público ao fazer solicitações de autenticação ao seu IdP. Para preservar as configurações de SAML, crie preservadores de dados para as seguintes tabelas:

    • Propriedade do sistema [sys_properties]: para preservar as propriedades do SAML.
    • Certificados X.509 [sys_certificate]: para preservar os certificados SAML.
    • Usuário [sys_user]: para preservar os usuários SAML.

    Você também precisa preservar as propriedades e os usuários envolvidos no SAML.

    Preservação de aplicações não publicadas

    Você não pode usar preservadores de dados para salvar aplicações não publicadas. Em vez disso, os desenvolvedores de aplicações devem escolher como desejam preservar aplicações não publicadas.

    O processo de clonagem não preserva as diferenças de versão das aplicações em desenvolvimento. Em vez disso, o clone do sistema copia somente a versão da aplicação instalada na instância de origem para a instância de destino. Se a instância de destino tiver uma versão de desenvolvimento da mesma aplicação, a aplicação será editável após o clone, mas estará em qualquer versão instalada na instância de origem. Se a aplicação estiver ausente na instância de origem, o processo de clonagem excluirá a aplicação da instância de destino.

    Criar um preservador de dados

    Os preservadores de dados mantêm os dados especificados em uma instância de destino.

    Antes de Iniciar

    Função necessária: clone_admin ou admin

    Por Que e Quando Desempenhar Esta Tarefa

    Às vezes, é desejável preservar determinados dados em uma instância de destino. Por exemplo, ao usar um MID Server, você pode evitar a substituição da tabela MID Server [ecc_agent]. Os dados preservados são armazenados em uma lista gerada dinamicamente na instância de destino antes do clone e restaurados na instância de destino após a conclusão do clone. Você define preservadores de dados na instância de origem.

    Os preservadores de dados têm como objetivo principal preservar as configurações e os temas do sistema, como configurações de autenticação específicas da instância. Não use preservadores de dados para transferir grandes conjuntos de dados, como grupos de usuários. Se você precisar preservar os dados da tabela, como usuários, grupos e funções, considere exportar os registros para um arquivo e importá-lo após a conclusão do clone.

    Considere se os dados nas tabelas a seguir devem ser preservados.
    • Marcador [sys_ui_bookmark]
    • Seleção recente [sys_ui_recent_selection]
    • Preferência do usuário [sys_user_preference]

    Se você definir um preservador de dados em uma tabela em que a instância de origem tem mais registros do que a instância de destino, os dados preservados na instância de destino também incluirão os registros adicionais da instância de origem.

    Por exemplo, suponha que o preservador de dados já esteja em vigor.
    • Na instância de origem, a tabela sys_temp contém 100 registros.
    • Na instância de destino, a tabela sys_temp contém 20 registros.
    Após o clone, a tabela sys_temp na instância de destino contém 100 registros.
    • Os 20 registros na tabela sys_temp de destino foram preservados com sucesso (de acordo com a especificação do preservador de dados). Esses registros fazem parte dos 100 registros na tabela sys_temp de origem.
    • A tabela sys_temp de origem traz os 80 registros restantes para a tabela sys_temp de destino.

    Para resolver esse problema e preservar somente os registros na tabela de destino, crie um registro de tabela de exclusão para a tabela de destino, além de definir o preservador de dados na tabela de origem.

    Importante:
    Configure preservadores na instância de origem.

    Procedimento

    1. Na instância de origem, navegue até Clone do sistema > Preservar dados.
    2. Clique em Nova.
    3. Insira o rótulo da tabela como o Nome, por exemplo, Preferência do usuário para a tabela [sys_user_preference].
      O preservador de dados deve ter um nome de tabela ou não poderá ser enviado.
    4. Selecione a Tabela a ser preservada.
      O preservador de dados deve ter uma tabela selecionada ou não poderá ser enviado.
    5. Marque a caixa de seleção Tema se os dados que estão sendo preservados forem uma propriedade de IU.
    6. Defina os dados a serem preservados usando o Construtor de condição.
      Você pode usar condições para definir registros específicos que deseja preservar durante um clone. Por exemplo, para preservar somente propriedades específicas do sistema, você pode adicionar condições para cada nome de propriedade que deseja preservar.
      Nota:
      A condição para corresponder a expressões regulares [match regex] não é mais compatível.
      Preservador de dados com condições
      Aviso:
      Se o clone do backup falhar por algum motivo, o processo de clone fará o failover para o mecanismo de clone legado. O mecanismo de clone legado não pode preservar dados de tabelas estendidas, relacionamentos, hierarquias entre tabelas e consultas de referência com pontos. Você pode reprogramar um clone do sistema ou transferir dados manualmente nesses casos.
    7. Clique em Enviar.
      Se você quiser excluir o preservador de dados mais tarde, certifique-se de não modificar ou excluir os seguintes registros de preservador de dados:
      • Propriedades da instância principal
      • Semáforos
      • Contas de e-mail
      Nota:
      As exibições de banco de dados não podem ser preservadas.

      Os preservadores não podem ficar em branco e os usuários não poderão enviar o clone se os preservadores estiverem vazios.

    Preservar propriedades SAML

    Se você quiser que uma instância de destino do clone mantenha sua integração SAML existente, edite o preservador de dados Propriedades da instância principal para incluir as propriedades SAML.

    Antes de Iniciar

    Função necessária: administrador

    Procedimento

    1. Navegar até Todos > Clone do sistema > Preservar dados.
    2. Selecione Propriedades da instância principal.
    3. Adicione as seguintes condições.
      • [OR] [Name] [é um de] [glide.authenticate.external, glide.authenticate.external.logout_redirect, glide.authenticate.failed_requirement_redirect]
      • [OR] [Name] [começa com] [glide.authenticate.sso.saml2]
      • [OR] [Name] [começa com] [com.snc.integration.saml_esig]
      Preservação de propriedade do sistema SAML
      Nota:
      Certifique-se de que a caixa de seleção Tema esteja desmarcada para que essas propriedades sejam preservadas, independentemente de você preservar o tema da instância.
    4. Clique em Atualizar.

    Preservar aplicações e personalizações no desenvolvimento durante um clone do sistema

    Preserve manualmente uma cópia de cada aplicação e personalização que você tem atualmente em desenvolvimento antes de clonar a versão da aplicação para a instância de destino (desenvolvimento).

    Antes de Iniciar

    Verifique se você tem acesso de gravação ao registro da aplicação.

    Verifique se você tem acesso a um repositório de controle de código-fonte.

    Função necessária: administrador

    Por Que e Quando Desempenhar Esta Tarefa

    O processo de clonagem não preserva as diferenças de versão para aplicações e personalizações de aplicações em desenvolvimento. Em vez disso, o sistema clona somente as cópias da aplicação e das versões de personalização da aplicação que estão instaladas na instância de origem na instância de destino. Se a instância de destino tiver uma versão de desenvolvimento da mesma aplicação, a aplicação será editável após o clone, mas estará na versão instalada na instância de origem. Se a aplicação estiver ausente na instância de origem, o processo de clonagem excluirá a aplicação da instância de destino.

    Procedimento

    1. Para preservar a aplicação na instância de destino do clone, execute uma destas ações:
      Tabela 1. Diferenças de versão entre instâncias
      Estado da versão da aplicação Ação a ser realizada
      A versão da aplicação na instância de destino do clone é diferente da versão da instância de origem. Exporte cada aplicação da instância de destino do clone. As opções incluem:
      • Vincule cada aplicação a um repositório de controle de código-fonte.
        Nota:
        Se a aplicação já estiver vinculada a um repositório de controle de código-fonte, confirme a versão mais recente para ele.
      • Publique cada aplicação em um conjunto de atualizações.
      A aplicação está disponível somente na instância de destino do clone.
      A versão da aplicação na instância de destino do clone é a mesma da instância de origem. Nenhum. O processo de clone do sistema copia esta versão da aplicação para a instância de destino durante o clone.
    2. Solicite um clone do sistema da instância de origem para a instância de destino.
      Por exemplo, clone sua instância de produção na instância de desenvolvimento.
    3. Após a conclusão do processo de clonagem, faça login na instância de destino do clone.
    4. Se você salvou cada aplicação em um repositório de controle de código-fonte, use uma destas ações para recuperá-las do repositório de controle de código-fonte:
      Tabela 2. Recuperar aplicações de um repositório de controle de código-fonte
      Estado de instalação da aplicação Ação a ser tomada no destino do clone
      A aplicação foi instalada anteriormente na instância de origem. Aplique mudanças remotas do repositório de controle de código-fonte.
      A aplicação nunca foi instalada na instância de origem. Importe a aplicação do repositório de controle de código-fonte.
    5. Nota:
      Para saber o que esperar após a pós-clonagem da personalização da aplicação, consulte Resultados após a clonagem para personalizações da aplicação.
      Para personalização da aplicação, use uma dessas ações para recuperá-las do repositório de controle de código-fonte.
      Tabela 3. Recuperar aplicações de um repositório de controle de código-fonte
      Estado da instalação da aplicação e da personalização Ação a ser tomada no destino do clone
      A aplicação e a personalização foram instaladas anteriormente na instância de origem. Aplique mudanças remotas do repositório de controle de código-fonte.
      A aplicação foi instalada anteriormente na instância de origem, mas não a personalização. Aplique mudanças remotas do repositório de controle de código-fonte.
      A aplicação base nunca foi instalada na instância de origem. Exclua a configuração do repositório (sys_repo_config) e importe a personalização do repositório de controle de código-fonte.
    6. Se você salvou cada aplicação em um conjunto de atualizações, execute uma destas ações para recuperá-las do conjunto de atualizações:
      Tabela 4. Recuperar aplicações de um conjunto de atualizações
      Estado de instalação da aplicação Ação a ser tomada no destino do clone
      A aplicação foi instalada anteriormente na instância de origem.
      1. Exclua a versão da aplicação que foi clonada da instância de origem.
      2. Carregue o conjunto de atualizações que contém a versão atual da aplicação.
      A aplicação nunca foi instalada na instância de origem. Carregue o conjunto de atualizações que contém a versão atual da aplicação.
    7. Depois de um clone, você pode aplicar as seguintes mudanças remotas:
      Tabela 5. Mudanças remotas após clonagem
      Campo Descrição
      glide.source_control.post_clone_import_enabled Para desabilitar a automação de aplicar mudanças remotas, defina como Falso. O padrão é Verdadeiro.
      glide.source_control.post_clone_import_delay_time_sec Para fornecer um tempo de atraso, que atrasará o processamento da fila, forneça um valor. O padrão é zero.
      glide.source_control.post_clone_import_pause_refresh_time_sec Para fornecer um intervalo no qual o trabalho de atualização do repositório não será executado, informe um valor. O padrão é três horas (10800).

    Resultado

    As aplicações anteriormente em desenvolvimento estão disponíveis para desenvolvimento adicional na instância de destino do clone.

    Preservar a aplicação Eventos de Marketing

    Digamos que sua empresa tenha criado anteriormente a versão 1.0 de um aplicativo personalizado chamado Marketing Events. Você já publicou a versão 1.0 da aplicação Marketing Events no repositório de aplicações e a instalou em sua instância de produção.

    Com o passar do tempo, os usuários enviaram solicitações de aprimoramento para a aplicação e você decide desenvolver a versão 2.0 da aplicação Eventos de Marketing em uma instância de não produção para atender a essas solicitações. Conforme o desenvolvimento se aproxima da conclusão, você deseja atualizar sua instância de não produção para a cópia mais recente de produção para alguns testes abrangentes.

    Como você usou anteriormente uma integração de controle de código-fonte para desenvolver a versão 1.0 da aplicação Marketing Events, você já vinculou a aplicação Marketing Events a um repositório de controle de código-fonte. Você confirma a versão 2.0 da aplicação Marketing Events para o repositório de controle de código-fonte.

    Você programa um clone da instância de produção na instância de desenvolvimento. Após a conclusão, você faz login na instância de desenvolvimento e vê que ela tem a versão 1.0 da aplicação Marketing Events, porque essa foi a versão instalada na instância de origem.

    Como a aplicação já foi instalada na instância de origem, você aplica as mudanças remotas do repositório de controle de código-fonte para receber a versão mais recente da aplicação. A instância de desenvolvimento agora tem a versão 2.0 da aplicação Marketing Events e está disponível para desenvolvimento e testes adicionais.