Este documento faz parte de uma série que fornece informações importantes e orientações relacionadas ao planejamento e à execução de migrações de banco de dados Oracle® 11g/12c para Cloud SQL para MySQL versão 5.7, em instâncias de segunda geração. A série inclui as partes a seguir:
- Como migrar usuários do Oracle para o Cloud SQL para MySQL: terminologia e funcionalidade
- Como migrar usuários do Oracle para o Cloud SQL para MySQL: tipos de dados, usuários e tabelas
- Como migrar usuários do Oracle para o Cloud SQL para MySQL: consultas, procedimentos armazenados, funções e gatilhos
- Como migrar usuários da Oracle para o Cloud SQL para MySQL: segurança, operações, monitoramento e geração de registros (este documento)
Segurança
Nesta seção, explicamos as diferenças na criptografia de dados entre o Oracle Cloud SQL para MySQL e falamos sobre a auditoria do controle de acesso do Cloud SQL para MySQL.
Criptografia de dados da Oracle
Além da autenticação básica de usuários e do gerenciamento de privilégios de usuário, a Oracle oferece o mecanismo de criptografia de dados transparente (TDE, na sigla em inglês) para adicionar uma camada de criptografia extra para segurança de dados em repouso no nível do sistema operacional. Depois de configurado, o Oracle TDE é implementado pelo sistema automaticamente e não requer nenhuma interação manual dos usuários. Para implementar o Oracle TDE, recomendamos configurá-lo explicitamente (por comando) nos objetos de banco de dados obrigatórios e compatíveis, que podem aceitar esse tipo de criptografia, por exemplo, tabelaspace, tabela ou coluna. Para lidar com a segurança de dados em trânsito, recomendamos que você implemente uma solução de segurança de rede.
Criptografia de dados do Cloud SQL para MySQL
O Google Cloud fornece várias camadas de criptografia para proteger os dados do cliente em repouso nos produtos do Google Cloud, incluindo o Cloud SQL. O Cloud SQL é criptografado usando o padrão AES-128 ou AES-256. Para mais informações, consulte o tópico a seguir sobre criptografia em repouso. Ao contrário da criptografia da Oracle (que precisa ser implementada por meio de ações de configuração), o Google Cloud criptografa os dados do cliente em repouso, sem nenhuma ação necessária. Do ponto de vista da conversão de esquema, nenhuma ação é necessária, e a criptografia permanece transparente para o usuário.
Para entender melhor como o Google Cloud lida com a criptografia de dados em trânsito, consulte Como a criptografia é gerenciada para dados em trânsito.
Auditoria
A Oracle fornece vários métodos de auditoria, como a padrão e a refinada. Por outro lado, por padrão, o MySQL não fornece soluções de auditoria equivalentes. Para superar essa limitação, use os painéis e o monitoramento do Google Cloud, mas, para capturar operações DML/DDL do banco de dados, use os registros de consulta lenta, geral e de erro como uma solução de auditoria mais robusta.
Para implementar essa solução, recomendamos que você use a instância
FLAGS para ativar o registro de consulta lenta e o registro geral. Além disso, você
precisa gerenciar a retenção desses registros de acordo com suas necessidades de negócios.
Use os registros de auditoria do Google Cloud para coletar informações de auditoria. Esses registros abrangem três níveis principais:
- Registros de auditoria de atividade do administrador (ativados por padrão)
- Registros de auditoria de acesso a dados (desativados por padrão)
- Leia sobre como configurar registros de acesso a dados.
- Os registros de auditoria de acesso a dados não registram operações desse tipo em recursos que podem ser acessados sem fazer login no Google Cloud.
- Registros de auditoria de eventos do sistema (ativados por padrão)
Como visualizar registros de auditoria do Google Cloud
Este é o caminho de acesso para visualizar registros de auditoria: Console do Google Cloud > Início > Atividade
É possível filtrar a granularidade de informações entre os níveis de auditoria. A captura de tela a seguir mostra uma auditoria de atividade do administrador.
Página do Cloud Logging
Este é o caminho de acesso para a página de geração de registros: Console do Google Cloud > Cloud Logging
É possível filtrar a granularidade de informações entre os tipos de registro. A captura de tela a seguir mostra uma auditoria de registro geral (dados de auditoria para usuário, host e instrução SQL).
Controle de acesso do Cloud SQL para MySQL
Os usuários podem se conectar à instância do Cloud SQL para MySQL usando um cliente MySQL com um endereço IP estático autorizado ou usando o Cloud SQL Proxy, de maneira semelhante a qualquer outra conexão de banco de dados. Para outras fontes de conexão, como o App Engine ou o Compute Engine, os usuários têm várias opções, como o Cloud SQL Proxy. Essas opções são descritas com mais detalhes em Controle de acesso à instância.
Operações
Nesta seção, falaremos sobre a exportação e importação, o backup e a restauração no nível da instância, o programador de eventos do MySQL (para jobs de banco de dados) e as instâncias em espera para operações somente leitura e recuperação de desastres.
Exportar e importar
O principal método da Oracle para executar operações lógicas de exportação e importação é o
utilitário Data Pump, usando o método EXPDP/IMPDP. Uma versão mais antiga da
funcionalidade de exportação/importação da Oracle incluía o exp e imp. Os
comandos equivalentes do MySQL são os utilitários mysqldump e mysqlimport,
que geram arquivos dump e realizam a importação no nível do banco de dados ou do
objeto (incluindo a exportação e importação de metadados).
Não há uma solução equivalente direta do MySQL para o utilitário Oracle DBMS_DATAPUMP,
o método Oracle para aplicar a funcionalidade EXPDP/IMPDP
que interage diretamente com o pacote DBMS_DATAPUMP. Para converter
do código Oracle DBMS_DATAPUMP PL/SQL, use
um código alternativo (por exemplo, Bash ou Python) para implementar elementos
lógicos e use MySQL mysqldump e mysqlimport para executar operações de
exportação/importação.
Os utilitários mysqldump e mysqlimport do MySQL são executados no nível do cliente, como
parte dos
programas clientes
do MySQL, conectando-se remotamente à instância do Cloud SQL para MySQL. Os arquivos dump são
criados no lado do cliente.
mysqldump:
Um utilitário cliente executa backups lógicos e importações de dados (como sql). Isso
produz um conjunto de instruções SQL que podem ser executadas para reproduzir as definições originais
do objeto do banco de dados e os dados da tabela. O utilitário mysqldump também pode
gerar saída no formato CSV, em outro texto delimitado ou em formato XML. A
principal vantagem desse formato de saída é que ele permite que você visualize ou edite a saída de exportação
antes de restaurar, porque é um arquivo de texto. A principal desvantagem é que
ele não é uma solução rápida ou escalonável para fazer backup de quantidades
significativas de dados.
Uso do mysqldump:
-- Single database backup & specific tables backup # mysqldump database_name > outpitfile.sql # mysqldump database_name tbl1 tbl2 > outpitfile.sql -- Back up all databases # mysqldump --all-databases > all_databases.sql -- Ignore a given table # mysqldump --databases db1 --ignore-table db1.tbl > outpitfile.sql -- Back up metadata only - Schema only # mysqldump --no-data db1 > bck.sql -- Include stored procedures and functions (routines) # mysqldump db1 --routines > db1.sql -- Back up only rows by a given WHERE condition # mysqldump db1 tbl1 --where="col1=1" > bck.sql -- Include triggers for each dumped table (default) # mysqldump db1 tbl1 —triggers > bck.sql
mysqlimport:
Este é um programa cliente que fornece uma interface de linha de comando para a instrução SQL LOAD
DATA INFILE. mysqlimport é usado com frequência para importar
dados de um arquivo de texto ou CSV para uma tabela MySQL com uma estrutura correspondente.
O Carregador Oracle SQL*Loader pode ser convertido em mysqlimport porque ambos compartilham a mesma
funcionalidade de carregamento de dados de um arquivo externo.
Uso do mysqlimport:
-- Example of loading data from a CSV file into a table:
-- Create a table named csv_file
mysql> create table file(col1 int, col2 varchar(10));
-- Create a CSV file (delimited by tab)
# echo 1 A > file.csv
# echo 2 B >> file.csv
# echo 3 C >> file.csv
-- Import the CSV file into the csv_file table
-- Note that the file and table name must be named identically
# mysqlimport -u USER -p -h HOSTNAME/IP DB_NAME --local file.csv
csv_file: Records: 3 Deleted: 0 Skipped: 0 Warnings: 0
-- Verify
# mysql -u USER -p -h HOSTNAME/IP DB_NAME -e "SELECT * FROM file"
+------+------+
| col1 | col2 |
+------+------+
| 1 | A |
| 2 | B |
| 3 | C |
+------+------+
-- Example of using LOAD DATA INFILE to load a CSV file (using the same
table from the previous example, with the CSV delimiter defined by
comma)
mysql> LOAD DATA LOCAL INFILE 'file.csv' INTO TABLE file
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n' (col1, col2);
mysql> SELECT * FROM file;
+------+------+
| col1 | col2 |
+------+------+
| 1 | A |
| 2 | B |
| 3 | C |
+------+------+
Exportação/importação do Cloud SQL para MySQL:
Os links da documentação a seguir ilustram como usar o gsutil/gcloud para
interagir com a instância do Cloud SQL e com o Cloud Storage para
aplicar
as operações de
exportação
e
importação.
Backup e restauração no nível da instância
É uma operação simples para migrar do Oracle RMAN ou do Data Pump e incluir mais opções de backup e restauração (por exemplo, instantâneos de VM, backup frio ou ferramentas de terceiros) para o Cloud SQL para MySQL. Nenhum outro código ou conhecimento é necessário. Gerencie esse processo usando o console do Google Cloud ou a Google Cloud CLI. Os exemplos anteriores foram compilados com instâncias do Cloud SQL de segunda geração.
Os tipos de métodos de backup do banco de dados MySQL são backups sob demanda e backups automáticos.
Use a restauração da instância do banco de dados do Cloud SQL para MySQL para restaurar a mesma instância, substituir os dados atuais ou restaurar para uma instância diferente. O Cloud SQL para MySQL também permite restaurar um banco de dados MySQL para um momento específico usando a geração de registros binários com a opção de backup automatizado ativada.
O Cloud SQL para MySQL permite clonar uma versão independente do banco de dados de origem. Esse recurso se aplica somente ao banco de dados primário (mestre) ou a outro clone e não pode ser retirado de uma instância de réplica de leitura. Também é possível usar esse recurso para restaurar uma instância do MySQL a partir de um ponto no tempo, permitindo a recuperação de dados, se necessário. É possível aplicar a restauração do banco de dados do Cloud SQL para MySQL usando o console do Google Cloud ou a CLI gcloud.
Programador de eventos do MySQL (jobs de banco de dados)
Para iniciar procedimentos predefinidos do banco de dados, a funcionalidade do
programador de eventos
do MySQL é equivalente ao Oracle DBMS_JOBS ou ao Oracle DBMS_SCHEDULER. Por padrão, o
parâmetro de banco de dados event_scheduler é definido como OFF. Se necessário,
mude-o para ON usando sinalizações
do Cloud SQL.
Use o programador de eventos do MySQL para executar um comando DML/DDL explícito ou programar uma função ou procedimento armazenado em um horário específico e com uma determinada lógica.
Consideração de conversão para Oracle DBMS_JOBS ou DBMS_SCHEDULER:
Todos os jobs da Oracle precisam ser convertidos em sintaxe e funcionalidade do MySQL manualmente ou usando ferramentas de conversão PL/SQL disponíveis comercialmente.
Use a seguinte instrução para verificar o valor atual do parâmetro event_scheduler
de uma execução do cliente:
mysql> SHOW VARIABLES LIKE '%event_s%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| event_scheduler | ON |
+-----------------+-------+
Exemplos do programador de eventos:
Oracle DBMS_SCHEDULER
SQL> BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'job_sessions_1d_del', job_type => 'PLSQL_BLOCK', job_action => 'BEGIN DELETE FROM sessions WHERE session_date < SYSDATE - 1; END;', start_date => SYSTIMESTAMP, repeat_interval => 'FREQ=DAILY', end_date => NULL, enabled => TRUE, comments => 'Deletes last day data from the sessions table'); END; /Conversão de eventos do MySQL:
mysql> CREATE EVENT job_sessions_1d_del ON SCHEDULE EVERY 1 DAY COMMENT 'Deletes last day data from the sessions table' DO DELETE FROM sessions WHERE session_date < DATE_SUB(SYSDATE(), INTERVAL 1 DAY);Metadados do programador de eventos do MySQL:
mysql> SELECT * FROM INFORMATION_SCHEMA.EVENTS \G; -- OR mysql> SHOW EVENTS FROM HR;
Instâncias em espera para operações somente leitura e implementação de recuperação de desastres
O Oracle Active DataGuard permite que uma instância em espera atue como um endpoint somente leitura enquanto os novos dados ainda estão sendo aplicados por meio dos registros de refazer e arquivar. Também é possível usar o Oracle GoldenGate para ativar mais uma instância para fins de leitura enquanto as modificações de dados são aplicadas em tempo real, servindo como uma solução de captura de dados de alteração (CDC, na sigla em inglês).
O Cloud SQL para MySQL é compatível com a separação de leitura/gravação usando réplicas de leitura para direcionar todas as leituras ou cargas de trabalho analíticas a partir de uma fonte alternativa quase em tempo real. É possível aplicar configurações para réplicas de leitura do Cloud SQL para MySQL usando o console do Google Cloud ou a ferramenta.
O Cloud SQL para MySQL é compatível com outras opções de replicação: replicar para uma instância externa do MySQL e replicar de uma instância externa do MySQL.
É possível implementar o Oracle Active DataGuard e o Oracle GoldenGate como uma solução de recuperação de desastres (DR), adicionando uma instância em espera já sincronizada com a instância principal.
As réplicas de leitura do Cloud SQL para MySQL não servem como instâncias em espera para cenários de DR. Para isso, o Cloud SQL permite configurar uma instância do MySQL para alta disponibilidade (usando o console do Google Cloud ou a CLI gcloud).
Algumas operações podem exigir uma reinicialização da instância, por exemplo, a adição de alta disponibilidade a uma instância principal. A partir da perspectiva de um SLA de alta disponibilidade (HA, na sigla em inglês), se a primária não responder por aproximadamente 60 segundos, a instância de espera de alta disponibilidade estará disponível após a reconexão. Para ativar a alta disponibilidade para o Cloud SQL para MySQL, consulte estas instruções.
Registro e monitoramento
O arquivo de registros de alerta da Oracle é a principal fonte para identificar eventos gerais do sistema e eventos de erro para entender qualquer ciclo de vida da instância do banco de dados da Oracle, principalmente para solucionar problemas de eventos de falha e de erro.
O registro de alertas da Oracle exibe informações sobre o seguinte:
- Erros e avisos da instância do banco de dados Oracle (
ORA-+ número do erro). - Eventos de inicialização e encerramento da instância do banco de dados Oracle.
- Problemas relacionados a rede e conexão.
- Eventos de alternância de registros de refazer do banco de dados.
- Os arquivos de rastreamento da Oracle podem ser mencionados com um link para mais detalhes sobre um evento de banco de dados específico.
Além disso, a Oracle fornece arquivos de registro dedicados para diferentes serviços, como LISTENER, ASM e Enterprise Manager (OEM), que não têm componentes equivalentes no Cloud SQL para MySQL.
Tipos de registro do Cloud SQL para MySQL:
| Tipo de registro do MySQL | Descrição | Observações |
|---|---|---|
| Registro de atividades | Contém dados sobre chamadas de API ou outras ações administrativas que modificam a configuração ou os metadados de uma instância do Cloud SQL para MySQL. | Esse é um dos três registros no grupo do Cloud Audit Logs. |
| Registro de acesso a dados | Contém dados sobre chamadas de API que leem a configuração ou os metadados de recursos, bem como chamadas de API orientadas pelo usuário que criam, modificam ou leem dados de recursos fornecidos pelo usuário. | Esse é um dos três registros no grupo do Cloud Audit Logs. Esse registro grava apenas operações de acesso a dados em instâncias do MySQL para eventos que podem ser acessados sem fazer login no Google Cloud. |
mysql.err |
Este é o arquivo de registro principal do MySQL, que pode ser comparado com o registro de alertas da Oracle. Os dois registros contêm eventos da instância do banco de dados, inicialização e desligamento, além de eventos de erro e aviso. | Guia de mensagens de erro do MySQL 5.7. |
mysql-slow.log |
O registro de consulta lenta do MySQL coleta dados em consultas que excedem a configuração predefinida, como cada consulta que tem um ambiente de execução maior que 2 segundos (o padrão é 10 segundos). | Essa configuração está desativada por padrão. Para ativar esse registro, defina as seguintes variáveis (parâmetros do banco de dados):
|
mysql-general.log |
Esse registro
coleta dados sobre conexões e desconexões de clientes e em qualquer instrução SQL
executada na instância do banco de dados MySQL. Esse registro é útil para
solucionar problemas e geralmente é alternado para OFF quando a operação
é concluída. |
Desativado por padrão. Para ativar as variáveis general_log,
deve ser definido como ON. |
| Registro binário | O servidor MySQL usa a geração de registros binários para gravar todas as instruções que modificaram dados. Esse registro é usado principalmente para backup e replicação. | Por padrão, o parâmetro de geração de registros binários é ativado no
Cloud SQL para MySQL para permitir a recuperação e a implantação de réplicas de leitura.
Para ativar a geração de registros binários, defina o parâmetro de configuração log_bin como
ON. |
| Registro de redirecionamento | Mantém as instruções recebidas dos registros binários primários para implementar todas as modificações de dados na instância subordinada (réplica de leitura). | Aplica-se apenas a instâncias secundárias (escravas) e réplicas de leitura. |
Como visualizar registros de operação do Cloud SQL para MySQL
O Cloud Logging é a plataforma principal para visualizar todos os detalhes do registro. É possível selecionar registros diferentes e filtrar por nível de evento de registro (por exemplo, crítico, erro ou aviso). O período do evento e a filtragem de texto livre também estão disponíveis.
Exemplo
A captura de tela a seguir mostra como encontrar uma consulta específica no
arquivo mysql-slow.log usando um período personalizado como um critério de filtro.
Monitoramento da instância do banco de dados MySQL
Os principais painéis de monitoramento da IU da Oracle fazem parte dos produtos OEM e Grid/Cloud Control (por exemplo, gráficos de atividades principais) e são úteis para o monitoramento de instâncias de banco de dados em tempo real no nível da sessão ou da instrução SQL. O Cloud SQL para MySQL fornece recursos de monitoramento semelhantes usando o console do Google Cloud. É possível ver informações resumidas sobre as instâncias do banco de dados do Cloud SQL para MySQL com várias métricas de monitoramento, como uso da CPU e de memória, operações de leitura/gravação, bytes de entrada/saída, conexões ativas e muito mais.
O Cloud Logging é compatível com outras métricas de monitoramento do Cloud SQL para MySQL. A captura de tela a seguir mostra o gráfico de consultas do MySQL das últimas 12 horas.
Monitoramento de réplica de leitura do MySQL
É possível monitorar réplicas de leitura de maneira semelhante a uma instância principal usando as métricas de monitoramento do console do Google Cloud, conforme descrito anteriormente. Além disso, há uma métrica de monitoramento dedicada para monitorar o atraso de replicação, determinando o atraso entre a instância primária e a instância de réplica de leitura em segundos (pode ser monitorado a partir da guia de visão geral da instância de réplica de leitura no console do Google Cloud).
Use a CLI gcloud para recuperar o status de replicação:
gcloud sql instances describe REPLICA_NAME
Também é possível fazer o monitoramento de replicação usando comandos de um cliente MySQL, que fornece um status para os bancos de dados primário e subordinado e para o registro binário e o registro de redirecionamento.
Use a seguinte instrução SQL para verificar o status da réplica de leitura:
mysql> SHOW SLAVE STATUS;
Monitoramento do MySQL
Esta seção descreve métodos básicos de monitoramento do MySQL que são considerados tarefas rotineiras realizadas por um DBA (Oracle ou MySQL).
Monitoramento de sessão
O monitoramento de sessão da Oracle é feito consultando as visualizações de desempenho dinâmico
conhecidas como visualizações "V$". As visualizações V$SESSION e V$PROCESS são usadas com frequência para receber insights em tempo real sobre a atividade atual do banco de dados, usando instruções
SQL. É possível monitorar a atividade da sessão no MySQL usando comandos e
instruções SQL. Por exemplo, o comando
SHOW PROCESSLIST
do MySQL fornece os seguintes detalhes sobre a atividade da sessão:
mysql> SHOW PROCESSLIST;
Também é possível consultar e filtrar os resultados de SHOW PROCESSLIST usando uma
instrução SELECT:
mysql> SELECT * FROM information_schema.processlist;
Monitoramento de transações longas
Para identificar transações de longa duração em tempo real que podem levar
a problemas de desempenho, consulte a
visualização dinâmica
information_schema.innodb_trx. Essa visualização mostra registros apenas para transações abertas em
execução na instância do banco de dados MySQL.
Monitoramento de bloqueio
É possível monitorar bloqueios de banco de dados usando a visualização dinâmica
information_schema.innodb_locks,
que fornece informações em tempo real sobre ocorrências de bloqueio
que podem levar a problemas de desempenho.