Резервное копирование App Engine никогда не заканчивается, только подсказка - ошибка на карте уменьшить worker_callback

В течение последних нескольких недель мы неоднократно терпели неудачу при выполнении полного резервного копирования хранилища данных с помощью инструмента администрирования хранилища данных. Мы думали, что проблемы связаны с ошибками квот, с которыми мы сталкивались, поэтому мы переключили наше приложение с бесплатного на платное приложение, и у нас все еще есть проблемы.

Каждый раз, когда мы пытаемся выполнить резервное копирование в blobstore, и что происходит, процесс не заканчивается. Мы видим резервную копию в нашем списке ожидающих резервных копий, но она никогда не завершается. Сейчас у нас есть всего 43 МБ данных, поэтому мы не рассматриваем его как проблему передачи данных. Если посмотреть на наши очереди задач по умолчанию, это показывает, что у нас есть две ожидающие задачи: один - вызов /_ah/mapreduce/controller_callback, а другой - вызов /_ah/mapreduce/worker_callback

Рабочий_callback подсчитывает счетчик повторов, и единственная ошибка, которую мы имеем, - это вкладка "Предыдущий запуск", на которой последний код ответа HTTP должен быть 500. Нет сообщения об ошибке, ничего не отображается в наших журналах ошибок, это просто продолжает пытаться снова и снова.

Мы смогли сузить проблемы резервного копирования до определенного типа сущности для определенного пространства имен, но мы не можем понять, почему этот тип сущности терпит неудачу, тогда как другие - нет. Основное различие заключается в том, что тип объекта имеет большое количество встроенных объектов, но если движок приложения способен читать/помещать эти объекты, мы не можем понять, почему у него возникают проблемы с его резервными копиями. Конкретное пространство имен, в котором происходит ошибка, содержит самые большие данные, хранящиеся для этого типа сущности, по сравнению с другими установками, которые мы установили.

Мы думаем, что если мы увидим, какая ошибка возникает в work_callback, мы можем понять, почему происходит сбой резервного копирования, или что не так с нашими данными, которые препятствуют резервной копии. Есть ли что-то, что нам нужно для настройки/включения через настройки/файлы конфигурации, чтобы предоставить нам более подробную информацию о резервном копировании? Или есть какой-то другой путь, который мы должны изучить, чтобы выяснить, как исследовать/исправить эту проблему?

Я должен упомянуть, что мы используем Java SDK, а также Objectify V3 ​​для работы с хранилищем данных. Мы также резервируем данные в Blobstore.

Спасибо.

2 ответа

Хорошо с командой команды разработчиков приложений мы выяснили, в чем проблема, и мы работали над проблемой. Я хочу дать подробности, если кто-то еще столкнется с этой проблемой.

Из issue 8363 команда разработчиков приложений указала, что из своих журналов они могли видеть, что уменьшение карты не удалось из-за большого количества свойств, которые наш вид сущности. Конкретный тип объекта, который вызывал сбой, имел большое количество переменных свойств, которые генерировали ошибки, когда уменьшение карты пыталось выписать схему. Они указали, что решение на их конце было игнорировать объекты, которые были похожи на это в резервной копии, чтобы сделать так, чтобы резервная копия работала успешно.

Что мы сделали, чтобы обойти эту проблему и сделать работу по резервному копированию, изменилось, как мы сказали объективировать хранить данные. Большое количество свойств создавалось благодаря использованию ключевого слова @embedded в поле члена класса HashMap(). Поскольку встроенное ключевое слово разбивает классы на отдельные компоненты, оно генерирует большое количество свойств. Мы изменили поле члена на @serialized, а затем выполнили процесс преобразования, чтобы использовать новое свойство serialized. Это снова сделало операцию резервного копирования/восстановления.

Вы можете больше узнать о различиях между встроенными и сериализованными на объективировать веб-сайт


snielson, не могли бы вы открыть проблему в нашем трекер-системе Publica здесь. Не забудьте добавить свой идентификатор приложения, чтобы мы могли дополнительно отладить этот конкретный сценарий.

Спасибо!

licensed under cc by-sa 3.0 with attribution.