(8.0) PS-7806: Column compression breaks async replication on PS #5162

kamil-holubicki · 2023-11-17T10:44:50Z

https://jira.percona.com/browse/PS-7806

Work based on the original patch for 8.0 by Nitendra Bhosle.

Problem:
When the statement related to the partitioned table containing
compressed BLOB columns is replicated, replica stops with error.
e.g. DELETE FROM t1 WHERE d2 = 0.00000 ;

Cause:
Queries like mentioned delete are implemented in the following way:

Index scan is performed
For every matching row, the row is deleted
Query is rewritten, using all columns in WHERE clause.

For partitioned tables, during the ordered scan, we read (and keep)
the next record from every partition, and then do ordering of cached
records, returning the first in order
(logic in Partition_helper::handle_ordered_index_scan()).
However, we use common prebuilt->compression_heap which is cleaned up
before every row read. This causes that rows cached for particular
partitions are freed and overwritten by next partition's row during
rows read loop in Partition_helper::handle_ordered_index_scan().
Then the query is being binlogged, but blob pointer may be invalid,
pointing to overwritten memory, so rewritten query contains wrong value
for BLOB column.
When received by replica, such row does not exists and replica stops.

Solution:
Implemented dedicated compression_heap for every partition, similarly to
already existing blob_heap.

kamil-holubicki · 2023-11-17T10:47:29Z

https://ps80.cd.percona.com/view/8.0%20parallel%20MTR/job/percona-server-8.0-pipeline-parallel-mtr/358/

https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap.

satya-bodapati

@kamil-holubicki many commits came along, can you please check?

) https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap. (cherry picked from commit 6797697)

https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap. (cherry picked from commit 6797697)

https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap.

… PS (percona#5162) https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap.

) https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap. (cherry picked from commit 6797697)

… PS (percona#5162) https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap.

… PS (percona#5162) https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap. (cherry picked from commit 6797697)

… PS (percona#5162) https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap.

… PS (percona#5162) https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap. (cherry picked from commit 6797697)

… PS (#5162) https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap.

… PS (percona#5162) https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap. (cherry picked from commit 6797697)

… PS (percona#5162) https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap. (cherry picked from commit 6797697) ---------------------------------------------------------------------- PS-9218: Merge MySQL 8.4.0 (fix terminology in replication tests) https://perconadev.atlassian.net/browse/PS-9218 mysql/mysql-server@44a77b5

… PS (#5162) https://jira.percona.com/browse/PS-7806 Work based on the original patch for 8.0 by Nitendra Bhosle. Problem: When the statement related to the partitioned table containing compressed BLOB columns is replicated, replica stops with error. e.g. DELETE FROM t1 WHERE d2 = 0.00000 ; Cause: Queries like mentioned delete are implemented in the following way: 1. Index scan is performed 2. For every matching row, the row is deleted 3. Query is rewritten, using all columns in WHERE clause. For partitioned tables, during the ordered scan, we read (and keep) the next record from every partition, and then do ordering of cached records, returning the first in order (logic in Partition_helper::handle_ordered_index_scan()). However, we use common prebuilt->compression_heap which is cleaned up before every row read. This causes that rows cached for particular partitions are freed and overwritten by next partition's row during rows read loop in Partition_helper::handle_ordered_index_scan(). Then the query is being binlogged, but blob pointer may be invalid, pointing to overwritten memory, so rewritten query contains wrong value for BLOB column. When received by replica, such row does not exists and replica stops. Solution: Implemented dedicated compression_heap for every partition, similarly to already existing blob_heap. (cherry picked from commit 6797697) ---------------------------------------------------------------------- PS-9218: Merge MySQL 8.4.0 (fix terminology in replication tests) https://perconadev.atlassian.net/browse/PS-9218 mysql/mysql-server@44a77b5