Re: [Maria-developers] MDEV-7937: Enforce SSL when --ssl client option is used
Hi, Vicențiu! On May 17, Vicențiu Ciorbaru wrote: Hi Sergei! I've done some work on this issue. I've read MySQL's implementation of this and have looked at our implementation. They have done a bit of refactoring, introducing an enforce_ssl flag, as well as changing the C interface a bit, to allow setting this flag programatically. I didn't check what they did. Do you, perhaps, have links to MySQL commits? There are two more things that I'm not sure of: 1. Specifying --ssl as a command line parameter to the mysql client is not enough to enforce ssl and the client's code in this case just ignores the option. We need to provide at least one of the additional ones like --ssl-key or --ssl-ca. My patch will not cause the client to report an error in this case. Is this acceptable behaviour or not? Up to you. I agree that this behavior is confusing. 2. Do we want mysql's enforce_ssl feature? With your patch we don't need it, do we? = A related thought Even if you enforce SSL, you still cannot be sure that there is no MITM. You can be connected to an SSL proxy that decrypts your data, modifies them, if needed, and then sends (over SSL) to the server. To know that you connect to the actual MariaDB server, you need to check the certificate, the mere fact of SSL encryption is not enough. Right? And if you check the SSL certificate, then there is no need to enforce SSL, because you won't connect if you won't see the correct certificate anyway. If I'm right it means that enforcing SSL isn't very useful. Those who care about their connection security, they check certificates. Those who don't do that - they get a false sense of security by enforcing SSL. Is that so? If yes, it means the efforts should be not simpy to enforce SSL, but to have a good certificate verification check (I don't know if the existing one is good enough) and to double-check that if CLIENT_SSL_VERIFY_SERVER_CERT flag is used, then we never connect without verifying the certificate (I think without SSL the verification is simply skipped now). Regards, Sergei ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Please review: MDEV-7824 [Bug #68041] Zero date can be inserted in strict no-zero mode through a default value
Hi Sergei,
Thanks for review! See my comments inline:
On 05/07/2015 06:57 PM, Sergei Golubchik wrote:
Hi, Alexander!
On Mar 25, Alexander Barkov wrote:
Hi Sergei,
Please review a patch for mdev-7824.
It's based on a MySQL patch for
http://bugs.mysql.com/bug.php?id=68041
and is a blocker for:
MDEV-3929 Add full support for auto-initialized/updated timestamp and
datetime
That looks good.
But I don't like it that you verify defaults for every row.
It's not very cheap. And neither defaults nor sql_mode can change in the
duration of one statement. It should be enough to test only once.
This is a good idea. I copied the patch from MySQL. So it will be nice
to have this implemented in MariaDB in a faster way.
I'm not sure, though, how to do that with a minimal overhead. A couple
of bool's in TABLE, like
bool all_default_are_checked;
bool write_set_defaults_are_checked;
that are set to false at the beginning on INSERT,INSERT...SELECT,LOAD.
And used like that
bool TABLE::restore_record_and_validate_unset_fields(THD *thd, bool all)
{
restore_record(this, s-default_values);
if (all ? all_default_are_checked : write_set_defaults_are_checked)
return false;
if (all) all_default_are_checked= true;
else write_set_defaults_are_checked= true;
return validate_default_values_of_unset_fields(thd);
}
and in mysql_insert():
if (fields.elements || !value_count)
{
if (table-restore_record_and_validate_unset_fields(thd, !value_count))
Sorry, I did't understand your idea about having two separate
flags for all and write_set.
Is it for the cases when one mixes empty and non-empty parenthesized
value lists, like these:
insert into (a,b) t1 values (),(10,20);
insert into (a,b) t1 values (10,20),();
???
Note, this currently does not work and return this error:
ERROR 1136 (21S01): Column count doesn't match value count at row 2
Looks like a bug. I guess this could work.
If so, would you like me to report and fix it before mdev-7824?
Thanks.
Regards,
Sergei
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] MDEV-8112: PATCH: no slave left behind
Hi Jonas,
Thanks for the patch!
I read through the patch. I am not that familiar with the semi-sync plugin
code, but it looks reasonable.
But the patch causes a test failure in sys_vars.all_vars. This is because
not all newly introduced variables have corresponding test cases in
mysql-test/suite/sys_vars/t/*_basic.test.
Also, do you have some documentation for the feature? (There is a bit in the
Jira entry, but for example the new variable
rpl_semi_sync_master_slave_lag_heartbeat_frequency_us seems to be not
described at all...
If you can fix the above two points (and if Buildbot does not point out more
test suite issues), then I will push it into the MariaDB tree.
Thanks,
- Kristian.
patch has been ported to 10.1
you can use it under new (also called 3-clause) BSD license
i have done internal benchmarks...but you are most welcome to do some too.
DESCRIPTION:
no slave left behind
this patch implements master throttling based on slave lag,
aka no slave left behind. the core feature works as follows
1) the semi-sync-reply is ammended to also report back SQL-thread
position (aka exec position)
2) transactions are not removed from the active-transaction-list
in the semi-sync-master plugin until atleast one slave has reported
that it has executed this transaction. the slave lag can then
be estimated by calculating how long the oldest transaction has been
lingering in the active-transaction-list.
3) client-threads are forced to wait before commit until slave lag
has decreased to acceptable value.
the following variables are introduced on master:
rpl_semi_sync_master_max_slave_lag (global)
rpl_semi_sync_master_slave_lag_wait_timeout (session)
the following status variables are introduced on master:
rpl_semi_sync_master_slave_lag_wait_sessions
rpl_semi_sync_master_estimated_slave_lag
rpl_semi_sync_master_trx_slave_lag_wait_time
rpl_semi_sync_master_trx_slave_lag_wait_num
rpl_semi_sync_master_avg_trx_slave_lag_wait_time
the following variables are introduced on slave:
rpl_semi_sync_slave_lag_enabled (global)
in addition to this, 2 optimizations that decreases overhead of semi-sync
is introduced.
1) the idea of this is that if when a slave should send and transaction,
it checks if it should be semi-synced, but rather
than semi-sync:ing each transaction (which is done currently) the code
will skip semi-syncing transaction if there already is newer transactions
committed. But, since this can mean that semi-syncing is delayed indefinitely
a cap is set using 2 new master variables:
rpl_semi_sync_master_max_unacked_event_bytes (global)
rpl_semi_sync_master_max_unacked_event_count (global)
2) rpl_semi_sync_master_group_commit which makes the semi-sync
plugin only semi-sync the last transaction in a group commit.
diff --git a/mysql-test/suite/rpl/r/rpl_semi_sync_slave_lag.result
b/mysql-test/suite/rpl/r/rpl_semi_sync_slave_lag.result
new file mode 100644
index 000..f3545a4
--- /dev/null
+++ b/mysql-test/suite/rpl/r/rpl_semi_sync_slave_lag.result
@@ -0,0 +1,150 @@
+include/master-slave.inc
+[connection master]
+set global rpl_semi_sync_master_enabled = 1;
+set global rpl_semi_sync_master_max_slave_lag = 10;
+show variables like 'rpl_semi_sync_master_%slave_lag%';
+Variable_nameValue
+rpl_semi_sync_master_max_slave_lag 10
+rpl_semi_sync_master_slave_lag_heartbeat_frequency_us50
+rpl_semi_sync_master_slave_lag_wait_timeout 50
+include/stop_slave.inc
+set global rpl_semi_sync_slave_enabled = 1;
+set global rpl_semi_sync_slave_lag_enabled = 1;
+include/start_slave.inc
+# create non-root user for testing READ_ONLY
+grant SELECT, INSERT on *.* to test@localhost;
+CREATE TABLE t1 (i INT NOT NULL AUTO_INCREMENT PRIMARY KEY, f varchar(8))
+ENGINE=innodb;
+#
+# Check basic behaviour
+#
+INSERT INTO t1 (f) VALUES ('1'),('2'),('3');
+# Now wait for slave lag to decrease to 0
+# [ on slave ]
+STOP SLAVE SQL_THREAD;
+# [ on master ]
+INSERT INTO t1 (f) VALUES ('4'),('5'),('6');
+# Now wait for slave lag to increase to 0
+# [ on slave ]
+START SLAVE SQL_THREAD;
+# [ on master ]
+# Now wait for slave lag to decrease to 0
+# [ on slave ]
+STOP SLAVE SQL_THREAD;
+# [ on master ]
+set session rpl_semi_sync_master_slave_lag_wait_timeout = 5;
+# First transaction should succeed. slave_lag is zero when it commits
+INSERT INTO t1 (f) VALUES ('7'),('8'),('9');
+# Now wait for slave lag to increase to 10s
+# Check that estimated_slave_lag is 10s
+SELECT VARIABLE_VALUE 1000 as should_be_1
+FROM INFORMATION_SCHEMA.GLOBAL_STATUS
+WHERE VARIABLE_NAME = 'rpl_semi_sync_master_estimated_slave_lag';
+should_be_1
+1
+# Second transaction should now fail. slave_lag is 10s when it commits
+INSERT INTO t1 (f) VALUES ('a'),('b'),('c');
+ERROR HY000: Slave-lag timeout
+# [ on slave ]
+START SLAVE SQL_THREAD;
+# [ on master ]
+# Now wait for slave lag to
