@tomat удалось выяснить вот что.
- Выгрузил все индексированные id из main и delta.
Затем прошелся скриптом по ids из delta и пачками по 100 слал запросы в proxy и результат сохранял в файл.
Итого:- в main после его ротации id проиндексировано: 2029747
- в delta после ротации (одной из последней) id проиндексировано: 16544
- через proxy прошли запросы группами по 100: 166 запросов
- по всем id (из 16544) есть результаты поиска
Отсюда можно сделать предварительный вывод, что все документы проиндексированные в новых delta, доступны после ротации для поиска.
- Прошелся скриптом по ids из main (2029747) и пачками по 1000 слал запросы в proxy и результат сохранял в файл.
Итого:
- в main после его ротации id: 2029747
- через proxy прошли 2018015 из 2029747, нет для 11760
Но при этом из 11732 (запросы группами по 1000: 2034 запросов
- результаты есть по (ранее 11760) - 4949 нет в delta, а там было 16544.
Взяв еще раз список id из 4949 выше, прогнал запросами и получил, что теперь из них недоступны для поиска только 1575.
P.S. Здесь можно не обращать внимание на такую разницу, т.к. проверка шла на прошлом и новом часе с новой индексацией.
Суть не меняет, просто не быстрый процесс проверок всех и обработки.
Выборочная проверка в таблице Источнике product по этим id показала вот что:
db_libra=# select id,name,is_removed,changed_at,changed_at_timestamp from product where id=2110110;
id | name | is_removed | changed_at | changed_at_timestamp
---------+---------------------------------------------+------------+---------------------+----------------------
2110110 | Атлант расправил плечи (комплект из 3 книг) | f | 2025-07-07 17:58:14 | 1751900294
(1 строка)
Суть в том, что для поиска недоступны документы, которые были изменены ДО начала нового часа уже после нового main и delta.
Сделал еще сравнение на основе результата выше.
Из 1575 для поиска были доступны 1567, а 8 нет.
Их id:
2082214
2095283
2103865
2140157
2193693
2769455
3085452
8108576
Запрос по ним в proxy:
mysql> select id,name from products where id in (2082214,2095283,2103865,2140157,2193693,2769455,3085452,8108576);
+---------+-------------------+
| id | name |
+---------+-------------------+
| 2769455 | Три любви |
+---------+-------------------+
1 row in set (0,00 sec)
И в Источник:
db_libra=# select id,name,is_removed,changed_at,changed_at_timestamp from product where id in (2082214,2095283,2103865,2140157,2193693,2769455,3085452,8108576);;
id | name | is_removed | changed_at | changed_at_timestamp
---------+-----------------------------------------------------------+------------+---------------------+----------------------
2082214 | Подводный мир. Полная энциклопедия. | f | 2025-07-07 17:57:25 | 1751900245
2095283 | Доктор Живаго | f | 2025-07-07 17:57:45 | 1751900265
2103865 | Отцы и дети | f | 2025-07-07 17:58:03 | 1751900283
2140157 | Маленький принц | f | 2025-07-07 17:59:01 | 1751900341
2193693 | История государства Российского | f | 2025-07-07 18:00:39 | 1751900439
2769455 | Три любви | f | 2025-07-07 18:20:07 | 1751901607
3085452 | Машенька | f | 2025-07-07 17:58:40 | 1751900320
8108576 | Секрет чёрного камня. Вампир Полумракс. Приключения Алисы | f | 2025-07-07 17:58:40 | 1751900320
(8 строк)
Для 7 записей из 8 видно, что у них changed_at до начала 18:00 включительно.
И эти id были подавлены в mian и недоступны для поиска на распределенном индексе.
Пробовал менять killlist_target: "INDEX_MAIN:kl" на:
killlist_target: "INDEX_MAIN:id"- только дляidиз deltakilllist_target: "INDEX_MAIN"- оба варианта: id из delta и kill-list
И запрос в sql_query_killlist:
SELECT id FROM product \
WHERE is_removed = 't' AND (id % CHUNK_SIZE) = CHUNK_MOD
И результат не изменился, документы в main как подавлялись, так и продолжают подавляться после ротации новой delta на новом main.
При этом id подавленных документов нет в delta. И при этом количество подавленных документов не сходится с delta и ее kill-list.