Commit graph

980 commits

Author SHA1 Message Date
sachin
ada54101a7 MDEV-9266 Creating index on temporaray table breaks replication
Problem:- Create/drop index was logged into binlog.

Goal:- Operation on temporary table should not be binlog when binlog format
is row.

Solution:-
We should add CF_FORCE_ORIGINAL_BINLOG_FORMAT when there is ddl on temp
table.
For optimize, analyze, repair we wont change anything ,Then will
be logged in binlog , But they also dont throw any error if operation fails
Since slave wont be having any temp table , but these operation on tmp
table will be processed without breaking replication.

For rename we need a different logic MDEV-16728 will solve it.
2018-07-18 17:13:24 +05:30
Daniel Black
2f07709aed MDEV-12436: binlog.binlog_unsafe - assumed len(hostname) <= 50 ()
Increased size in tests to allow for 100 character hostname.

Signed-off-by: Daniel Black <daniel.black@au.ibm.com>
2017-07-15 19:45:37 +03:00
Nirbhay Choubey
f7e03d4419 MDEV-4774: Fix test case 2017-01-30 18:35:26 -05:00
Sachin Setiya
18ef02b04d MDEV-4774 Strangeness with max_binlog_stmt_cache_size Settings
Problem:- When setting max_binlog_stmt_cache_size=18446744073709547520
from either command line or .cnf file, server fails to start.

Solution:- Added one more function eval_num_suffix_ull , which uses
strtoull to get unsigned ulonglong from string. And getopt_ull calls this
function instead of eval_num_suffix. Also changed previous eval_num_suffix to
eval_num_suffix_ll to remain consistent.
2017-01-20 21:33:36 +05:30
Sergei Golubchik
3e8155c637 Merge branch '5.5' into 10.0 2016-12-09 16:33:48 +01:00
Sergei Golubchik
f640527e65 typo fixed: s/MSYQL/MYSQL/ 2016-12-03 22:02:00 +01:00
Sergei Golubchik
309c08c17c Merge branch '5.5' into 10.0 2016-08-10 19:19:05 +02:00
Sergei Golubchik
a350e53b61 Merge branch 'mysql/5.5' into 5.5
without a fix for Bug#12818255 (MDEV-6581)
2016-08-03 20:38:25 +02:00
Sujatha Sivakumar
818b3a9123 Bug#12818255: READ-ONLY OPTION DOES NOT ALLOW
INSERTS/UPDATES ON TEMPORARY TABLES
Bug#14294223: CHANGES NOT ALLOWED TO TEMPORARY TABLES ON
READ-ONLY SERVERS

Problem:
========
Running 5.5.14 in read only we can create temporary tables
but can not insert or update records in the table. When we
try we get Error 1290 : The MySQL server is running with the
--read-only option so it cannot execute this statement.

Analysis:
=========
This bug is very specific to binlog being enabled and
binlog-format being stmt/mixed. Standalone server without
binlog enabled or with row based binlog-mode works fine.

How standalone server and row based replication work:
=====================================================
Standalone server and row based replication mark the
transactions as read_write only when they are modifying
non temporary tables as part of their current transaction.

Because of this when code enters commit phase it checks
if a transaction is read_write or not. If the transaction
is read_write and global read only mode is enabled those
transaction will fail with 'server is read only mode'
error.

In the case of statement based mode at the time of writing
to binary log a binlog handler is created and it is always
marked as read_write. In case of temporary tables even
though the engine did not mark the transaction as read_write
but the new transaction that is started by binlog handler is
considered as read_write.

Hence in this case when code enters commit phase it finds
one handler which has a read_write transaction even when
we are modifying temporary table. This causes the server
to throw an error when global read-only mode is enabled.

Fix:
====
At the time of commit in "ha_commit_trans" if a read_write
transaction is found, we should check if this transaction is
coming from a handler other than binlog_handler. This will
ensure that there is a genuine read_write transaction being
sent by the engine apart from binlog_handler and only then
it should be blocked.
2016-05-04 14:06:45 +05:30
Sergei Golubchik
872649c7ba Merge branch '5.5' into 10.0 2016-04-26 23:05:26 +02:00
Sergei Golubchik
b069d19284 Merge branch 'mysql/5.5' into 5.5 2016-04-20 15:25:55 +02:00
Venkatesh Duggirala
29cc2c2883 BUG#20574550 MAIN.MERGE TEST CASE FAILS IF BINLOG_FORMAT=ROW
The main.merge test case was failing when tested using row based
binlog format.

