Thanks for the feedback! re #5, agree that it is a design flaw and we intend to fix it.

Moreover, now I see it is impossible to start MySQL with only gtid_mode=ON, whereus in my previous test it was possible to do so, and error was only reported on CHANGE MASTER TO.
This is also an improvement and avoids confusion.

7 – thank you for the clarifications. So “–enforce-gtid-consistency” stands on its own, so as to validate that my application confirms to possible GTID use; then, when I’m convinced, I turn GTID on — did I get it right? That makes sense.

8 – Now in the error log I do get:
121121 13:00:41 [ERROR] –gtid-mode=ON or UPGRADE_STEP_1 requires –disable-gtid-unsafe-statements

Which is indeed a clear message. I must have missed the update!

7. –enforce-gtid-consistency (earlier called –disable-gtid-unsafe-statements) prevents execution of statements that are
incompatible with GTIDs. –gtid-mode=ON turns on GTIDs. We made two different options, so that you can first check that your application is compatible with GTIDs, and then in a second step you can turn on GTIDs. It is impossible to set –gtid-mode=ON without –enforce-gtid-consistency.

8. We double-checked this and we do generate the correct error messages. Did you by any chance use –gtid-mode=1 instead of ON? That would explain the message. Please note that gtid-mode is an enumeration with four values, not a boolean, so 1 and ON are not the same. It was wrongly documented as boolean in an early version of the documentation and this has now been fixed.

Regarding:

“Why the inconsistency of putting ALGORITHM=…, LOCK=… in between
commas, as opposed to other flags/commands not between commas? For example:
ALTER TABLE my_table ADD COLUMN i INT, ALGORITHM=COPY, LOCK=SHARED,
ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4”

Clauses in ALTER TABLE are normally separated by comma (‘,’). For
example, as in “ALTER TABLE t1 ADD COLUMN i INT, ALGORITHM=INPLACE”.

What can be confusing here is that clause that allows to set new options for
table can lookslike “ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4”.
I.e. that we allow use of spaces for separator between options.

From the view point of ALTER TABLE syntax this is a single clause, which
consists of several subclauses and which is separated from other clauses,
like ADD COLUMN…, ALGORITHM=… and LOCK=…, using commas.

In short, ALGORITHM and LOCK are not similar to table options like ENGINE, but more like ADD COLUMN, ADD KEY clauses.

Regards,
Dmitry

For question #1: yes, I now see the comment in the blog post. Good!

For question #2, the documentation has indeed improved. I am still unclear about all combinations (such as: ALGORITHM=COPY –> does that mean LOCK=NONE can’t be used? It only says “if supported”. Suppurted by what?)

For #6, I will, but this looks like a long shot.

Cheers

Thanks,
3. No, there are no examples of online DDL in said page; I have already browsed that page.
There is not a single ALGORITHM= or LOCK= statement. All there is is a setup for “old_alter_table”.

But it makes FTWRL slower, potentially a lot slower. Flushing say 40,000 changed pages unnecessarily will hurt some users.

That difference means is that there’s likely to be a bug report requesting that we do pay attention to the difference between the two needs. Might even be me who files it, either before or after someone says it’s a problem for them.

All of this might be more than you really wanted to know about the differences and why they can matter. 🙂

James Day