Если это оракл, то партицию указывать не обязательно. Достаточно хорошего индекса и условия выборки. Да и select * практика плохая.

Добро пожаловать в самое дружелюбное комьюнити.

В общем проблема была в том что мы упираемся в max_connections из-за использования SubDag, которые спавнят коннекшены мимо пул

причём это всё коннекшены в бд самого airflow, поэтому в логах источника и цели данных ничего странного не было. придётся переписывать даги)

Как оказалось это из-за того, что celery result backend был в postgre. Переправил на redis - полет нормальный уже неделю .

На днях столкнулся с тем , что шедулер просто перестает работать . На ui отображается , как последний хертбит был получен N времени назад . Версия 1.10.10. покопался , нашел свежую тему https://github.com/apache/airflow/issues/7935 . Пишут что нужно запускать с параметром -n .

кто-нибудь сталкивался с проблемой, что логи тасок не пишутся в соответствующие лог файлы?

В самом даге logger как-то переопределяется ? Или это абсолютно везде

В модуле с тасками дага я создаю логгер из дикт конфига: в логгере три хэндлера, один из них пишет логи в стдаут. Раньше эирфлоу перехватывал стдаут и записывал все это в логи тасок, сейчас логи тасок пустые

Доброго дня! Сможет кто нибудь помочь? Есть даг выполняющийся по шедулеру раз в сутки. Если триггерить его вручную, то данные переносятся - среднее время выполнения около 2-х минут. Однако при запуске по шедулеру таски выполняются за ~20 сек. помечаются как успешные но данных в целевой бд нет. Уже изменили время запуска по шедулеру, чтобы быть полностью уверенными что в исходной бд вьюха содержит данные. В логах таски ничего конкретного нет (и не очень понятно что залогировать). Другие даги отрабатывают успешно. Версия airflow 1.10.6. Заранее спасибо!

А таски как-то завязаны на время запуска дага?

Абсолютно нет

три таски
1)создать темповую таблицу в целевой бд,
2)мигрировать данные из вью исходной бд в темповую таблицу в целевой бд,
3) переименовать темповую бд и отнаследовать от другой таблички

собственно вопрос то только в миграции которая при запуске по шедулеру отрабатывает успешно но не мигрирует данных между системами

таска с миграцией данных: 1) select * из исходной бд

2) insert в целевую бд

если это sql квери, обычно они success просто от выполнения квери, не важно были там данные или нет, имеет смысл сенсор повесить просто в начало, чтобы он прочекал что данные точно есть, если я правильно поняла что вопрос в том, как запускать когда точно данные есть

данные есть, однако попробую повесить логирование кол-ва данных. спасибо

Какая бд? Через Airflow test пробовали? Учтите что у каждой таски своя сессия

Поэтому сессионные темп таблицы не прокатят