Via ssh eu consigo fazer
16:07blz
16:07Deu certo
16:46?
16:46Chegou ver a ideia do novo cluster ?
16:47Bom dia meu amigo
10:47Blz?
10:47Bom diaaa
11:32to lendo aqui
11:32Acho que vai ficar muito bom e com segurança melhor
11:33eu to lendo sobre as ferramentas novas
11:34sim, com certeza
11:36seria interessante ter um load balancer para os apps tbm né?
11:37Existe o gargalo do db, mas também existe o gargalo do apache
11:37hj o load balancer é por round robin no dns
11:37Então, a primeira fase a gente faz o cluster e depois vamos para os apps
11:37O que acha?
11:37se o dns mandar todo mundo para um app com o apache 100% estressado, o app fica fora do ar
11:38sim, pode ser
11:38Além do que trazendo para o Brasil já vai economizar de cara 10%
11:39eu sabia da existência do load balancer oficial do mariadb (MariaDB MaxScale) mas é pago acima de X nodes
11:39Já o ProxySQL também é indicado na documentação do mariadb e tem a vantagem de poder utilizar grátis sem suporte né
11:39Sim, tava estudando e acho que vai ficar legal e ainda podemos montar um Dashboard para acompanhar
11:40já o garbd não conhecia, achei genial.
11:40É um gambiarrinha para se ter nodes em par kkkkk
11:40mas super funciona
11:40Kkkkk
11:41ele serve só para "arbitrar" e compor um cluster de 3 nodes
11:41ele simula um nó de banco de dados, mas não é um db
11:41kkk
11:41Depois vai faltar só o visitas
11:41vc tá amando os dashboards feitos com IA né kkk
11:41Sim cara, ajuda demais na tomada de decisão
11:42Adicione nos próximos passos a atualização do DB. A versão atual é bem antiga (10.1.22). Para chegar no 10.11 são vários e vários releases
11:43não vai ser só instalar, mas fazer upgrade e testar
11:43creio que será necessário mexer na estrutura do banco de dados (tabelas, tipos de campos)
11:44Então, vou atualizar tanto o dB quanto o sistema operacional
11:44normalizar alguns tipos de dados
11:44talvez modificar consultas no código php
11:44por isso, vai ter que fazer por etapas a atualização do db
11:45talvez instalar uma instalação nova e vazia, e ir importando os dados das tabelas
11:45Nisso a gente deve ganhar desempenho , certo?
11:45em vez de pegar e atualizar o db que já existe
11:45tipo assim... fazer do zero e importar as tabelas/dados
11:45com certeza
11:45acho que assim é mais confiável
11:45acredito que isso será a parte mais complexa do planejamento, pois envolve manipular os dados
11:46não se pode perder dados ou ainda ter os dados modificados durante a migração
11:46cara, você não teve boas experiências com o docker?
11:47O que vc pensa em fazer?
11:47porque neste caso ele iria ganhar bastante tempo, na questão de instalar uma imagem em vários servidores
11:47ainda mais sem cpanel para modificar o ambiente/comportamento padrão do servidor
11:47[Audio transcrito] Porque uma coisa que eu vejo, que sempre atrapalha a gente, é que são três bancos de dados. Aí a gente tem que alterar o IP, alterar uma configuração, alterar alguma coisa em um, aí tem que replicar no-nos outros dois. Só que muitas vezes a gente esquece, tanto eu quanto você. Cada um na sua área, mas a gente esquece. Agora, a gente vai ter-- não tô com o arquivo aberto aqui, mas uns seis bancos de dados, vai ter banco de dado pra caramba, em servidores diferentes, em vários servidores, né? Tem-- corre o risco da gente esquecer e-e vai ficar cada vez mais difícil fazer essa manutenção. Eu acredito que o Docker, pelo que eu sei, eu nunca mexi com o Docker não, mas assim, na teoria, você cria uma imagem e vai exportando essa imagem ou vai rodando essa imagem, ou alguma coisa assim, talvez ajudaria. O que que cê acha?
11:48Então, mas sempre vai barrar no ip, penso da gente criar um mcp para controlar isso em um único lugar
11:50mcp de ia vc fala?
11:50Mcp controloador mesmo , onde ficar todos os ips , todos os dados caso a gente precise
11:51não conheço esse mcp
11:52Mas é de boa
11:52sabe o significa da sigla?
11:52Vai ser cluster sim
11:56Ahh tá, então beleza
11:57Só que a sincronização é diferente para não travar
11:57- Um cluster em SP com 4 nodes + garbd - Um cluster em USA com 2 nodes + garbd
11:57Dúvida: caso de uma falha no Cluster USA, vamos utilizar o Cluster SP. Neste caso, dados terão que ser inseridos no cluster SP. Como sincronizar depois os dados novos para o cluster USA quando ele voltar ao ar?
11:58Dúvida: o ProxySQL também consegue orquestrar o Cluster SP?
11:59Ele entrando no cluster já atualiza
11:59Sim
11:59Antes da gente migrar os dados vc testa
11:59Dúvida: o ProxySQL também pode falhar (ou seja, ele também é um ponto de falha)? Se sim, o que acontece com a aplicação? Tem alguma mitigação?
11:59Então, eu levantei isso, e ele disse que direciona sozinho, mas a gente vai ver na prática
12:01Quero ver isso rodando
12:01A gente simula várias coisas antes de virar
12:01Vc tem um mode teste se não tem?
12:01Mas testamos quando subir
12:031 cluster só
12:09Desculpe o podcast! kkkkk
12:21de resto, eu super concordo com o planejamento
12:21acredito que algumas coisas iremos descobrir durante os testes
12:22mas no geral, a estrutura tem que ser essa mesmo
12:22A parte do backup está bem protegida mesmo, vários níveis. Muito bom
12:22também poderia utilizar o github para isso, mas aí, todos os arquivos de config, _.sh_, executáveis, sei lá, tem que estar dentro de um diretório padrão no servidor, para que possam ser salvos no github (diretório do projeto)
12:23A gente pode fazer tb, estou usando para meus projetos
12:35pra quando você está pensando em implementar isso?
14:12eu ja pedi os servidores, assim que subir a gente inicia os testes, acredito que em 30 dias... eles liberam 1, e depois o outro , vou estudar uma forma de ficar mais facil virar os servidores em caso necessario.. o bom agora com a IA, que eu posso perguntar para ela 1000x e ela nao fica brava
14:14kkkkkkkk
14:14"o bom agora com a IA, que eu posso perguntar para ela 1000x e ela nao fica brava" por enquanto!
14:14kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
14:15eu so nao xingo ela
14:15beleza, eu ia falar para a gente fazer lá pro meio de Agosto
14:15kkkkkk
14:15kkkkkk
14:15