Desde 1931 o horário de verão no período de outubro a fevereiro é um costume nas regiões sul, sudeste e centro-oeste do Brasil, fazendo com que fabricantes também planejem as suas soluções para se adaptar automaticamente a essa mudança periódica. Devido a abolição do horário de verão no Brasil, a AWS recomenda algumas remediações técnicas para contas usuárias de bancos de dados Amazon RDS (Relational Database Service).
Se você é cliente da AWS e usa banco de dados RDS configurados nos fusos horários do Brasil, confira algumas ações que podem ser tomadas para prevenir possíveis imprevistos na sua operação:
RDS MySQL/MariaDB/Aurora MySQL
Até o lançamento do patch para corrigir esse problema, a AWS sugere que seja usado “America/Fortaleza” ou “America/Manaus” para as instâncias que não estão refletindo as mudanças do horário de verão brasileiro:
America/Sao_Paulo (AKA Brazil/East) (standard UTC-3, UTC-2 in DST): usar temporariamente America/Fortaleza (UTC-3, no DST)
America/Cuiaba (standard UTC-4, UTC-3 in DST): usar temporariamente (UTC-4, no DST)
Para solucionar o problema, faça o seguinte procedimento:
- 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”;
PostgreSQL
As versões 11.5, 10.10, 9.6.15, 9.5.19 e 9.4.24 já estão com a última versão do tzdata, seguindo a lei de 2019. Portanto, a configuração não entrará no horário de verão. Se o cliente usa uma instância em qualquer outra versão anterior a essas, será necessário fazer upgrade.
RDS Oracle
No caso de instâncias RDS Oracle, é necessário verificar se estão usando colunas do tipo “TIMESTAMP WITH TIME ZONE”. Caso contrário, o usuário deve verificar a data do último start do Oracle, acessando 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.
Caso a verificação dê um resultado positivo, é necessário verificar qual a versão do arquivo através do acesso em DST:SQL> select * from v$timezone_file.
- Se a versão for maior ou igual a “31”, a 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 pela equipe de serviço da AWS 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 ela.
- 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, pois o arquivo DST instalado foi configurado para entrar no horário de verão dia 20 de outubro de 2019. 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.
RDS SQL Server
A equipe de serviço da AWS ainda está trabalhando para que os hosts sejam atualizados até 3 de novembro de 2019.
