Existe uma instância mariaDB que já está em execução e possui dados em muitas tabelas. Deixe-me chamar esse banco de dados antigo. Digamos que a estrutura (tabelas e seus campos) não foi bem pensada e, portanto, leva à duplicação de dados em vários registros e a maioria das colunas está vazia em muitos registros. Além disso, os nomes das colunas não eram informativos - como col1, col2 e col3 em vez de nome, local e endereço. Como a instância mariaDB está em uso ativo, qualquer reestruturação envolverá a alteração de outros aplicativos que a utilizam. Então, gostaríamos de replicá-lo para uma estrutura diferente em uma instância diferente localizada em um local diferente, deixe-me chamar esse novo banco de dados. Dessa forma, todos os aplicativos implantados anteriormente ainda funcionam, mas há uma cópia estruturada melhor disponível.
À medida que os dados são adicionados ao banco de dados antigo, eles são replicados na nova estrutura ao vivo. Por exemplo, digamos que o banco de dados antigo tenha uma tabela funcionário como
create table employee (
g1 int,
g2 varchar(255),
g3 varchar(255),
g4 varchar(255),
g5 date
);
No novo banco de dados, digamos que os mesmos dados sejam estruturados dividindo-os em duas tabelas:
create table employee_table (
id int primary key,
first_name varchar(255),
last_name varchar(255),
date_of_birth date
);
create table address_table (
id int,
address varchar(255),
foreign key (id) references employee_table(id)
);
Neste cenário, digamos que queremos o seguinte mapeamento dos campos do funcionário no banco de dados antigo para os campos do novo banco de dados:
- funcionário.g1 -> funcionário_tabela.id, endereço_tabela.id
- empregado.g2 -> tabela_funcionário.nome_primeiro
- empregado.g3 -> tabela_funcionário.último_nome
- empregado.g4 -> endereço_tabela.endereço
- empregado.g5 -> tabela_funcionário.data_de_nascimento
É possível fazer isso usando algum método de replicação disponível suportado por mariadb ou postgresql?
Entendo que é possível replicar para a mesma estrutura do banco de dados antigo, mas não consegui encontrar nada sobre replicar para uma estrutura diferente. O único método que consegui criar envolve escrever uma configuração json que mapeia cada campo no novo banco de dados para o banco de dados antigo, juntamente com as informações necessárias, como tipos, para que a conversão de tipo seja executada, se necessário. Um script python, por exemplo, pode usar isso como uma pesquisa para preencher o novo banco de dados do banco de dados antigo e esse script pode ser executado em intervalos regulares. A configuração também deve mencionar maneiras de sinalizar ou lidar com conflitos como eles são esperados devido à estrutura ruim do banco de dados antigo. Por exemplo, o mesmo funcionário pode ter dois data_of_birth diferentes no banco de dados antigo e isso deve ser tratado ou sinalizado durante a replicação.
Existe também a possibilidade de ter gatilhos para cada tabela na inserção, de modo que os dados inseridos no banco de dados antigo sejam refletidos na estrutura diferente do novo banco de dados. Os dados são sempre inseridos apenas no banco de dados antigo por meio de aplicativos já implantados. Em seguida, o novo banco de dados pode ser replicado usando a abordagem padrão para o outro local. Mas acho que isso não é bom, pois editar uma configuração json é mais fácil do que ir para cada tabela e modificar o gatilho caso sejam necessárias alterações.
Agradeceria sugestões sobre melhores abordagens para fazer esse tipo de replicação e ponteiros sobre métodos padrão para fazer isso.
Para mudanças de nome simples, definir
VIEWs
pode ser a 'melhor' solução.Cada um
VIEW
pode ser uma camada fina sobre uma já existente. Isso ainda exigiria a alteração dos nomes das tabelas para os nomes das exibições.A replicação, mesmo "baseada em linha", pode ser incapaz de ignorar os nomes das colunas.
Parte do problema é que deve mudar o aplicativo no "mesmo" tempo que o esquema. Mas isso pode ser uma solução alternativa para isso:
Observe que esse processo de 3 etapas pode lidar com muitos tipos de alteração, não apenas alterações de nome.
pt-online-schema-change
pode ser a melhor maneira de fazer ALTERs; ele executa ALTER com tempo de inatividade praticamente zero.