Some questions about the excellent writing Tips on Converting to Galera.
Is "cross-colo writing" cross connect datacenters write?
Also, you should use "START TRANSACTION READONLY" wherever appropriate.
this means the transaction will be handled only by one node (no replication latency)?. Are there cases when a
START TRANSACTION READONLY involving more than one node?
SELECT marks it's a read?
(This section assumes you have Galera nodes in multiple colos.) Because of some of the issues discussed, it is wise to group your write statements into moderate sized BEGIN...COMMIT transactions. There is one latency hit per COMMIT or autocommit. So, combining statements will decrease those hits. On the other hand, it is unwise (for other reasons) to make huge transactions, such as inserting/modifying millions of rows in a single transaction.
Is this the max transaction size? Is it recommend to use close to max transaction size? Can you give a value what number you mean with moderate sized BEGIN...COMMIT transactions
MariaDB [(none)]> select @@wsrep_max_ws_size; +---------------------+ | @@wsrep_max_ws_size | +---------------------+ | 1073741824 | +---------------------+ 1 row in set (0.00 sec)
Here is a 'simple' (but not 'free') way to assure that a read-after-write, even from a different connection, will see the updated data.
when an app needs to use a read-after-write? What's the use case for read-after-write? But anyway then this read-after-write should be in the same transaction? Please a little more info about read-after-write and when to use it.
Variables that may need to be different (...) innodb_doublewrite - ON: When an IST occurs, want there to be no torn pages? (With FusionIO or other drives that guarantee atomicity, OFF is better.)
what are torn pages? I translated torn in my native language and now even more confused.
Miscellany (...) DROP USER may not replicate?
Any more details and infos? We use automated
DROP USER since a few years and never noticed issues. Did we just didn't saw the problems?