While analyzing the issue it was found the following issues:

a) The server is calling binlog related code even when a statement will
   not be binlogged;
b) The child table list was not present into table structure by the time
   to generate the create table statement;
c) The tables in the child table list will not be opened yet when
   generating table create info using row based replication;
d) CREATE TABLE LIKE TEMP_TABLE does not preserve original table storage
   engine when using row based replication;

This patch addressed all above issues.

@ sql/sql_class.h

Added a function to determine if the binary log is disabled to
  the current session. This is related with issue (a) above.

@ sql/sql_table.cc

Added code to skip binary logging related code if the statement
  will not be binlogged. This is related with issue (a) above.

Added code to add the children to the query list of the table that
  will have its CREATE TABLE generated. This is related with issue (b)
  above.

Added code to force the storage engine to be generated into the
  CREATE TABLE. This is related with issue (d) above.

@ storage/myisammrg/ha_myisammrg.cc

Added a test to skip a table getting info about a child table if the
  child table is not opened. This is related to issue (c) above.
2016-02-26 09:01:49 +05:30
Sergei Golubchik
cfeedbfd3e Merge branch '5.5' into 10.0 2015-10-09 17:12:26 +02:00
Oleksandr Byelkin
29ac245dd0 MDEV-8473: mysqlbinlog -v does not properly decode DECIMAL values in an RBR log
Backport of upstream patch. revno: 5696
2015-09-07 13:13:52 +02:00
Jan Lindström
9a5787db51 Merge commit '96badb16afcf' into 10.0
Conflicts:
	client/mysql_upgrade.c
	mysql-test/r/func_misc.result
	mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
	mysql-test/suite/innodb/r/innodb-fk.result
	mysql-test/t/subselect_sj_mat.test
	sql/item.cc
	sql/item_func.cc
	sql/log.cc
	sql/log_event.cc
	sql/rpl_utility.cc
	sql/slave.cc
	sql/sql_class.cc
	sql/sql_class.h
	sql/sql_select.cc
	storage/innobase/dict/dict0crea.c
	storage/innobase/dict/dict0dict.c
	storage/innobase/handler/ha_innodb.cc
	storage/xtradb/dict/dict0crea.c
	storage/xtradb/dict/dict0dict.c
	storage/xtradb/handler/ha_innodb.cc
	vio/viosslfactories.c
2015-08-03 23:09:43 +03:00
Sergey Vojtovich
392df76bc3 MDEV-4017 - GET_LOCK() with negative timeouts has strange behavior
GET_LOCK() silently accepted negative values and NULL for timeout.
Fixed GET_LOCK() to issue a warning and return NULL in such cases.
2015-07-29 15:59:56 +04:00
Sergei Golubchik
810cf362ea Merge branch '5.5' into 10.0 2015-06-11 20:20:35 +02:00
Alexander Barkov
9da8a8f946 MDEV-7269 mysqlbinlog Don't know how to handle column type=0 meta=0 (0000)#
MDEV-8267 Add /*old*/ comment into I_S.COLUMN_TYPE for old DECIMAL
2015-06-04 18:49:12 +04:00
Sergei Golubchik
49c853fb94 Merge branch '5.5' into 10.0 2015-05-04 22:00:24 +02:00
Kristian Nielsen
9088f26f20 MDEV-7802: group commit status variable addition
Backport into 10.0
2015-04-29 11:29:25 +02:00
Sergei Golubchik
e26b2071be MDEV-7938 MariaDB Crashes Suddenly while writing binlogs
on disconnect THD must clean user_var_events array before
dropping temporary tables. Otherwise when binlogging a DROP,
it'll access user_var_events, but they were allocated
in the already freed memroot.
2015-04-27 15:42:12 +02:00
Kristian Nielsen
184f718fef MDEV-7249: Performance problem in parallel replication with multi-level slaves
Parallel replication (in 10.0 / "conservative" mode) relies on binlog group
commits to group transactions that can be safely run in parallel on the
slave. The --binlog-commit-wait-count and --binlog-commit-wait-usec options
exist to increase the number of commits per group. But in case of conflicts
between transactions, this can cause unnecessary delay and reduced througput,
especially on a slave where commit order is fixed.

