Configuração do MySQL como Camada de Persistência Segura

No ecossistema do HarmonyOS Next, o repositório privado ohpm-repo é o componente central para a gestão de dependências. Para garantir a integridade dos metadados, a utilização do MySQL é recomendada em detrimento do armazenamento em arquivos locais para ambientes de produção. #### Parametrização do Banco de Dados

A integração é realizada através do arquivo config.yaml. É uma boa prática de segurança utilizar contas de serviço com permissões restritas em vez da conta root. ``` db: type: mysql config: host: "10.0.0.50" port: 3306 username: "ohpm_service_user" password: "StrongPassword_123" database: "ohpm_metadata"

Para mitigar riscos, o usuário `ohpm_service_user` deve possuir privilégios apenas de `SELECT`, `INSERT`, `UPDATE` e `DELETE` no schema específico do repositório. #### Criptografia de Dados Sensíveis

Caso existam metadados críticos que exijam uma camada extra de proteção, é possível aplicar criptografia a nível de coluna diretamente no MySQL utilizando funções nativas como `AES_ENCRYPT`. ```
-- Estrutura para armazenamento de metadados sensíveis
CREATE TABLE registry_secrets (
    sec_id INT AUTO_INCREMENT PRIMARY KEY,
    identifier VARCHAR(100) NOT NULL,
    payload_blob VARBINARY(512)
);

-- Inserção com criptografia simétrica
INSERT INTO registry_secrets (identifier, payload_blob)
VALUES ('secret_token_v1', AES_ENCRYPT('valor_confidencial', 'chave_mestra_789'));

-- Recuperação e descriptografia
SELECT identifier, AES_DECRYPT(payload_blob, 'chave_mestra_789') AS decrypted_content
FROM registry_secrets;

Extensibliidade via Plugins de Armazenamento

O ohpm-repo permite a implementação de drivers de armazenamento customizados quando as soluções nativas não atendem a requisitos corporativos específicos (como integração com S3 ou storages proprietários). ``` store: type: custom config: export_name: "CloudStorageProvider" plugin_path: "lib/plugins/CloudStorageProvider" endpoint: "https://s3.region.amazonaws.com" bucket: "harmonyos-repo-data"

### Arquitetura de Alta Disponibilidade (HA)

Para suportar fluxos intensos de CI/CD e garantir que o repositório permaneça on line, é necessário implementar uma arquitetura multi-instância. #### Sincronização e Consistência de Dados

A consistência entre múltiplas instâncias do ohpm-repo depende da replicação do banco de dados MySQL. Em um cenário de Replicação Primário-Secundário (Master-Slave): 1. No servidor **Primário**, habilite o log binário no arquivo `my.cnf`: ```
[mysqld]
log-bin=mysql-bin
server-id=101

2. Crie o usuário de replicação com as devidas permissões: ``` CREATE USER 'sync_worker'@'%' IDENTIFIED BY 'repl_pass'; GRANT REPLICATION SLAVE ON . TO 'sync_worker'@'%'; FLUSH PRIVILEGES;

3. No servidor **Secundário**, configure um ID exclusivo e aponte para o primário: ```
[mysqld]
server-id=102

CHANGE MASTER TO
MASTER_HOST='10.0.0.50',
MASTER_USER='sync_worker',
MASTER_PASSWORD='repl_pass',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;

START SLAVE;

Balanceamento de Carga com Nginx

Para distribuir as requisições entre as instâncias do ohpm-repo, utiliza-se um balanceador de carga. O Nginx é uma escolha eficiente para gerenciar o tráfego HTTP/HTTPS. ``` upstream ohpm_cluster { server 192.168.1.10:8088 weight=5; server 192.168.1.11:8088 weight=5; }

server { listen 443 ssl; server_name repo.internal.company.com;

location / {
    proxy_pass http://ohpm_cluster;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_connect_timeout 60s;
}

}

### Estratégias de Backup e Disaster Recovery

#### Automação de Backups

A perda de dados em um repositório privado pode paralisar o desenvolvimento. Um script Bash agendado via `crontab` garante a disponibilidade de cópias de segurança atualizadas. ```
#!/bin/bash
# Script de Backup ohpm-repo
DEST_PATH="/mnt/backups/mysql"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
DB_NAME="ohpm_metadata"

mkdir -p $DEST_PATH
mysqldump -u ohpm_admin -p'Admin_Pass' $DB_NAME > $DEST_PATH/dump_$TIMESTAMP.sql

# Retenção: remove arquivos com mais de 30 dias
find $DEST_PATH -name "*.sql" -mtime +30 -exec rm {} \;

Para agendar a execução diária às 03:00 AM: ``` 0 3 * * * /usr/local/bin/db_backup.sh

#### Procedimento de Recuperação

Em caso de falha catastrófica, o processo de restauração envolve a criação do banco de dados e a importação do último dump válido: ```
mysql -u ohpm_admin -p ohpm_metadata < /mnt/backups/mysql/dump_20231027_030000.sql

É altamente recomendável realizar testes de restauração trimestralmente para validar a integridade dos arquivos de backup e o tempo de recuperação (RTO).