Conforme publicado no decreto Nº 9.772 do Governo Federal Brasileiro, em 2019 não haverá horário brasileiro de verão.
Em busca da resiliência dos seus serviços na nuvem e para evitar conflitos e imprecisões de horários, é importante você tomar as seguintes medidas antes de 2 de novembro de 2019 para evitar impactos nos seus ambientes.
Vale ressaltar que, originalmente, antes do decreto Nº 9.772, a data de início do horário de verão 2019 seria 3 de novembro de 2019 – Desta forma, é altamente recomendada a verificação e possíveis ações de adequação aqui descritas antes de 3 de novembro (com atenção à uma exceção em bases Oracle melhor descrito mais abaixo).
Neste artigo você encontrará ações recomendadas para bancos de dados instanciados no AWS RDS, bancos de dados instanciados no serviço de computação Amazon EC2 e também para gerência de sistema operacional nas máquinas virtuais no Amazon EC2.
Para instâncias AWS RDS – MySQL, MariaDB ou Aurora MySQL
1. Como workaround, até o lançamento do patch para corrigir esta configuração, é recomendado usar “America/Fortaleza” ou “America/Manaus” como configuração de timezone para as instancias que não estão refletindo as mudanças do horário de verão brasileiro.
mysql> select CONVERT_TZ('2019-10-19 20:37:53', 'UTC', 'Brazil/East')
"Oct19_BRT",CONVERT_TZ('2019-10-20 20:37:53', 'UTC', 'Brazil/East')
"Oct20_BRT";
mysql> select CONVERT_TZ('2019-10-19 20:37:53', 'UTC', 'America/Fortaleza')
"Oct19_BRT",CONVERT_TZ('2019-10-20 20:37:53', 'UTC', 'America/Fortaleza')
"Oct20_BRT";
Para clientes que referenciam seus horários com a cidade de Cuiabá/Mato Grosso:
mysql> select CONVERT_TZ('2019-10-19 20:37:53', 'UTC', 'America/Manaus')
"Oct19_BRT",CONVERT_TZ('2019-10-20 20:37:53', 'UTC', 'America/Manaus')
"Oct20_BRT";
Para instâncias AWS RDS – PostgreSQL ou Aurora PostgreSQL
As versões 11.5, 10.10, 9.6.15, 9.5.19 e 9.4.24 já estão com as configurações adequadas de timezone, seguindo o decreto de 2019 – portanto, não entrará no horário de verão. Caso tenha uma instância em qualquer outra versão anterior a essas, é recomendado fazer upgrade da instância para alguma das versões acima (ou mais recentes).
Para instâncias AWS RDS – Oracle
No caso de instâncias RDS Oracle, é necessário verificar se estão usando colunas do tipo “TIMESTAMP WITH TIME ZONE”. Esta verificação nos deixa em dois cenários possíveis:
1. Caso não estejam, realizar o seguinte procedimento:
a) Verificar a data do último start do Oracle:
SQL> select startup_time from v$instance;
Se o start for posterior ao dia 27/08/2019, não há previsão de impacto. Caso contrário, se o start ocorreu antes do dia 27/08/2019, é necessário um stop/start da instância.
2. Caso estejam, realizar o seguinte procedimento:
a) Verificar qual a versão do arquivo DST:
SQL> select * from v$timezone_file;
b) Se a versão for maior ou igual a “31”, sua instância está configurada para entrar no horário de verão em 3 de novembro. Um patch para isso ainda está sendo testado/aplicado pelo time de serviço e será disponibilizado em algumas semanas. De acordo com o time de RDS, será necessário criar uma nova instância e migrar os dados para essa nova instância.
c) Se a versão for menor do que “31”, é necessário criar uma nova instância para a última versão disponível do Oracle (por exemplo, 12.1.0.2.v17 ou 11.2.0.4.v21), e migrar os dados para essa nova instância, pois o arquivo DST instalado está configurado para entrar no horário de verão dia 20 de outubro. Esse processo irá postergar o horário de verão para o dia 3 de novembro, fazendo ser necessário a atualização da engine do banco e cópia dos dados, como mencionado acima.
Para instâncias AWS RDS – SQL Server
O time de serviço ainda está trabalhando para que os hosts sejam atualizados até 3 de novembro.
Para instâncias de bancos de dados rodando em Amazon EC2
Você pode considerar as recomendações para RDS acima e, em caso de dúvidas, contate o suporte do seu banco de dados.
Para máquinas virtuais Amazon EC2
Em alguns cenários de negócio, as aplicações sendo executadas em máquinas virtuais podem ter um vínculo forte com o horário do sistema operacional onde está sendo executada. Isto é comum em servidores de aplicação de notas fiscais, ERP, ou qualquer outro cenário de negócio onde o horário das transações é uma informação crítica e sensível.
Para este cenário, existe um pacote utlizado do TZDATA para o Amazon Linux ou CentOS Linux, tanto para o sistema operacional como para o Java que vem disponível na instalação do sistema operacional. Para adequar seu ambiente operativo à estas recomendações, siga o seguinte procedimento:
Validar a versão instalada no S.O
[root@server~]# rpm -qa | grep -i tzdata
tzdata-java-2018i-1.amzn2.noarch
tzdata-2018i-1.amzn2.noarch
Efetuar a atualização
[root@server~]# yum update tzdata.noarch
Validar se a versão foi atualizada
[root@server~]# rpm -qa | grep -i tzdata
tzdata-java-2018i-1.amzn2.noarch
tzdata-2019b-1.amzn2.noarch
Obs: Caso tenha aplicações Javas utilizando os pacotes Java providos pelo sistema operacional, efetue também sua atualização.
Para os demais sistemas operacionais, consulte o suporte do fornecedor do SO.
No caso de dúvidas ou necessidades adicionais de ajuda, contate a linha de suporte técnico e ao negócio da Amazon Web Services – que inclui o seu Gerente de Conta, o seu Arquiteto de Soluções, o time de Suporte Enterprise e o time de Professional Services.
Autores
Rodolfo Vilarinho
Vilarinho é arquiteto de solução na AWS no segmento de enterprise e atualmente, direciona clientes na criação e execução de estratégias de adoção de nuvem e na modernização de aplicações. Com mais de 10 anos de experiência em tecnologia já atou em frentes de transformação de tecnologia liderando equipes em projetos de migração e implementação de ambientes complexos.
Nikolas Aulicino
Nikolas é arquiteto de soluções da AWS na América Latina, apoiando empresas dos mais diversos segmentos na adoção de nuvem. Com mais de 13 anos de experiência atuando na área de tecnologia da informação, Nikolas atuou em diversos segmentos do ramo desde de implementação de redes físicas e lógicas, migrações de sistemas e desenvolvimento de aplicações.
Luciano Martins
Luciano é arquiteto de soluções na AWS, trabalhando junto com clientes nas suas jornadas de inovação e adoção da nuvem. No seu dia dia, Luciano foca em modernização de aplicações e soluções de Inteligência artificial. Com experiência de mais de 18 anos em tecnologia, Luciano já ajudou dezenas de empresas de vários países a planejar, implementar e gerir suas estratégias de modernização de TI.