Как справиться с резервным копированием и восстановлением базы данных в разных средах?

Question

Я использую Directus в Prod и нескольких непродовольственных средах. В Prod пользователи будут обновлять контент только в коллекциях. В non-prod администраторы будут тестировать все остальные обновления, касающиеся новых коллекций, ролей пользователей, разрешений и т. Д. Я планирую создавать резервные копии таблиц, связанных с контентом коллекций, в prod и восстанавливать их в более низких средах, чтобы поддерживать актуальность данных. После того, как тестирование новых коллекций или другие изменения администратора будут выполнены в непроданных средах, я планирую создать их резервную копию, а затем восстановить таблицы, относящиеся к этим изменениям, до prod. Прямо сейчас планируется написать сценарии оболочки, используя mysqldump и mysqlimport для выполнения этих операций.

Мой вопрос заключается в том, какие таблицы, относящиеся к содержимому коллекций, нужно резервировать в prod и перемещать в более низкие среды? Кроме того, могу ли я использовать метод, описанный здесь, чтобы не перезаписывать какие-либо записи активности и избежать потери данных?

Answer 1

Критически важные таблицы будут:

• directus_collections (какие коллекции есть)
• directus_fields (какие поля в этих коллекциях)
• directus_relations (какие коллекции связаны друг с другом)

Я лично скопировал бы все таблицы directus_*. Даже если вам не обязательно переходить к таким вещам, как активность, я буду осторожен и постараюсь не столкнуться с какими-либо странными проблемами позже.

Кроме того, могу ли я использовать метод, описанный здесь, чтобы не перезаписывать какие-либо записи активности и избежать потери данных?

Если вы не собираетесь редактировать какой-либо фактический контент в непроизводственных средах, вы должны иметь возможность игнорировать directus_activity и directus_revisions, поскольку эти два непосредственно связаны с необработанным контентом.