Clustering MySQL для установки Magento 2.0

Question

Я планирую установить установку Magento 2.0 с помощью MySQL Cluster o MySQL Galera Cluster для высокодоступной БД. Одним из ограничений для них является то, что каждая таблица должна иметь PK. К моему удивлению, не каждая таблица на Magento 2.0 Community Edition имеет ПК. У большинства из них есть один, но есть некоторые, которые этого не делают.

Кто-нибудь достиг установки Magento с высокодоступной кластерной БД? Как вам это удалось? Я думал о просто добавлении auto-incremental PK к таблицам, которые не имеют PK, но это может означать проблемы для будущих обновлений Magento с изменениями схемы.

Что вы хотите сделать?

EDIT: Это таблицы, которые были бы хлопотно:

+--------------------------------------------------------------+--------+------+----------+--------+ 
| tbl               | engine | nopk | ftidx | gisidx | 
+--------------------------------------------------------------+--------+------+----------+--------+ 
| magento.cataloginventory_stock_status_tmp     | MEMORY |  |   |  | 
| magento.catalogsearch_fulltext_scope1      | InnoDB |  | FULLTEXT |  | 
| magento.catalog_category_product_index_tmp     | MEMORY | NOPK |   |  | 
| magento.catalog_product_entity_media_gallery_value_to_entity | InnoDB | NOPK |   |  | 
| magento.catalog_product_entity_media_gallery_value_video  | InnoDB | NOPK |   |  | 
| magento.catalog_product_index_eav_decimal_tmp    | MEMORY |  |   |  | 
| magento.catalog_product_index_eav_tmp      | MEMORY |  |   |  | 
| magento.catalog_product_index_price_bundle_opt_tmp   | MEMORY |  |   |  | 
| magento.catalog_product_index_price_bundle_sel_tmp   | MEMORY |  |   |  | 
| magento.catalog_product_index_price_bundle_tmp    | MEMORY |  |   |  | 
| magento.catalog_product_index_price_cfg_opt_agr_tmp   | MEMORY |  |   |  | 
| magento.catalog_product_index_price_cfg_opt_tmp    | MEMORY |  |   |  | 
| magento.catalog_product_index_price_downlod_tmp    | MEMORY |  |   |  | 
| magento.catalog_product_index_price_final_tmp    | MEMORY |  |   |  | 
| magento.catalog_product_index_price_opt_agr_tmp    | MEMORY |  |   |  | 
| magento.catalog_product_index_price_opt_tmp     | MEMORY |  |   |  | 
| magento.catalog_product_index_price_tmp      | MEMORY |  |   |  | 
| magento.catalog_url_rewrite_product_category     | InnoDB | NOPK |   |  | 
| magento.cms_block           | InnoDB |  | FULLTEXT |  | 
| magento.cms_page            | InnoDB |  | FULLTEXT |  | 
| magento.customer_grid_flat         | InnoDB |  | FULLTEXT |  | 
| magento.oauth_nonce           | InnoDB | NOPK |   |  | 
| magento.sales_creditmemo_grid        | InnoDB |  | FULLTEXT |  | 
| magento.sales_invoice_grid         | InnoDB |  | FULLTEXT |  | 
| magento.sales_order_grid          | InnoDB |  | FULLTEXT |  | 
| magento.sales_shipment_grid         | InnoDB |  | FULLTEXT |  | 
| magento.widget_instance_page_layout       | InnoDB | NOPK |   |  | 
+--------------------------------------------------------------+--------+------+----------+--------+ 

Answer 1

У меня была аналогичная задача несколько месяцев назад: оценить лучшее решение DB высокой доступности, который будет соответствовать нашему проекту (Java веб-приложение + MySQL).

Сначала я начал оценивать кластер Galera, и я узнал, что если вы попытаетесь просто использовать кластеризацию БД с приложением, которое не было написано с учетом кластеризации, скорее всего, это не просто работает, но может потребоваться корректировки кода. Мы могли бы адаптировать наш код в большинстве областей, но мы столкнулись с препятствием. В нашем приложении используются транзакции XA, которые не поддерживаются Galera. Поскольку мы не можем избавиться от транзакций XA в ближайшем будущем, мы не можем использовать Galera (пока).

Итак, я перешел к следующей опции: Репликация Master-Slave с автоматическим откатом. Не так элегантно, как кластерное решение, тем более что в этой настройке подчиненный может находиться за мастером с несколькими секундами, что означает, что в случае сбоя мастера могут быть некоторые потерянные данные (не так много). В настоящее время мы все еще оцениваем этот подход, и пока все выглядит хорошо.

Теперь .. если бы я был вами, я бы попытался сделать работу Magento с кластером Galera первым. Как вы сказали, вам придется изменить схему, чтобы сделать ее совместимой с Galera, но вам нужно быть осторожным с будущими обновлениями. Мы используем следующие треки для отслеживания проблем/поддержки: MantisBT и osTicket, которые мне пришлось настраивать, изменяя как код PHP, так и схему базы данных. Я выполняю все обновления вручную. Я должен быть очень осторожен, но другой, что это не очень важно. Я думаю, если у вас будет достаточно терпения, вы можете сделать то же самое на Magento.

Помимо таблиц, в которые вы должны добавить PK, я вижу, что есть таблицы, в которых используется движок MEMORY. Насколько я знаю, Galera поддерживает только движок InnoDB, и у него есть экспериментальная поддержка MyIsam. В то время как PK-материал легче исправить, установка этого движка MEMORY на Galera может быть труднее. Смотрите интересное обсуждение здесь именно на управлении Magento with Galera

Наконец, если вы решили, что это слишком сложно, чтобы пойти с Галера (если вообще возможно), у вас есть другие варианты, такие как HA репликации ведущий-ведомый, например. Я не вижу причин для того, чтобы он не работал в вашем случае.

В качестве последнего слова: я узнал, что приведение HA в проект непросто. Но это забавная и выполняющая задача. :-) Просто сообщите, какой подход вы поехали в конце. Это может быть очень полезно и для других.