This patch adds a heuristics to reduce this problem. When transaction T1 goes
to commit, it will first wait for N transactions to queue up for a group
commit. However, if we detect that another transaction T2 is waiting for a row
lock held by T1, then we will skip the wait and let T1 commit immediately,
releasing locks and let T2 continue.

On a slave, this avoids the unfortunate situation where T1 is waiting for T2
to join the group commit, but T2 is waiting for T1 to release locks, causing
no work to be done for the duration of the --binlog-commit-wait-usec timeout.

(The heuristic seems reasonable on the master as well, so it is enabled for
all transactions, not just replication transactions).
2015-03-13 14:01:52 +01:00
Sergei Golubchik
d7e7862364 Merge branch '5.5' into 10.0 2015-02-18 15:16:27 +01:00
Sergei Golubchik
8e80f91fa3 Merge remote-tracking branch 'mysql/5.5' into bb-5.5-merge @ mysql-5.5.42 2015-02-11 23:50:40 +01:00
Sergei Golubchik
d9c01e4b4a 5.5 merge 2015-01-21 12:03:02 +01:00
Sergei Golubchik
510ca9b697 MDEV-7402 'reset master' hangs, waits for signalled COND_xid_list
Using a boolean flag for 'there is a RESET MASTER in progress' doesn't
work very well for multiple concurrent RESET MASTER statements.
Changed to a counter.
2015-01-19 14:32:28 +01:00
s.sujatha
5da083ef67 Bug#20041860: SLAVE ERROR WHEN DROP DATABASE
Fix:
===
Backport Bug#11756194 to mysql-5.5. slave breaks if
'drop database' fails on master and mismatched tables on
slave.

'DROP TABLE <deleted tables>' was binlogged when
'DROP DATABASE' failed and at least one table was deleted
from the database. The log event would lead slave SQL thread
stop if some of the tables did not exist on slave.

