No grupo de parâmetros da instância, defina binlog_format para ROW . O padrão no RDS é MIXED , embora não haja um motivo convincente para esse valor padrão na maioria das condições. Nos meus sistemas, ROW é sempre usado porque tem vantagens substanciais sobre MIXED .
Uma das razões mais convincentes neste cenário é esta parte da explicação:
The restore operation encountered inserts/updates with strings containing non-encoded binary characters
Embora isso não me pareça uma explicação completa (porque isso não é realmente inválido, sem um bug), podemos facilmente evitar o problema, conforme descrito - o formato de registro ROW captura imagens de linhas alteradas, em vez de capturar a inserção / update (/ delete) instruções como "strings", por isso, se houver um problema com a maneira como a infraestrutura do RDS ou a versão do MySQL subjacente lida com isso, isso deve eliminá-lo.
O modo MIXED permite que o otimizador escolha se deseja registrar os resultados de DML como a consulta que foi emitida ou como imagens das linhas que foram alteradas, e tenderá a registrar a instrução se nada internamente sinalizar a instrução como não-determinístico para, ou incompatível com, repetição - como usar coisas como a função UUID() (que não geraria o mesmo valor quando chamado, no futuro). (Outras funções, como NOW() , possuem mecanismos complementares embutidos no registro que os tornam determinísticos para reprodução, contra-intuitivamente.)
A única ressalva significativa que vem à mente com o modo ROW é que todas as suas tabelas devem ter chaves primárias (o que deve ser prática padrão, de qualquer forma) senão restauração e replicação (se você tiver réplicas) podem ser mais lentas, pois toda a tabela é verificada quanto a exclusões e atualizações nessa condição ... mas deixando de lado essa consideração, as vantagens do log% ROW são tais que eu não tive a oportunidade de usar nada além de ROW por muitos anos. / p>
A segunda questão é garantir que você não esteja usando o MyISAM ou qualquer outro mecanismo de armazenamento, exceto as tabelas do sistema que as utilizam por padrão (não tente alterá-las).
O MyISAM não possui o recurso de recuperação de falhas do InnoDB, e o RDS depende dessa capacidade para tornar os instantâneos utilizáveis. Ele toma precauções nas tabelas do sistema, portanto elas não representam um problema, mas, para as suas tabelas, nenhuma proteção está em vigor. Uma tabela não-MyISAM que não esteja em um estado consolidado com segurança quando a captura instantânea ocorrer pode impedir que a captura instantânea funcione corretamente.
Embora o suporte não identifique isso como sendo seu problema, é consistente com sua observação de que o horário não funciona até que você crie um novo instantâneo.
Apesar de não documentado em detalhes, minha suposição baseada em evidências anedóticas é que o ponto no tempo começa com o instantâneo antes, mas está mais próximo do ponto de recuperação desejado e, em seguida, aplica todos os logs binários arquivados relevantes para avançar para o ponto de recuperação desejado. É assim que você faz isso manualmente, fora do RDS, e com base nas ações observáveis do usuário "rdsadmin", não há razão para acreditar que o RDS reinventou a roda.
É claro que o problema com um snapshot que inclui tabelas MyISAM desfiguradas é que isso não é algo que se apresenta até após você restaurar o snapshot e e tentar acessar uma das tabelas.
Se este for realmente o problema, o suporte pode ter assumido que você estava ciente do seguinte e, incorretamente, excluiu-o como uma possibilidade:
The MyISAM storage engine does not support reliable recovery and can result in lost or corrupt data when MySQL is restarted after a recovery, preventing Point-In-Time restore or snapshot restore from working as intended.
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html
Se você estiver usando tabelas MyISAM, você deve convertê-las para o InnoDB.