🍀Seu apoio é crucial para mantermos o canal independente e continuarmos a produzir os conteúdos com a qualidade que você já conhece: pix@uminventorqualquer.com.br ⚜ Curso Cloud Computing Premium: www.cloudstorm.academy/ 💬 Comunidade Cloud no Discord: www.cloudstorm.club/
Cara que conteudo Rico ! Achei otimo, sem muita graça, direto ao ponto, bem explicado, sem puxar sadinha para AWS ! Vou começar a ver mais os seus videos. Parabéns
ou , curto seu canal demais ,cara aquela serie sua me ajudou e ajuda até hj . nunca te agradeci mas obrigado e se algum dia vc ler e achar interessante ja que está tão em alta muiltcloud gcp e aws , azure e aws e a mega de banco de dados oracle aws. Abraço fica com Deus e este canal abriu minha mente não cursos comprados foi este canal.(eu estudei vpc e não sacava muito mas com sua aula de vpc aquilo fixou na cabaça.
Eu que agradeço por prestigiar nosso conteúdo Maurício. E sim, multi-cloud é o caminho, uso GCP, AWS e outros derivados em muitos projetos, a junção deles traz os melhores resultados
Obrigado Luiz. Em tese ele vai suportar, mas dependendo da engine (MySQL/Postgres) você precisa controlar o tamanho do índice se estiver tudo em uma tabela, essa parte pode consumir bastante recurso para se otimizar, mas há muitas soluções possíveis, entre elas o particionamento da tabela.
Milan, se não for pedir muito explica pra gente sobre as possibilidades do Aurora v2 porém com o bd MS-Sql server. E qual seria o serviço simular da Azure específico pra esse bd.
Alairton, o Aurora Serverless V2 só suporte MySQL e Postgres atualmente, e infelizmente não conheço os serviços de banco do Azure para poder te dar essa informação
Tentei usar pouco tempo após o lançamento mas sempre que ia escalar pra cima começava a estourar limite de conexões e travava. Nem reboot funcionava. Tinha que criar um banco provisionado no cluster e promover a principal pra poder voltar a funcionar a aplicação. Meses depois tentei de novo, mesma coisa. Por fim desisti e estou usando o provisionado mesmo.
Excelente conteúdo como sempre! Esperando pelo video explicando os custos, tenho uma aplicação rodando com RDS Postgree em uma instancia T4G.MEDIUM porém esta começando a sofrer em momentos de picos, estou pensando em mudar para o Aurora, porém ainda não consegui entender muito bem o calculo de custos para ter uma previsão como consigo ter com a instancia atual, se compensa migrar nesse tamanho que estou agora ou se seria melhor partir para uma instancia acima que me traria uma folga para o momento atual e seria mais barato do que o Aurora V2...
Precisa dar uma atenção especial quanto ao uso de conexoes persistentes pra não sobrecarregar a memória do serverless, usar conexões temporárias é muito mais barato ;)
Acho que vai me servir esse DB, pois tenho uma aplicação que hoje não se paga, e se colocar ela no lambda com esse aurora v2 acho que consigo fazer uma aplicação 100% serventes e reduzir brutalmente os custos
Mas o V1 dá downtime sim, ela escala várias vezes quanto está em um determinado ponto muito próximo entre as 2 units, e nesse momento de escala a aplicação cai, pois o banco não responde. A única solução que encontrei foi fazer via API, alterar os units em determinados horários, porem paguei o preco de excesso as vezes, pois é imprevisível, algo que no final vale a pena, pois o mais importante é a aplicação ficar estável. Acredito que o V2 não seja assim, estou me preparando para testá-lo.
Oi Felipe, acredito que sua instância do V1 estava configurada para entrar em stand-by quando ociosa, esse erro é comum pois a opção vem marcada por default no formulário de criação, enfrentei esse problema também até descobrir esse detalhe, depois disso sem downtime de 1 a 128 units durante anos. Espero ter ajudado
@@GaragemDoInventor So que acontecia em horário de pico, por escalar a todo momento ela sempre fazia a aplicação cair por não responder por alguns segundos, isso já causa uma briga grande, pois os clientes pensam que caiu total.
@@filipemontt compreendo, passei pelo mesmo problema, não sei qual linguagem você está usando, mas essa incompatibilidade ocorre com conexões persistentes, no meu caso foi com NodeJS, mas com conexões voláteis como PHP por exemplo, eu vi funcionar bem, pois a cada requisição ele estabelece um novo socket, e isso fazia a API do V1 acordar o banco, mesmo assim tinha um delay. Ainda bem que no V2 isso não tem mais, agora é só alegria
🍀Seu apoio é crucial para mantermos o canal independente e continuarmos a produzir os conteúdos com a qualidade que você já conhece: pix@uminventorqualquer.com.br
⚜ Curso Cloud Computing Premium: www.cloudstorm.academy/
💬 Comunidade Cloud no Discord: www.cloudstorm.club/
Cara que conteudo Rico ! Achei otimo, sem muita graça, direto ao ponto, bem explicado, sem puxar sadinha para AWS ! Vou começar a ver mais os seus videos. Parabéns
Excelente conteúdo, muito didático. parabéns.
Parabéns pelo excelente conteúdo aqui no TH-cam nesse nível são poucos!
Gostaria de agradecer pelo conteúdo Aurora RDS V2. Muito bom parabéns pela didática.
Obrigado Arquimedes, eu que agradeço por assistir, TMJ
Tem muito cara bom no TH-cam, mas didática melhor que a sua, eu ainda não vi.
Parabéns
Valeu Vagner🙏
Vagner entra no nosso Discord pra trocar umas ideias legais www.cloudstorm.club/
Didática sensacional! Continua com esses conteúdos da Aws!
Valeu Suel! TMJ
Parabéns pelo conteúdo!
Muito obrigado
ótimo vídeo!
Obrigado 😃
ou , curto seu canal demais ,cara aquela serie sua me ajudou e ajuda até hj . nunca te agradeci mas obrigado e se algum dia vc ler e achar interessante ja que está tão em alta muiltcloud gcp e aws , azure e aws e a mega de banco de dados oracle aws. Abraço fica com Deus e este canal abriu minha mente não cursos comprados foi este canal.(eu estudei vpc e não sacava muito mas com sua aula de vpc aquilo fixou na cabaça.
Eu que agradeço por prestigiar nosso conteúdo Maurício. E sim, multi-cloud é o caminho, uso GCP, AWS e outros derivados em muitos projetos, a junção deles traz os melhores resultados
Muito boa a didatica, parabens! Duvida, como o Aurora Serverless V2 se comporta com bilhoes de linhas?
Obrigado Luiz. Em tese ele vai suportar, mas dependendo da engine (MySQL/Postgres) você precisa controlar o tamanho do índice se estiver tudo em uma tabela, essa parte pode consumir bastante recurso para se otimizar, mas há muitas soluções possíveis, entre elas o particionamento da tabela.
Muito bom mesmo!!! Eu já achava o aurora anterior interessante, esse daí, parece ser genial mesmo!!!
Vale muito a pena dependendo do tamanho do projeto
Milan, se não for pedir muito explica pra gente sobre as possibilidades do Aurora v2 porém com o bd MS-Sql server. E qual seria o serviço simular da Azure específico pra esse bd.
Alairton, o Aurora Serverless V2 só suporte MySQL e Postgres atualmente, e infelizmente não conheço os serviços de banco do Azure para poder te dar essa informação
Tentei usar pouco tempo após o lançamento mas sempre que ia escalar pra cima começava a estourar limite de conexões e travava. Nem reboot funcionava. Tinha que criar um banco provisionado no cluster e promover a principal pra poder voltar a funcionar a aplicação. Meses depois tentei de novo, mesma coisa. Por fim desisti e estou usando o provisionado mesmo.
Curso AWS: www.uminventorqualquer.com.br/curso-aws/
Canal Wesley Milan: bit.ly/3LqiYwg
Review do Aurora: th-cam.com/video/zVBuKSJ9-M8/w-d-xo.html
Instagram: bit.ly/3tfzAj0
LinkedIn: www.linkedin.com/in/wesleymilan/
Excelente conteúdo como sempre!
Esperando pelo video explicando os custos, tenho uma aplicação rodando com RDS Postgree em uma instancia T4G.MEDIUM porém esta começando a sofrer em momentos de picos, estou pensando em mudar para o Aurora, porém ainda não consegui entender muito bem o calculo de custos para ter uma previsão como consigo ter com a instancia atual, se compensa migrar nesse tamanho que estou agora ou se seria melhor partir para uma instancia acima que me traria uma folga para o momento atual e seria mais barato do que o Aurora V2...
Segunda-feira o vídeo dos preços estará na mão!
Assistindo o video Review no outro canal, ajudou muito! Obrigado!
No lado da aplicação eu preciso de alguma cuidado adicionar quando usar o Aurora servless? Atualmente trabalho com Golang
Precisa dar uma atenção especial quanto ao uso de conexoes persistentes pra não sobrecarregar a memória do serverless, usar conexões temporárias é muito mais barato ;)
Acho que vai me servir esse DB, pois tenho uma aplicação que hoje não se paga, e se colocar ela no lambda com esse aurora v2 acho que consigo fazer uma aplicação 100% serventes e reduzir brutalmente os custos
Oi Renato, se a demanda por banco for muito pequena eu recomendo assistir o vídeo da próxima semana primeiro ;)
Assistindo aqui com fone, susto da pohh@ com esse raio passando kkkkk
Mas o V1 dá downtime sim, ela escala várias vezes quanto está em um determinado ponto muito próximo entre as 2 units, e nesse momento de escala a aplicação cai, pois o banco não responde. A única solução que encontrei foi fazer via API, alterar os units em determinados horários, porem paguei o preco de excesso as vezes, pois é imprevisível, algo que no final vale a pena, pois o mais importante é a aplicação ficar estável. Acredito que o V2 não seja assim, estou me preparando para testá-lo.
Oi Felipe, acredito que sua instância do V1 estava configurada para entrar em stand-by quando ociosa, esse erro é comum pois a opção vem marcada por default no formulário de criação, enfrentei esse problema também até descobrir esse detalhe, depois disso sem downtime de 1 a 128 units durante anos. Espero ter ajudado
@@GaragemDoInventor So que acontecia em horário de pico, por escalar a todo momento ela sempre fazia a aplicação cair por não responder por alguns segundos, isso já causa uma briga grande, pois os clientes pensam que caiu total.
@@GaragemDoInventor O V1 não escala como o V2, ele tem um delay maior.
@@filipemontt compreendo, passei pelo mesmo problema, não sei qual linguagem você está usando, mas essa incompatibilidade ocorre com conexões persistentes, no meu caso foi com NodeJS, mas com conexões voláteis como PHP por exemplo, eu vi funcionar bem, pois a cada requisição ele estabelece um novo socket, e isso fazia a API do V1 acordar o banco, mesmo assim tinha um delay. Ainda bem que no V2 isso não tem mais, agora é só alegria