MemSQL Weird Insert/Update Поведение

Question

Мы используем единый узел MemSQL и все работает нормально, но когда мы пытаемся переместить нашу установку MemSQL использовать мульти узел/заявление обновления вставки ведут себя очень странно

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

CREATE /*!90618 REFERENCE*/ TABLE `fact_orderitem_hourly_release_update` 
(
    `order_id` int(11) NOT NULL DEFAULT '0', 
    `customer_login` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL, 
    `warehouse_id` int(11) DEFAULT NULL, 
    `city` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL, 
    `store_id` int(11) DEFAULT NULL, 
    PRIMARY KEY (`order_id`) 
); 

CREATE TABLE `fact_orderitem_hourly_scale` (
    `order_id` int(11) NOT NULL DEFAULT '0', 
    `order_group_id` int(11) NOT NULL DEFAULT '0', 
    `item_id` int(11) NOT NULL, 
    `sku_id` int(11) NOT NULL DEFAULT '0', 
    `sku_code` varchar(45) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL, 
    `po_type` varchar(20) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL, 
    `store_order_id` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL, 
    `bi_last_modified_on` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00.000000', 
    PRIMARY KEY (`item_id`,`sku_id`), 
    /*!90618 SHARD */ KEY `sku_id` (`sku_id`), 
    KEY `idx_fact_orderitem_hourly_lmd` (`bi_last_modified_on`), 
    KEY `idx_fact_orderitem_hourly_ord` (`order_id`), 
    KEY `idx_order_group_id` (`order_group_id`), 
    KEY `idx_store_order_id` (`store_order_id`) 
); 

My Load Script:

mysql -h$LiveMemSQL_DB -u$LiveMemSQL_USER --password=$LiveMemSQL_PASS -P$LiveMemSQL_PORT --verbose reports_and_summary < /home/titan/brand_catalog/upsert_memsql_orl_update.sql 

Contents of .SQL File : 

--start of .sql file 
    TRUNCATE TABLE reports_and_summary.fact_orderitem_hourly_release_update; 

#Load data into staging 

LOAD DATA LOCAL INFILE '/myntra/redshift/delta_files/live_scale_order_release_upd.txt' INTO TABLE reports_and_summary.fact_orderitem_hourly_release_update LINES TERMINATED BY '\n'; 


#Insert/Update statement 
INSERT INTO reports_and_summary.fact_orderitem_hourly_scale 
(
item_id, 
sku_id, 
customer_login, 
order_status, 
is_realised, 
is_shipped, 
shipping_charge, 
gift_charge, 
warehouse_id, 
city, 
store_id 
) 
select 
fo.item_id, 
fo.sku_id, 
fr.customer_login, 
fr.order_status, 
fr.is_realised, 
fr.is_shipped, 
fr.shipping_charge, 
fr.gift_charge, 
fr.warehouse_id, 
fr.city, 
fr.store_id 
from fact_orderitem_hourly_release_update fr 
join fact_orderitem_hourly_scale fo 
on fr.order_id=fo.order_id 
ON duplicate key update 
customer_login=values(customer_login), 
order_status=values(order_status), 
is_realised=values(is_realised), 
is_shipped=values(is_shipped), 
shipping_charge=values(shipping_charge), 
gift_charge=values(gift_charge), 
warehouse_id=values(warehouse_id), 
city=values(city), 
store_id=values(store_id); 

--end .sql файл

Когда я запускаю вышеуказанный .sql через клиент командной строки mysql, он работает иногда, и он не много раз, а несколько раз, если я выполняю тот же самый файл .sql непрерывно 5-10 раз, обновления будут получить эффект в одном из этих прогонов, а иногда сказать, например, если есть 3 записи с order_id 101 и статус SHIPPED, и мы получили обновление в таблице слияния, скажем, что статус заказа был изменен на DELIVERED, в идеале статус всех 3 заказов должен быть изменено на DELIVERED, но только одна или две строки, связанные с заказом, обновляются, но если я выполняю тот же самый файл .sql-файла через MySQLWorkbench, он отлично работает, я могу казаться глупым, но это то, что происходит, и я борется за последние 2 дня с этим странным поведением

Пожалуйста, найдите приведенный ниже экран, в котором я зафиксировал это поведение. https://www.youtube.com/watch?v=v2HN-n4V0MI&feature=youtu.be

Answer 1

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

Вы можете

• ждать немного после записи в справочной таблице
• сделать промежуточную таблицу нереференсного