mysql 5.7 на Amazon RDS получает сообщение «table foo не существует»

После восстановления резервной копии mysql в AWS RDS я получаю «таблица не существует»:

Server version: 5.7.22-log Source distribution
mysql> show tables;
+----------------------------+
| Tables_in_db               |
+----------------------------+
| foo                        |
...

mysql> select * from foo;
ERROR 1146 (42S02): Table 'db.foo' doesn't exist

Эта ошибка связана с ошибкой сервера и переполнением стека. Обычно предлагается остановить серверы, изучить файлы в файловой системе и так далее.

Я не думаю, что у меня есть доступ к серверу или файловой системе на AWS. Я в шланге?

Как мне вообще подать заявку в AWS?

РЕДАКТИРОВАТЬ: Я удалил случайный период выше, потому что его не было в реальном примере. Этот случайный период (теперь уже ушедший) заставил кого-то проделать удивительную отладку ниже, но это не моя проблема.

Кроме того, я узнал, как подать заявку на AWS. Вот.

Думаю, я воссоздал вашу проблему:

mysql> use test
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| collorder      |
| collorder2     |
+----------------+
2 rows in set (0.00 sec)

mysql> CREATE DATABASE `test .`;
mysql> USE `test .`;
mysql> CREATE TABLE foo (x int);
mysql> SHOW TABLES;
+------------------+
| Tables_in_test . |
+------------------+
| foo              |
+------------------+
1 row in set (0.00 sec)
mysql> USE test;
mysql> SELECT * FROM foo;
ERROR 1146 (42S02): Table 'test.foo' doesn't exist

Если вы не видите, что я сделал, давайте попробуем следующее:

mysql> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test               |
| test .             |
+--------------------+

Теперь это очевидно?

Сделай это:

SELECT schema_name, char_length(schema_name), hex(schema_name)
    FROM information_schema.schemata;

чтобы увидеть подробности.

Проблема оказалась в том, что я использовал некоторые сложные направления чтобы преобразовать MySQL из utf8 (ловушка) в utf8mb4 и нарушить некоторые ограничения внешнего ключа, изменив две стороны ограничения на разные типы, пока ограничение было отключено. Я не виню направления, но это деликатная операция. Я виню MySQL в плохом дефолте («utf8» - это еще не все utf8) и в нелегком процессе, чтобы попасть в нужное место.

Эти ошибочные ограничения внешнего ключа сделали резервную копию «успешной», но с данными, которые не могли быть восстановлены должным образом (но без ошибок восстановления, пока я не попытался выбрать из таблицы).