Question

Here is the situation.

I am using magento 2.1.6 Enterprise edition. In magento documentation it has been said that "Magento uses MySQL database triggers to improve database access during reindexing".

But my question is what will happen if I use database without triggers. Because I am planning to move the database to Google cloud SQL. In google cloud documentation they said to avoid triggers if you are going to use replication as it may cause inconsistency in the replica.

What is the best is the best to go about it ?

Was it helpful?

Solution

Magento uses MySQL database triggers to improve database access during reindexing.

Magento does not support any custom triggers in the Magento database because custom triggers can introduce incompatibilities with future Magento versions.

The Magento indexing mechanism uses the status value in reindex triggering process.

You can check the status of an indexer in the Admin panel

System > New Index Management

enter image description here

or manually using the command line. View a list of indexers

To view a list of all indexers:

bin/magento indexer:info

The list displays as follows:

catalog_category_product                 Category Products
catalog_product_category                 Product Categories
catalog_product_price                    Product Price
catalog_product_attribute                Product EAV
cataloginventory_stock                   Stock
catalogrule_rule                         Catalog Rule Product
catalogrule_product                      Catalog Product Rule
catalogsearch_fulltext                   Catalog Search

How does it work?

In short, Magento 2 creates triggers for each “Update by Schedule” index.

These triggers fire on any INSERT, UPDATE and DELETE on any of the entity’s tables.

  • On firing, they create a new entry with the entity id in a specific changelog table.

  • When the cron job runs, it compares the version_id of its mview_state table with the version_ids of the change-log table.

  • The index is updated for all entities that are marked as changed. Caches for specific entities are invalidated (cleared) as well.

Triggers

When an index is set to “Update on Schedule”, Magento 2 creates a series of triggers for it. For catalog_product_flat alone, 30 triggers are created.

mysql> show triggers \G

*************************** 1. row ***************************
             Trigger: trg_catalog_product_entity_after_insert
               Event: INSERT
               Table: catalog_product_entity
           Statement: BEGIN
INSERT IGNORE INTO `catalog_product_flat_cl` (`entity_id`) VALUES (NEW.`entity_id`);
END
              Timing: AFTER
             Created: 2018-01-10 16:04:59.54
            sql_mode: 
             Definer: some-magento-user@localhost
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
*************************** 2. row ***************************
             Trigger: trg_catalog_product_entity_after_update
               Event: UPDATE
               Table: catalog_product_entity
           Statement: BEGIN
INSERT IGNORE INTO `catalog_product_flat_cl` (`entity_id`) VALUES (NEW.`entity_id`);
END
              Timing: AFTER
             Created: 2018-01-10 16:04:59.56
            sql_mode: 
             Definer: some-magento-user@localhost
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
*************************** 3. row ***************************
             Trigger: trg_catalog_product_entity_after_delete
               Event: DELETE
               Table: catalog_product_entity
           Statement: BEGIN
INSERT IGNORE INTO `catalog_product_flat_cl` (`entity_id`) VALUES (OLD.`entity_id`);
END
              Timing: AFTER
             Created: 2018-01-10 16:04:59.57
            sql_mode: 
             Definer: some-magento-user@localhost
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci

The 3 triggers you see here all respond to changes in the table “catalog_product_entity” (see Table). The events are INSERT, UPDATE, and DELETE. Since there are 10 tables that affect the contents of the materialized view catalog_product_flat, it needs 3 x 10 = 30 triggers to cover all cases.

Conclusion

If you want to modify catalog products in a way that is not possible via Magento’s admin panel, or that can be done faster via a direct SQL query with phpMyAdmin or with a script, this is still possible, even on a production webshop. Of course you need to have a good knowledge of Magento’s MySQL tables. But the partial reindexing techniques from Update by Schedule ensure that all necessary indexes and flat tables are updated, and even specific caches are invalidated.

References :

Licensed under: CC-BY-SA with attribution
Not affiliated with magento.stackexchange
scroll top