This is actually an existing problem in the old binlog implementation, and
this patch is applicable to old binlog also. The problem is that RESET
MASTER can run concurrently with binlog dump threads / connected slaves.
This will remove the binlog from under the feet of the reader, which can
cause all sorts of strange behaviour.
This patch fixes the problem by disallowing to run RESET MASTER when dump
threads (or other RESET MASTER or SHOW BINARY LOGS) are running. An error is
thrown in this case, user must stop slaves and/or kill dump threads to make
the RESET MASTER go through. A slave that connects in the middle of RESET
MASTER will wait for it to complete.
Fix a lot of test cases to kill any lingering dump threads before doing
RESET MASTER, mostly just by sourcing include/kill_binlog_dump_threads.inc.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
Replication filtering is not safe for cluster consistency.
There is problem when two or more filtering rules are
provided by user. Here, we disable replication filtering
inside a Galera cluster for now. To support safe replication
filereing in the Galera cluster it should also effect SST/IST.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
This reverts commit 0403f0147f
for 10.6 branch. It caused MDEV-33136 test to fail in 10.6 branch.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
Issue:
When applying 'SELECT NEXT VALUE..' on applier node with
binlog_row_image=MINIMAL and log-binlog enabled, applier
node fails with below error:
Slave SQL: Could not execute Write_rows_v1 event on table monitor.seq_moni_num; Unknown error, Error_code: 1105; handler error No Error!; the event's master log FIRST, end_log_pos 0, Internal MariaDB error code: 1105
To reproduce run below command on the first/active node:
> CREATE SEQUENCE `seq_test` start with 1 minvalue 1 maxvalue 9223372036854775806 increment by 0 cache 1000 nocycle ENGINE=InnoDB;
> SELECT NEXT VALUE FOR seq_test;
> SELECT NEXT VALUE FOR seq_test;
The applier node will leave the cluster after executing
the 'SELECT NEXT VALUE' with below error:
ERROR] Slave SQL: Could not execute Write_rows_v1 event on table test.seq_test; Unknown error, Error_code: 1105; handler error No Error!; the event's master log FIRST, end_log_pos 0, Internal MariaDB error code: 1105
[Warning] WSREP: Event 3 Write_rows_v1 apply failed: 195, seqno 14511334511
Solution:
When binary loggging is enabled and binlog_row_image is set to
'MINIMAL', then 'SELECT NEXT VALUE' fails to apply on applier node.
It fails with error HA_ERR_SEQUENCE_INVALID_DATA 195 in
sequence_definition::check_and_adjust() because sequence variables
like min_value, max_value, start are 0.
The marking of all columns in 'TABLE::mark_columns_per_binlog_row_image()'
will prevent update/set column values for the sequence table.
For the sequence table column bitmap sent from master is only used.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
Remove show create table because,
Test has two concurrent statements:
(1) ALTER TABLE t1 ADD COLUMN f3 INTEGER; INSERT INTO t1 VALUES (NULL, 10000, 10000);
(2) CREATE UNIQUE INDEX i1 ON t1(f2);
If INSERT starts execution and reaches certifying state and execution
is switched to CREATE, there will be MDL-conflict. This MDL-conflict is
resolved by BF-abort (brute force abort) i.e. INSERT is aborted.
But it has already acquired value for auto_increment
column from InnoDB. INSERT is then retryed and that will cause
new auto_increment value generation. Therefore, later SHOW CREATE
TABLE could show unstable values i.e. either value that is generated
on schedule where there was no retry and value where there was a retry.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
Test changes only. INSERT may fail for lock wait because
in other node we have LOCK TABLE or it may succeed
if next statement i.e. UNLOCK TABLES is fast enough.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
@@enforce_storage_engine is local setting and there is no
knowledge how other nodes are configured. Statement
CREATE TABLE xxx ENGINE=yyy is replicated as it is and
if required engine != enforced engine it could lead
inconsistent used storage engine in the cluster.
Fix is to return error and a warning if required engine is not
same as enforced engine.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
After the membership change on a newly synced node, then this is just a
warning and safe to suppress.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
Issue:
Mariadb acquires additional MDL locks on UPDATE/INSERT/DELETE statements
on table with foreign keys. For example, table t1 references t2, an
UPDATE to t1 will MDL lock t2 in addition to t1.
A replica may deliver an ALTER t1 and UPDATE t2 concurrently for
applying. Then the UPDATE may acquire MDL lock for t1, followed by a
conflict when the ALTER attempts to MDL lock on t1. Causing a BF-BF
conflict.
Solution:
Additional keys for the referenced/foreign table needs to be added
to avoid potential MDL conflicts with concurrent update and DDLs.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
Add wait_condition to wait until all inserted rows are replicated
so that show create table is deterministic.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
Test changes only. Idea of the test is to test two concurrent
nonconflicting DDL-clauses. Therefore, use debug sync to
really execute two DDL-clauses as concurrently as Galera
allows.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
Additional corrections: there is a natural race between closing connection
to cluster in case of applying error and finishing the IST and sometimes
IST finishes and tries to send JOIN message over a closed connection.
This does not affect the correctness of the test or node behavior.
Added error message suppression.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
Delaying scripts on joiner after SST/IST has been made
a common debug feature for all suitable SST/IST methods.
Also some minor fixes have been made for new tests.
After cluster vote to evict a node that failed a transaction,
current master can't commit anymore.
Error voting for joiner in the JOINED state was broken because
the group-wide commit cut (implicit SUCCESS vote) was not taken
into account when processing error vote request from the JOINED
node.
This commit adds 3 MTR tests to verify the fix in the galera
library works as designed.
Requires Galera library commit 91f0090a05e96c3cc353b80d961ede45cefb9279
(galera library version > 26.4.19).
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
Problem was that transacton was BF-aborted after certification
succeeded and transaction tried to rollback and during
rollback binlog stmt cache containing sequence value reservations
was written into binlog.
Transaction must replay because certification succeeded but
transaction must not be written into binlog yet, it will
be done during commit after the replay.
Fix is to skip binlog write if transaction must replay and
in replay we need to reset binlog stmt cache.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
The mariadb-backup --use-memory parameter will be trimmed to a multiple
of 8 MiB, or 2 MiB on 32-bit systems.
Also, let us remove a bogus message in mariadb-backup:
Warning: option 'use-memory': signed value -1 adjusted to 8388608
