Migrar de Oracle para MySQL/Percona Server não é uma tarefa trivial. Embora esteja ficando mais fácil, principalmente com a chegada do MySQL 8.0 e a Percona anunciou o Percona Server para MySQL 8.0 GA. Além de planejar sua migração do Oracle para o Percona Server, você deve garantir que entende a finalidade e a funcionalidade do motivo pelo qual ele deve ser o Percona Server.
Este blog se concentrará na migração do Oracle para o Percona Server como seu banco de dados de destino específico de escolha. Há uma página no site da Oracle sobre Informações Suplementares do SQL Developer para Migrações do MySQL que podem ser usadas como referência para a migração planejada. Este blog não abordará o processo geral de migração, pois é um processo longo. Mas esperamos que forneça informações básicas suficientes para servir de guia para seu processo de migração.
Como o Percona Server é um fork do MySQL, quase todos os recursos que acompanham o MySQL estão presentes no Percona Server. Portanto, qualquer referência do MySQL aqui também é aplicável ao Percona Server. Anteriormente, escrevemos sobre a migração do Oracle Database para o PostgreSQL. Reitero novamente as razões pelas quais se consideraria migrar do Oracle para um RDBMS de código aberto como PostgreSQL ou Percona Server/MySQL/MariaDB.
- Custo:Como você deve saber, o custo da licença do Oracle é muito caro e há um custo adicional para alguns recursos, como particionamento e alta disponibilidade. Portanto, no geral, é muito caro.
- Licenciamento flexível de código aberto e fácil disponibilidade de provedores de nuvem pública como a AWS.
- Aproveite os complementos de código aberto para melhorar o desempenho.
Planejamento e Estratégia de Desenvolvimento
A migração do Oracle para o Percona Server 8.0 pode ser um problema, pois há muitos fatores-chave que precisam ser considerados e abordados. Por exemplo, o Oracle pode ser executado em uma máquina Windows Server, mas o Percona Server não oferece suporte ao Windows. Embora você possa compilá-lo para Windows, o próprio Percona não oferece suporte para Windows. Você também deve identificar seus requisitos de arquitetura de banco de dados, pois o Percona Server não foi projetado para OLAP (Processamento Analítico Online) ou aplicativos de armazenamento de dados. Percona Server/MySQL RDBMS são perfeitos para OLTP (Online Transaction Processing).
Identificando o aspecto chave de sua arquitetura de banco de dados, por exemplo, se sua arquitetura Oracle atual implementa MAA (Maximum Available Architecture) com Data Guard ++ Oracle RAC (Real Application Cluster), você deve determinar sua equivalência no Percona Server. Não há uma resposta direta para isso no MySQL/Percona Server. No entanto, você pode escolher entre uma replicação síncrona, uma replicação assíncrona (o Percona XtraDB Cluster ainda está na versão 5.7.x) ou com Replicação de Grupo. Então, há várias alternativas que você pode implementar para sua própria solução de alta disponibilidade. Por exemplo, (para citar alguns) usando a pilha Corosync/Pacemaker/DRBD/Linux, ou usando MHA (MySQL High Availability), ou usando a pilha Keepalived/HaProxy/ProxySQL, ou simplesmente confiar no ClusterControl que suporta Keepalived, HaProxy, ProxySQL, Garbd e Maxscale para suas soluções de alta disponibilidade.
Por outro lado, a questão que você também deve considerar como parte do plano é "Como a Percona fornecerá suporte e quem nos ajudará quando o próprio Percona Server encontrar um bug ou quão alta é a urgência quando precisamos de ajuda?". Uma coisa a considerar também é o orçamento, se o objetivo da migração do banco de dados corporativo para um RDBMS de código aberto for devido à redução de custos.
Existem diferentes opções, desde o planejamento da migração até as coisas que você precisa fazer como parte de sua estratégia de desenvolvimento. Essas opções incluem o envolvimento com especialistas no campo MySQL/Percona Server e isso nos inclui aqui na Variousnines. Existem muitas empresas de consultoria MySQL que podem ajudá-lo com isso, pois a migração do Oracle para o MySQL requer muita experiência e know-how na área do MySQL Server. Isso não deve se limitar ao banco de dados, mas deve abranger experiência em escalabilidade, redundância, backups, alta disponibilidade, segurança, monitoramento/observabilidade, recuperação e envolvimento em sistemas de missão crítica. No geral, ele deve ter uma compreensão de sua visão arquitetônica sem expor a confidencialidade de seus dados.
Avaliação ou Verificação Preliminar
O backup de seus dados, incluindo configurações ou arquivos de configuração, ajustes de kernel, scripts de automação, não deve ser esquecido. É uma tarefa óbvia, mas antes de migrar, sempre proteja tudo primeiro, principalmente ao mudar para uma plataforma diferente.
Você também deve avaliar se seus aplicativos estão seguindo as convenções de engenharia de software atualizadas e garantir que sejam independentes de plataforma. Essas práticas podem ser benéficas especialmente ao mudar para uma plataforma de banco de dados diferente, como o Percona Server for MySQL.
Observe que o sistema operacional que o Percona Server requer pode ser um impedimento se seu aplicativo e banco de dados forem executados em um Windows Server e o aplicativo for dependente do Windows; então isso pode dar muito trabalho! Lembre-se sempre de que o Percona Server está em uma plataforma diferente:a perfeição pode não ser garantida, mas pode ser alcançada perto o suficiente.
Por último, certifique-se de que o hardware de destino foi projetado para funcionar de forma viável com os requisitos do servidor da Percona ou que pelo menos esteja livre de bugs (veja aqui). Você pode considerar o teste de estresse primeiro com o Percona Server antes de sair do banco de dados Oracle de forma confiável.
O que você deve saber
Vale ressaltar que no Percona Server / MySQL, você pode criar vários bancos de dados enquanto o Oracle não vem com a mesma funcionalidade do MySQL.
No MySQL, fisicamente, um esquema é sinônimo de um banco de dados. Você pode substituir a palavra-chave SCHEMA em vez de DATABASE na sintaxe SQL do MySQL, por exemplo, usando CREATE SCHEMA em vez de CRIAR BANCO DE DADOS; enquanto a Oracle tem uma distinção disso. Um esquema representa apenas uma parte de um banco de dados:as tabelas e outros objetos pertencentes a um único usuário. Normalmente, há um relacionamento de um para um entre a instância e o banco de dados.
Por exemplo, em uma configuração de replicação equivalente no Oracle (por exemplo, Real Application Clusters ou RAC), você tem várias instâncias acessando um único banco de dados. Isso permite iniciar o Oracle em vários servidores, mas todos acessando os mesmos dados. No entanto, no MySQL, você pode permitir acesso a vários bancos de dados de suas várias instâncias e pode até filtrar quais bancos de dados/esquema você pode replicar para um nó MySQL.
Fazendo referência a um de nossos blogs anteriores, o mesmo princípio se aplica quando se fala em converter seu banco de dados com ferramentas disponíveis encontradas na internet.
Não existe tal ferramenta que possa converter 100% do banco de dados Oracle em Percona Server / MySQL; alguns serão trabalhos manuais.
Confira as seções a seguir para saber o que você deve estar ciente quando se trata de migração e verificação do resultado lógico do SQL.
Mapeamento de tipo de dados
O MySQL / Percona Server tem vários tipos de dados que são quase os mesmos do Oracle, mas não tão ricos quanto o Oracle. Mas desde a chegada da versão 5.7.8 do MySQL, há suporte para um tipo de dados JSON nativo.
Abaixo está sua representação equivalente de tipo de dados (a representação tabular é tirada daqui):
Oráculo | MySQL | |||
---|---|---|---|---|
1 | BFILE | Ponteiro para arquivo binário, ⇐ 4G | VARCHAR(255) | |
2 | BINARY_FLOAT | Número de ponto flutuante de 32 bits | FLOAT | |
3 | BINARY_DOUBLE | Número de ponto flutuante de 64 bits | DUPLO | |
4 | BLOB | Objeto binário grande, ⇐ 4G | LONGBLOB | |
5 | CHAR(n), CHARACTER(n) | String de comprimento fixo, 1 ⇐ n ⇐ 255 | CHAR(n), CHARACTER(n) | |
6 | CHAR(n), CHARACTER(n) | String de comprimento fixo, 256 ⇐ n ⇐ 2000 | VARCHAR(n) | |
7 | CLOB | Caractere objeto grande, ⇐ 4G | TEXTO LONGO | |
8 | DATA | Data e hora | DATETIME | |
9 | DECIMAL(p,s), DEC(p,s) | Número de ponto fixo | DECIMAL(p,s), DEC(p,s) | |
10 | DUPLA PRECISÃO | Número de ponto flutuante | DUPLA PRECISÃO | |
11 | FLOAT(p) | Número de ponto flutuante | DUPLO | |
12 | INTEIRO, INT | 38 dígitos inteiro | INT | DECIMAL(38) |
13 | INTERVAL YEAR(p) TO MONTH | Intervalo de data | VARCHAR(30) | |
14 | INTERVALO DIA(p) A SEGUNDO(s) | Intervalo de dia e hora | VARCHAR(30) | |
15 | LONGO | Dados de caracteres, ⇐ 2G | TEXTO LONGO | |
16 | LONG RAW | Dados binários, ⇐ 2G | LONGBLOB | |
17 | NCHAR(n) | String UTF-8 de comprimento fixo, 1 ⇐ n ⇐ 255 | NCHAR(n) | |
18 | NCHAR(n) | String UTF-8 de comprimento fixo, 256 ⇐ n ⇐ 2000 | NVARCHAR(n) | |
19 | NCHAR VARIANDO(n) | String UTF-8 de comprimento variável, 1 ⇐ n ⇐ 4000 | NCHAR VARYING(n) | |
20 | NCLOB | String Unicode de comprimento variável, ⇐ 4G | NVARCHAR(max) | |
21 | NUMBER(p,0), NUMBER(p) | inteiro de 8 bits, 1 <=p <3 | TINYINT | (0 a 255) |
inteiro de 16 bits, 3 <=p <5 | SMALLINT | |||
inteiro de 32 bits, 5 <=p <9 | INT | |||
inteiro de 64 bits, 9 <=p <19 | GRANDE | |||
Número de ponto fixo, 19 <=p <=38 | DECIMAL(p) | |||
22 | NUMBER(p,s) | Número de ponto fixo, s> 0 | DECIMAL(p,s) | |
23 | NÚMERO, NÚMERO(*) | Número de ponto flutuante | DUPLO | |
24 | NUMERIC(p,s) | Número de ponto fixo | NUMERIC(p,s) | |
25 | NVARCHAR2(n) | String UTF-8 de comprimento variável, 1 ⇐ n ⇐ 4000 | NVARCHAR(n) | |
26 | RAW(n) | String binária de comprimento variável, 1 ⇐ n ⇐ 255 | BINÁRIO(n) | |
27 | RAW(n) | String binária de comprimento variável, 256 ⇐ n ⇐ 2000 | VARBINÁRIO(n) | |
28 | REAL | Número de ponto flutuante | DUPLO | |
29 | ROWID | Endereço da linha física | CHAR(10) | |
30 | SMALLINT | 38 dígitos inteiro | DECIMAL(38) | |
31 | TIMESTAMP(p) | Data e hora com fração | DATETIME(p) | |
32 | TIMESTAMP(p) COM FUSO HORÁRIO | Data e hora com fração e fuso horário | DATETIME(p) | |
33 | UROWID(n) | Endereços de linhas lógicas, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
34 | VARCHAR(n) | String de comprimento variável, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
35 | VARCHAR2(n) | String de comprimento variável, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
36 | XMLTYPE | Dados XML | TEXTO LONGO |
Atributos e opções do tipo de dados:
Oráculo | MySQL |
Semântica de tamanho de coluna BYTE e CHAR | O tamanho está sempre em caracteres |
Transações
O Percona Server usa o XtraDB (uma versão aprimorada do InnoDB) como seu principal mecanismo de armazenamento para lidar com dados transacionais; embora vários mecanismos de armazenamento possam ser uma opção alternativa para lidar com transações, como os mecanismos de armazenamento TokuDB (obsoleto) e MyRocks.
Embora existam vantagens e benefícios em usar ou explorar o MyRocks com o XtraDB, este último é o mecanismo de armazenamento mais robusto e de fato que o Percona Server está usando e está habilitado por padrão, portanto, usaremos esse mecanismo de armazenamento como base para migração em relação às transações.
Por padrão, o Percona Server / MySQL tem a variável de autocommit definida como ON, o que significa que você deve manipular explicitamente as instruções transacionais para aproveitar o ROLLBACK para ignorar as alterações ou usar o SAVEPOINT.
É basicamente o mesmo conceito que a Oracle usa em termos de commit, rollbacks e savepoints.
Para transações explícitas, isso significa que você deve usar o START TRANSACTION/BEGIN;
Caso contrário, se você tiver que desabilitar o autocommit, você precisará explicitamente COMMIT o tempo todo para suas instruções que exigem alterações em seus dados.
Mesa dupla
O MySQL tem a compatibilidade dupla com o Oracle, que se destina à compatibilidade de bancos de dados usando uma tabela fictícia, ou seja, DUAL.
Isso se adequa ao uso do DUAL pela Oracle, portanto, quaisquer instruções existentes em seu aplicativo que usem o DUAL podem não exigir alterações na migração para o Percona Server.
A cláusula Oracle FROM é obrigatória para cada instrução SELECT, portanto, o banco de dados Oracle usa a tabela DUAL para a instrução SELECT onde um nome de tabela não é necessário.
No MySQL, a cláusula FROM não é obrigatória, então a tabela DUAL não é necessária. No entanto, a tabela DUAL não funciona exatamente da mesma forma que para o Oracle, mas para SELECTs simples no Percona Server, isso é bom.
Veja o seguinte exemplo abaixo:
No Oráculo,
SQL> DESC DUAL;
Name Null? Type
----------------------------------------- -------- ----------------------------
DUMMY VARCHAR2(1)
SQL> SELECT CURRENT_TIMESTAMP FROM DUAL;
CURRENT_TIMESTAMP
---------------------------------------------------------------------------
16-FEB-19 04.16.18.910331 AM +08:00
Mas no MySQL:
mysql> DESC DUAL;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DUAL' at line 1
mysql> SELECT CURRENT_TIMESTAMP FROM DUAL;
+---------------------+
| CURRENT_TIMESTAMP |
+---------------------+
| 2019-02-15 20:20:28 |
+---------------------+
1 row in set (0.00 sec)
Observação:o DESC DUAL A sintaxe não funciona no MySQL e os resultados também diferem, pois CURRENT_TIMESTAMP (usa o tipo de dados TIMESTAMP) no MySQL não inclui o fuso horário.
SYSDATE
A função SYSDATE do Oracle é quase a mesma no MySQL.
MySQL retorna data e hora e é uma função que requer () (fechar e abrir parênteses sem necessidade de argumentos. Para demonstrar isso abaixo, veja o Oracle e o MySQL usando SYSDATE.
No Oracle, usar SYSDATE simples apenas retorna a data do dia sem a hora. Mas para obter a hora e a data, use TO_CHAR para converter a data e hora no formato desejado; enquanto no MySQL, você pode não precisar dele para obter a data e a hora, pois retorna ambos.
Veja exemplo abaixo.
No Oráculo:
SQL> SELECT TO_CHAR (SYSDATE, 'MM-DD-YYYY HH24:MI:SS') "NOW" FROM DUAL;
NOW
-------------------
02-16-2019 04:39:00
SQL> SELECT SYSDATE FROM DUAL;
SYSDATE
---------
16-FEB-19
Mas no MySQL:
mysql> SELECT SYSDATE() FROM DUAL;
+---------------------+
| SYSDATE() |
+---------------------+
| 2019-02-15 20:37:36 |
+---------------------+
1 row in set (0.00 sec)
Se você deseja formatar a data, o MySQL possui uma função DATE_FORMAT().
Você pode verificar a documentação de data e hora do MySQL para obter mais informações.
TO_DATE
O equivalente TO_DATE do Oracle no MySQL é a função STR_TO_DATE().
É quase idêntico ao do Oracle:ele retorna o tipo de dado DATE, enquanto no MySQL ele retorna o tipo de dado DATETIME.
Oráculo:
SQL> SELECT TO_DATE ('20190218121212','yyyymmddhh24miss') as "NOW" FROM DUAL;
NOW
-------------------------
18-FEB-19
MySQL:
mysql> SELECT STR_TO_DATE('2019-02-18 12:12:12','%Y-%m-%d %H:%i:%s') as "NOW" FROM DUAL;
+---------------------+
| NOW |
+---------------------+
| 2019-02-18 12:12:12 |
+---------------------+
1 row in set (0.00 sec)
SINÔNIMO
No MySQL, não existe tal suporte nem qualquer equivalência para SYNONYM no Oracle.
Uma alternativa possível com o MySQL é usar VIEW.
Embora SYNONYM possa ser usado para criar um alias de uma tabela remota,
por exemplo.
CREATE PUBLIC SYNONYM emp_table FOR [email protected]
No MySQL, você pode aproveitar o uso do mecanismo de armazenamento FEDERADO.
por exemplo.
CREATE TABLE hr_employees (
id INT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(32) NOT NULL DEFAULT '',
other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
INDEX name (name),
INDEX other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=utf8mb4
CONNECTION='mysql://[email protected]_host:9306/federated/test_table';
Ou você pode simplificar o processo com a sintaxe CREATE SERVER, para que ao criar uma tabela atuando como seu SINÔNIMO para acessar uma tabela remota, seja mais fácil. Consulte a documentação para obter mais informações sobre isso.
Comportamento de String Vazia e NULL
Observe que no Percona Server / MySQL, a string vazia não é NULL, enquanto o Oracle trata a string vazia como valores nulos.
No Oráculo:
SQL> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
Nul
---
Yes
No MySQL:
mysql> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
+-----------+
| Null Eval |
+-----------+
| No |
+-----------+
1 row in set (0.00 sec)
Sequências
No MySQL, não há exatamente a mesma abordagem do que o Oracle faz para SEQUENCE.
Embora existam alguns posts que estão simulando a funcionalidade dessa abordagem, você pode tentar obter a próxima chave usando LAST_INSERT_ID() desde que o índice clusterizado da sua tabela, PRIMARY KEY, esteja definido com <
Funções de cadeia de caracteres
Ao contrário do Oracle, o MySQL / Percona Server tem um punhado de funções de string, mas não tantas funções úteis embutidas no banco de dados.
Seria muito longo discuti-lo aqui um por um, mas você pode verificar a documentação do MySQL e comparar isso com as funções de string do Oracle.
Declarações DML
As instruções Insert/Update/Delete do Oracle são congruentes no MySQL.
INSERIR TUDO/INSERIR PRIMEIRO da Oracle não é suportado no MySQL.
Caso contrário, você precisaria declarar suas consultas MySQL uma a uma.
por exemplo.
No Oráculo:
SQL> INSERT ALL
INTO CUSTOMERS (customer_id, customer_name, city) VALUES (1000, 'Jase Alagaban', 'Davao City')
INTO CUSTOMERS (customer_id, customer_name, city) VALUES (2000, 'Maximus Aleksandre Namuag', 'Davao City')
SELECT * FROM dual;
2 rows created.
2 linhas criadas.
Mas no MySQL, você precisa executar a inserção uma de cada vez:
mysql> INSERT INTO CUSTOMERS (customer_id, customer_name, city) VALUES (1000, 'Jase Alagaban', 'Davao City');
Query OK, 1 row affected (0.02 sec)
mysql> INSERT INTO CUSTOMERS (customer_id, customer_name, city) VALUES (2000, 'Maximus Aleksandre Namuag', 'Davao City');
Query OK, 1 row affected (0.00 sec)
O INSERT ALL/INSERT FIRST não se compara a como ele é usado no Oracle, onde você pode aproveitar as condições adicionando uma palavra-chave WHEN em sua sintaxe; não há opção equivalente no MySQL / Percona Server neste caso.
Portanto, sua solução alternativa para isso é usar procedimentos.
Símbolo "+" de junções externas
No Oracle, o uso do operador + para junções à esquerda e à direita não é suportado no momento no MySQL, pois o operador + é usado apenas para decisões aritméticas.
Portanto, se você tiver o operador + em suas instruções Oracle SQL existentes, precisará substituí-lo por LEFT JOIN ou RIGHT JOIN.
Você pode querer verificar a documentação oficial para "Outer Join Simplification" do MySQL.
COMEÇAR COM..CONECTAR POR
O Oracle usa START WITH..CONNECT BY para consultas hierárquicas.
A partir do MySQL / Percona 8.0, há suporte para gerar resultados de dados hierárquicos que usam modelos como lista de adjacências ou modelos de conjuntos aninhados. Isso é chamado de Common Table Expressions (CTE) no MySQL.
Semelhante ao PostgreSQL, o MySQL usa WITH RECURSIVE sintaxe para consultas hierárquicas, então traduza CONNECT BY declaração em COM RECURSIVO demonstração.
Confira abaixo como ele difere do ORACLE e do MySQL/Percona Server.
No Oráculo:
SELECT cp.id, cp.title, CONCAT(c2.title, ' > ' || cp.title) as path
FROM category cp INNER JOIN category c2
ON cp.parent_id = c2.id
WHERE cp.parent_id IS NOT NULL
START WITH cp.id >= 1
CONNECT BY NOCYCLE PRIOR c2.id=cp.parent_id;
E no MySQL:
WITH RECURSIVE category_path (id, title, path) AS
(
SELECT id, title, title as path
FROM category
WHERE parent_id IS NULL
UNION ALL
SELECT c.id, c.title, CONCAT(cp.path, ' > ', c.title)
FROM category_path AS cp JOIN category AS c
ON cp.id = c.parent_id
)
SELECT * FROM category_path
ORDER BY path;
PL/SQL em MySQL/Percona?
MySQL / Percona RDBMS tem uma abordagem diferente do PL/SQL da Oracle.
O MySQL usa procedimentos armazenados ou funções armazenadas, que são semelhantes a PL/SQL e sintaxe usando BEGIN..END sintaxe.
O PL/SQL da Oracle é compilado antes da execução quando é carregado no servidor, enquanto o MySQL é compilado e armazenado no cache quando é invocado.
Você pode querer verificar esta documentação como um guia de referência sobre como converter seu PL/SQL para MySQL.
Ferramentas de migração
Fiz algumas pesquisas para quaisquer ferramentas que pudessem ser um padrão de fato para migração, mas não consegui encontrar uma boa resposta.
No entanto, encontrei sqlines e parece simples, mas promissor.
Embora eu não tenha me aprofundado, o site oferece um punhado de insights, que podem ajudá-lo a migrar do Oracle para o MySQL/Percona Server. Existem também ferramentas pagas como esta e esta.
Também pesquisei no github, mas não encontrei nada muito mais atraente como solução para o problema. Portanto, se você pretende migrar do Oracle e para a Amazon, eles têm o AWS Schema Conversion Tool para o qual a migração do Oracle para o MySQL é compatível.
No geral, a razão pela qual a migração não é uma coisa fácil de fazer é principalmente porque o Oracle RDBMS é uma fera com muitos recursos que o Percona Server / MySQL ou o MariaDB RDBMS ainda não possuem.
De qualquer forma, se você encontrar ou souber de alguma ferramenta que considere útil e benéfica para migrar do Oracle para o MySQL/Percona Server, deixe um comentário neste blog!
Teste
Como parte de seu plano de migração, o teste é uma tarefa vital que desempenha um papel muito importante e afeta sua decisão em relação à migração.
A ferramenta dbdeployer (um porte do MySQL Sandbox) é uma ferramenta muito útil que você pode aproveitar. Isso é muito fácil para você tentar testar diferentes abordagens e economizar seu tempo, em vez de configurar toda a pilha se seu objetivo for tentar testar a plataforma RDBMS primeiro.
Para testar suas rotinas armazenadas de SQL (funções ou procedimentos), gatilhos, eventos, sugiro que você use essas ferramentas mytap ou o Unit Testing Framework do Google.
A Percona também oferece uma série de ferramentas que estão disponíveis para download em seu site. Confira o Percona Toolkit aqui. Você pode escolher as ferramentas de acordo com suas necessidades, especialmente para tarefas de teste e uso de produção.
No geral, as coisas que você precisa ter em mente como suas diretrizes ao fazer um teste para o seu servidor MySQL são:
- Após a instalação, você precisa considerar fazer alguns ajustes. Confira este blog da Percona para obter ajuda.
- Faça alguns benchmarks e testes de carga de estresse para sua configuração em seu nó atual. Confira mysqlslap e sysbench que podem ajudá-lo com isso. Confira também nosso blog "Como comparar o desempenho do MySQL e do MariaDB usando o SysBench".
- Verifique se seus DDLs estão definidos corretamente, como tipos de dados, restrições, índices clusterizados e secundários ou partições, se houver.
- Verifique seu DML especialmente se a sintaxe estiver correta e estiver salvando os dados corretamente conforme o esperado.
- Confira suas rotinas, eventos e gatilhos armazenados para garantir que eles executem/retornem os resultados esperados.
- Verifique se suas consultas em execução estão funcionando. Sugiro que você aproveite as ferramentas de código aberto ou experimente nosso produto ClusterControl. Oferece monitoramento/observabilidade especialmente do seu servidor MySQL/Percona. Você pode usar o ClusterControl aqui para monitorar suas consultas e seu plano de consulta para garantir que elas tenham desempenho.