-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Product EAV index throws error with GTID consistency #12124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The problem was fixed for me after installing this module: |
@Gvigner Thanks for the tip! It seems like this is one of those things that belongs in core. |
@scrivvles, thank you for your report. |
Great news! |
@Gvigner for us didnt worked in all projects, it depends if root category is assigned to a store or not, which makes create sub-category failing under some circumstances |
Linking to #11055 The Module |
Issue 15209 reports the same MySQL error while creating a category with MySQL binary logging enabled. |
Any update for this? |
Still broken on 2.2 and 2.3 over a year after being reported :( Magento should be able to run on a MySQL installation with binary logging enabled. |
Magento 2.3.0 don't run on a MySQL installation with binary logging enabled. |
Is there any update? At the very least the docs should be updated to indicate this issue and a workaround if one is available, such as ignoring temporary tables. |
FOR GOOGLE CLOUD SQL USERS I'm trying to migrate a 2.3 CE database to Google Cloud SQL on a 2nd gen server. Upon reindexing I get the "violates GTID consistency" error for the Product EAV index. There's little info on the forums so far, so thought I'd contribute my findings.
SOLUTION: I'm on M2.3 CE and not using db replication, so I just tried to disable "Binary Logging" on the SQL Server. Go to instance > click Edit > go to Enable auto-backups > Uncheck "Enable binary logging (required for replication and earlier position point-in-time recovery)". Test I understand the limitations to this approach, but until Magento gets their act together (don't hold your breath, issue ongoing since 2017), this is the only way I can find to run M2.3 on Google SQL 2nd Gen Servers. |
Hello, Any update about this ? Are you working on it and do you have an idea when it will be fixed ?
Thanks |
@dferdoille you are welcome to try my solution at https://github.com/alexgoodey/magento_gtid_fix No guarantees. |
I believe this can be marked as a duplicate of #15209, as that is scheduled for remediation. |
@dharake Are you still hosting 2.3 on GCP's cloud SQL service? Disabling binary logging does not disable the GTID settings. Magento2 still throws exceptions in various places, like updating stock, reorganizing categories, indexing. |
I investigated the EAV indexer code to figure out what's going wrong. Found out that this commit configured the indexer with a Because this temp table is causing issues. I disabled the TempTableStrategy to default to the regular TableStrategy for the EAV indexer in file: <type name="Magento\Catalog\Model\ResourceModel\Product\Indexer\Eav\Source">
<arguments>
<!-- <argument name="tableStrategy" xsi:type="object">Magento\Catalog\Model\ResourceModel\Product\Indexer\TemporaryTableStrategy</argument> -->
<argument name="connectionName" xsi:type="string">indexer</argument>
</arguments>
</type> When using the regular TableStrategy, which is using the magento@magento-admin:/app$ bin/magento indexer:reindex catalog_product_attribute
Product EAV index has been rebuilt successfully in 00:00:00 However I don't like to alter the private function reindexBatch(PriceInterface $priceIndexer, Select $batch): void
{
$entityIds = $this->getEntityIdsFromBatch($batch);
if (!empty($entityIds)) {
// Temporary table will created if not exists
$idxTableName = $this->_defaultIndexerResource->getIdxTable();
$this->_emptyTable($idxTableName);
if ($priceIndexer->getIsComposite()) {
$this->_copyRelationIndexData($entityIds);
}
// Reindex entities by id
$priceIndexer->reindexEntity($entityIds);
// Sync data from temp table to index table
$this->_insertFromTable($idxTableName, $this->getReplicaTable());
// Drop temporary index table
$this->_defaultIndexerResource->getConnection()->dropTable($idxTableName);
}
}
..
protected function _insertFromTable($sourceTable, $destTable, $where = null)
{
$sourceColumns = array_keys($this->getConnection()->describeTable($sourceTable));
$targetColumns = array_keys($this->getConnection()->describeTable($destTable));
$select = $this->getConnection()->select()->from($sourceTable, $sourceColumns);
if ($where) {
$select->where($where);
}
$query = $this->getConnection()->insertFromSelect(
$select,
$destTable,
$targetColumns,
\Magento\Framework\DB\Adapter\AdapterInterface::INSERT_ON_DUPLICATE
);
$this->getConnection()->query($query);
} Source: I'm no Magento developer, but it seems valid to not use a transaction in this context. Simply because it's just staging data from a clean temp table to a result set. Anyhow, I first validated this idea by removing the transactions from the Eav syncData-method. /**
* @inheritdoc
*/
protected function syncData($indexer, $destinationTable, $ids = null): void
{
$connection = $indexer->getConnection();
$sourceTable = $indexer->getIdxTable(); // Here the temp table is created, and in context of a transaction, also our issue..
$sourceColumns = array_keys($connection->describeTable($sourceTable));
$targetColumns = array_keys($connection->describeTable($destinationTable));
$select = $connection->select()->from($sourceTable, $sourceColumns);
$query = $connection->insertFromSelect(
$select,
$destinationTable,
$targetColumns,
AdapterInterface::INSERT_ON_DUPLICATE
);
$connection->query($query);
// $connection = $indexer->getConnection();
// $connection->beginTransaction();
// try {
// $sourceTable = $indexer->getIdxTable();
// $sourceColumns = array_keys($connection->describeTable($sourceTable));
// $targetColumns = array_keys($connection->describeTable($destinationTable));
// $select = $connection->select()->from($sourceTable, $sourceColumns);
// $query = $connection->insertFromSelect(
// $select,
// $destinationTable,
// $targetColumns,
// AdapterInterface::INSERT_ON_DUPLICATE
// );
// $connection->query($query);
// $connection->commit();
// } catch (\Exception $e) {
// $connection->rollBack();
// throw $e;
// }
} This change resolves the GTID issue in my installation. Logically this only fixes the Product EAV GTID issue. So I'm not sure if this makes Magento GTID consistent, but for our installation it would be an improvement. Like to hear from a Magento developer on how to get this change tested/patched/merged etc. |
I just asked Google why cloud SQL does not support CREATE TEMPORARY TABLE statement. The Google support create a public issue and ask me to "leaving a comment explaining how this affects your use case, as this will increase its visibility to the Product Team." If you are interested too, maybe you could add a comment |
We need this solved.. |
Hi @scrivvles,
Currently, Magento 2.4 supports MySQL 8 https://devdocs.magento.com/guides/v2.4/install-gde/system-requirements.html. Could you confirm that this issue is fixed now? |
Hi @ihor-sviziev. Thank you for working on this issue.
|
Note I created PR that adds note to dev docs. magento/devdocs#9111 |
Attempting to reindex the Product EAV when binary logging or replication is enabled on MySQL 5.7throws a SQL error. This same type of error is thrown when attempting to create a new category.
Preconditions
Steps to reproduce
php bin/magento indexer:reindex
Expected result
All indexes run correctly and display that they have rebuilt successfully
Actual result
SQLSTATE[HY000]: General error: 1787 Statement violates GTID consistency: CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed outside transactional context. These statements are also not allowed in a function or trigger because functions and triggers are also considered to be multi-statement transactions., query was: CREATE TEMPORARY TABLE IF NOT EXISTS catalog_product_index_eav_temp LIKE catalog_product_index_eav_tmp
This error indicates that there is a transaction that violates GTID consistency somewhere in the Product EAV indexing SQL. One suggestion that was made to avoid this problem would be a CREATE VIEW instead of CREATE TEMPORARY TABLE in the indexer module.
The text was updated successfully, but these errors were encountered: