Все операции метабазы, возвращающие «Поле 'id', не имеют значения по умолчанию" - PullRequest
Новая
       8

Все операции метабазы, возвращающие «Поле 'id', не имеют значения по умолчанию"

0 голосов
/ 17 марта 2020

Мы перемещаем наше развертывание Metabase v0.24.1 с AWS RDS MySQL 5.7 на AWS Aurora MySQL Без сервера (совместимо с 5.6). Когда мы запускаем Metabase каждый запрос, который пытается выполнить приложение, возвращает какую-либо форму этой ошибки: 

Field 'id' doesn't have a default value

Полная ошибка: 

03-17 16:07:57 [1mERROR metabase.middleware[0m :: [31mPOST /api/database 500 (68 ms) (0 DB calls)[0m
{:message "Field 'id' doesn't have a default value",
 :stacktrace
 ["api.database$fn__29894$fn__29897.invoke(database.clj:233)"
  "api.common.internal$do_with_caught_api_exceptions.invokeStatic(internal.clj:229)"
  "api.common.internal$do_with_caught_api_exceptions.invoke(internal.clj:224)"
  "api.database$fn__29894.invokeStatic(database.clj:215)"
  "api.database$fn__29894.invoke(database.clj:215)"
  "middleware$enforce_authentication$fn__38784.invoke(middleware.clj:120)"
  "api.routes$fn__38908.invokeStatic(routes.clj:58)"
  "api.routes$fn__38908.invoke(routes.clj:58)"
  "routes$fn__39540$fn__39541.doInvoke(routes.clj:64)"
  "routes$fn__39540.invokeStatic(routes.clj:60)"
  "routes$fn__39540.invoke(routes.clj:60)"
  "middleware$log_api_call$fn__38883$fn__38885.invoke(middleware.clj:329)"
  "middleware$log_api_call$fn__38883.invoke(middleware.clj:328)"
  "middleware$add_security_headers$fn__38833.invoke(middleware.clj:243)"
  "middleware$bind_current_user$fn__38788.invoke(middleware.clj:140)"
  "middleware$maybe_set_site_url$fn__38837.invoke(middleware.clj:266)"],
 :sql-exception-chain ["SQLException:" "Message: Field 'id' doesn't have a default value" "SQLState: HY000" "Error Code: 1364"]}

Попытки добавить новую базу данных также возвращают та же ошибка в пользовательском интерфейсе метабазы.

Мы проверили, что параметры базы данных RDS одинаковы для базы данных, в которую мы переносим, ​​и исключаем конфигурации по умолчанию для движка, которые могут изменяться между Aurora Serverless и MySQL 5.7 по умолчанию.

Еще одним заметным изменением является то, что мы переходим от обычных задач ECS, работающих на экземплярах EC2, которыми мы владеем, к задачам Fargate, но определения задач у них идентичны.

Редактировать: I обнаружил другое несоответствие конфигурации между Aurora Serverless и MySQL 5.7 в параметре sql_mode. В 5.7 по умолчанию установлено значение NO_ENGINE_SUBSTITUTION, а в режиме без сервера установлено значение 0.

После обновления sql_mode в моем развертывании без сервера до NO_ENGINE_SUBSTITUTION я обнаружил, что фактическая конфигурация остается противоречивым в самой базе данных. SELECT @@sql_mode; возвращает NO_ENGINE_SUBSTITUTION в развертывании 5.7 и возвращает STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION в развертывании без сервера, даже если для группы параметров не задано это значение.

Редактировать 2: я не упомянул метод, который мы используется для передачи данных в новую базу данных, и это AWS DMS версии 3.3.1. Похоже, что DMS не реплицирует атрибут таблицы auto_increment, который должен присутствовать в столбцах id в базе данных метабазы. Это может быть проблема root.

1 Ответ

0 голосов
/ 18 марта 2020

Причина root этой проблемы заключалась в том, что столбцы id в БД метабазы ​​не имели атрибута auto_increment и обрабатывались так, как будто у них не было значений, даже если они имели.

Это произошло потому, что AWS DMS, который мы использовали для передачи данных, не копирует все детали схемы:

https://dba.stackexchange.com/questions/138946/aws-dms-creates-tables-with-no-auto-increment

Чтобы решить эту проблему, сначала нужно было выполнить миграцию схемы с использованием стандартного mysqldump --no-data, а затем мы заполнили данные DMS.

...