After this patch, It is always binlogged with 'IF EXISTS'
option.
2014-12-29 12:17:55 +05:30
Sergei Golubchik
a978bdda1e mysql-5.5.41 merge 2014-12-19 11:35:44 +01:00
Sergei Golubchik
3495801e2e 5.5 merge 2014-11-19 17:23:39 +01:00
Sergei Golubchik
84f25c25f2 MDEV-3940 Server crash or assertion `item->type() == Item::STRING_ITEM' failure on LOAD DATA through a view with statement binary logging
A "field" could be either an Item_field or
(if loading into a view) an Item_direct_ref that references Item_field.

Also: when iterating fields, use fields of the TABLE_LIST (table or view),
not fields of a TABLE (actual underlying table - might have more columns).
2014-11-18 15:42:32 +01:00
Bill Qu
cdb8e6ed38 Bug USING SET GLOBAL SQL_LOG_BIN SHOULD NOT BE ALLOWED
Normally, SET SESSION SQL_LOG_BIN is used by DBAs to run a
non-conflicting command locally only, ensuring it does not
get replicated.
Setting GLOBAL SQL_LOG_BIN would not require all sessions to
disconnect. When SQL_LOG_BIN is changed globally, it does not
immediately take effect for any sessions. It takes effect by
becoming the session-level default inherited at the start of
each new session, and this setting is kept and cached for the
duration of that session. Setting it intentionally is unlikely
to have a useful effect under any circumstance; setting it
unintentionally, such as while intending to use SET [SESSION]
is potentially disastrous. Accidentally using SET GLOBAL
SQL_LOG_BIN will not show an immediate effect to the user,
instead not having the desired session-level effect, and thus
causing other potential problems with local-only maintenance
being binlogged and executed on slaves; And transactions from
new sessions (after SQL_LOG_BIN is changed globally) are not
binlogged and replicated, which would result in irrecoverable
or difficult data loss.
This is the regular GLOBAL variables way to work, but in
replication context it does not look right on a working server
(with connected sessions) 'set global sql_log_bin' and none of
that connections is affected. Unexperienced DBA after noticing
that the command did "nothing" will change the session var and
most probably won't unset the global var, causing new sessions
to not be binlog.
Setting GLOBAL SQL_LOG_BIN allows DBA to stop binlogging on all
new sessions, which can be used to make a server "replication
read-only" without restarting the server. But this has such big
requirements, stop all existing connections, that it is more
likely to make a mess, it is too risky to allow the GLOBAL variable.

The statement 'SET GLOBAL SQL_LOG_BIN=N' will produce an error
in 5.5, 5.6 and 5.7. Reading the GLOBAL SQL_LOG_BIN will produce
a deprecation warning in 5.7.
2014-09-24 09:44:48 +08:00
Bill Qu
5693b1e4a4 Bug USING SET GLOBAL SQL_LOG_BIN SHOULD NOT BE ALLOWED
Normally, SET SESSION SQL_LOG_BIN is used by DBAs to run a
non-conflicting command locally only, ensuring it does not
get replicated.
Setting GLOBAL SQL_LOG_BIN would not require all sessions to
disconnect. When SQL_LOG_BIN is changed globally, it does not
immediately take effect for any sessions. It takes effect by
becoming the session-level default inherited at the start of
each new session, and this setting is kept and cached for the
duration of that session. Setting it intentionally is unlikely
to have a useful effect under any circumstance; setting it
unintentionally, such as while intending to use SET [SESSION]
is potentially disastrous. Accidentally using SET GLOBAL
SQL_LOG_BIN will not show an immediate effect to the user,
instead not having the desired session-level effect, and thus
causing other potential problems with local-only maintenance
being binlogged and executed on slaves; And transactions from
new sessions (after SQL_LOG_BIN is changed globally) are not
binlogged and replicated, which would result in irrecoverable
or difficult data loss.
This is the regular GLOBAL variables way to work, but in
replication context it does not look right on a working server
(with connected sessions) 'set global sql_log_bin' and none of
that connections is affected. Unexperienced DBA after noticing
that the command did "nothing" will change the session var and
most probably won't unset the global var, causing new sessions
to not be binlog.
Setting GLOBAL SQL_LOG_BIN allows DBA to stop binlogging on all
new sessions, which can be used to make a server "replication
read-only" without restarting the server. But this has such big
requirements, stop all existing connections, that it is more
likely to make a mess, it is too risky to allow the GLOBAL variable.

The statement 'SET GLOBAL SQL_LOG_BIN=N' will produce an error
in 5.5, 5.6 and 5.7. Reading the GLOBAL SQL_LOG_BIN will produce
a deprecation warning in 5.7.
2014-09-24 09:44:48 +08:00
Sergei Golubchik
152f1cd086 print binlog unsafe errors at log_warnings level 1, not 2. 2014-09-18 15:24:30 +02:00
Michael Widenius
8e4566e912 Don't give warning if there are two unique keys used with INSERT .. ON DUPLICATE KEY UPDATE.
We should assume that the store engine will report the first duplicate key for this case.

Old code of suppression of unsafe logging error with LIMIT didn't work, because of wrong usage of my_interval_timer().

Suppress unsafe logging errors to the error log if we get too many unsafe logging errors in a short time.
This is to not overflow the error log with meaningless errors.

- Each error code is suppressed and counted separately.
- We do a 5 minute suppression of new errors if we get more than 10 errors in that time.

Only print unsafe logging errors if log_warnings > 1.



mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result:
  Update test results as INSERT ... ON DUPLICATE KEY UPDATE doesn't get logged anymore
mysql-test/suite/binlog/r/binlog_unsafe.result:
  Update test results as INSERT ... ON DUPLICATE KEY UPDATE doesn't get logged anymore
mysql-test/suite/engines/README:
  Fixed typos
mysql-test/suite/rpl/r/rpl_known_bugs_detection.result:
  Update test results as INSERT ... ON DUPLICATE KEY UPDATE doesn't get logged anymore
sql/sql_base.cc:
  Don't log warning if there are two unique keys used with INSERT .. ON DUPLICATE KEY UPDATE.
  We should assume that the store engine will report the first duplicate key for this case.
sql/sql_class.cc:
  Suppress error in binary log if we get too many unsafe logging errors in a short time.
  Only print unsafe logging errors if log_warnings > 1
2014-09-16 00:00:47 +03:00
Sergei Golubchik
e27c338634 5.5.38 merge 2014-06-06 00:07:27 +02:00
Sergei Golubchik
5d16592d44 mysql-5.5.38 merge 2014-06-03 09:55:08 +02:00
Sergei Golubchik
d3e2e1243b 5.5 merge 2014-05-09 12:35:11 +02:00
Alexander Barkov
fbfa004327 MDEV-6170 Incorrect ordering with utf8_bin and utf8mb4_bin collations 2014-04-25 17:10:25 +04:00
Sujatha Sivakumar
1b74f2e3da Bug#17942050:KILL OF TRUNCATE TABLE WILL LEAD TO BINARY LOG
WRITTEN WHILE ROWS REMAINS

Problem:
========
When truncate table fails while using transactional based
engines even though the operation errors out we still
continue and log it to binlog. Because of this master has
data but the truncate will be written to binary log which
will cause inconsistency.

Analysis:
========
Truncate table can happen either through drop and create of
table or by deleting rows. In the second case the existing
code is written in such a way that even if an error occurs
the truncate statement will always be binlogged. Which is not
correct.

Binlogging of TRUNCATE TABLE statement should check whether
truncate is executed "transactionally or not". If the table
is transaction based we log the TRUNCATE TABLE only on
successful completion.

If table is non transactional there are possibilities that on
error we could have partial changes done hence in such cases
we do log in spite of errors as some of the lines might have
been removed, so the statement has to be sent to slave.

Fix:
===
Using table handler whether truncate table is being executed
in transaction based mode or not is identified and statement
is binlogged accordingly.

mysql-test/suite/binlog/r/binlog_truncate_kill.result:
  Added test case to test the fix for Bug#17942050.
mysql-test/suite/binlog/t/binlog_truncate_kill.test:
  Added test case to test the fix for Bug#17942050.
sql/sql_truncate.cc:
  Check if truncation is successful or not and retun appropriate
  return values so that binlogging can be done based on that.
sql/sql_truncate.h:
  Added a new enum.
2014-04-15 15:17:25 +05:30
Sujatha Sivakumar
58b9807826 Bug#17942050:KILL OF TRUNCATE TABLE WILL LEAD TO BINARY LOG
WRITTEN WHILE ROWS REMAINS

Problem:
========
When truncate table fails while using transactional based
engines even though the operation errors out we still
continue and log it to binlog. Because of this master has
data but the truncate will be written to binary log which
will cause inconsistency.

Analysis:
========
Truncate table can happen either through drop and create of
table or by deleting rows. In the second case the existing
code is written in such a way that even if an error occurs
the truncate statement will always be binlogged. Which is not
correct.

Binlogging of TRUNCATE TABLE statement should check whether
truncate is executed "transactionally or not". If the table
is transaction based we log the TRUNCATE TABLE only on
successful completion.

If table is non transactional there are possibilities that on
error we could have partial changes done hence in such cases
we do log in spite of errors as some of the lines might have
been removed, so the statement has to be sent to slave.

Fix:
===
Using table handler whether truncate table is being executed
in transaction based mode or not is identified and statement
is binlogged accordingly.
2014-04-15 15:17:25 +05:30
Alexander Barkov
f5b73fe3f1 Merge from 5.3. 2014-04-21 12:19:47 +04:00
Alexander Barkov
5fc5195fc5 An after-fix for
MDEV-6134 SUBSTRING_INDEX returns wrong result for 8bit character sets when delimiter is not found

Recording the forgotten test results.
2014-04-21 11:29:50 +04:00
Sergei Golubchik
b7b991add0 fix tests to cleanup after themselves 2014-02-06 16:27:55 +01:00
Alexander Barkov
9f4dd86c2e Merge 10.0-base->10.0 2013-12-17 17:28:48 +04:00
Alexander Barkov
768751c786 Merge 5.5->10.0-base 2013-12-17 16:23:08 +04:00
Alexander Barkov
dc407270a1 MDEV-5453 Assertion `src' fails in my_strnxfrm_unicode on GROUP BY MID(..) WITH ROLLUP
Fixed a wrong assertion.
2013-12-17 15:19:26 +04:00
Sergei Golubchik
d28d3ba40d 10.0-base merge 2013-12-16 13:02:21 +01:00
Sergei Golubchik
6ae5f0efea MDEV-5115 RBR from MySQL 5.6 to MariaDB 10.0 does not work
Patially merge WL#5917, to understand v2 row events
2013-12-09 12:37:45 +01:00
Sergei Golubchik
c6d30805db 5.5 merge 2013-11-23 00:50:54 +01:00
Sergei Golubchik
fa3f8a18b2 mysql-5.5.34 merge
(some patches reverted, test case added)
2013-11-19 13:16:25 +01:00