Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
Description
Desc:- This will split Alter into 2 different commits. START ALTER and COMMIT
/ROLLBACK ALTER , Start Alter will be written in binlog as soon as we get the
locks for the table, alter will proceeds as usual and at the time of writing
binlog if alter is successful we will write COMMIT Alter other wise ROLLBACK
Alter.
Implementation details are in develop list
https://lists.launchpad.net/maria-developers/msg12067.html
Attachments
Issue Links
- causes
-
MDEV-33057 alter table form s3 to different engine on leader break replicas with binlog_alter_two_phase;
-
- Open
-
-
MDEV-35431
my_snprintf fixes for 10.11+
-
- Closed
-
-
-
- In Review
-
-
-
- Closed
-
- is blocked by
-
-
- Closed
-
- is part of
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
MDEV-7502 Automatic provisioning of slave
-
- Open
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
Currently no true LOCK=NONE exists on slave.
Alter table is first committed on master then it is replicated on slaves. The purpose of this task is to create a true LOCK=NONE |
Currently no true LOCK=NONE exists on slave.
Alter table is first committed on master then it is replicated on slaves. The purpose of this task is to create a true LOCK=NONE Implementation Idea Master will write BEGIN_DDL_EVENT in binlog after it hits ha_prepare_inplace_alter_table. Then master will write QUERY_EVENT on binlog with actual alter query . On commit/rollback master will write COMMIT_DDL_EVENT/ROLLBACK_DDL_EVENT. On slave there will be pool of threads(configurable global variable), which will apply these DDLs. On reciving BEGIN_DDL_EVENT slave thread will pass the QUERY_EVENT to one of the worker thread. Worker thread will execute untill ha_inplace_alter_table. Actual commit_inplace_alter will be called by sql thread. If sql thread recieve some kind of rollback event , then it will somehow signal worker thread to stop executing alter. If none of the worker threads are avaliable then event will be enqueued, then If we recieved rollback event the we will simply discard event from queue, If we recieved commit event then SQL thread will syncrolysly process DDL event. |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Summary | True LOCK=NONE on slave. | True ALTER LOCK=NONE on slave. |
| Fix Version/s | 10.3 [ 22126 ] | |
| Fix Version/s | 10.2 [ 14601 ] |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
| Labels | gsoc18 |
| Description |
Currently no true LOCK=NONE exists on slave.
Alter table is first committed on master then it is replicated on slaves. The purpose of this task is to create a true LOCK=NONE Implementation Idea Master will write BEGIN_DDL_EVENT in binlog after it hits ha_prepare_inplace_alter_table. Then master will write QUERY_EVENT on binlog with actual alter query . On commit/rollback master will write COMMIT_DDL_EVENT/ROLLBACK_DDL_EVENT. On slave there will be pool of threads(configurable global variable), which will apply these DDLs. On reciving BEGIN_DDL_EVENT slave thread will pass the QUERY_EVENT to one of the worker thread. Worker thread will execute untill ha_inplace_alter_table. Actual commit_inplace_alter will be called by sql thread. If sql thread recieve some kind of rollback event , then it will somehow signal worker thread to stop executing alter. If none of the worker threads are avaliable then event will be enqueued, then If we recieved rollback event the we will simply discard event from queue, If we recieved commit event then SQL thread will syncrolysly process DDL event. |
Currently no true LOCK=NONE exists on slave.
Alter table is first committed on master then it is replicated on slaves. The purpose of this task is to create a true LOCK=NONE *Implementation Idea* Master will write BEGIN_DDL_EVENT in binlog after it hits ha_prepare_inplace_alter_table. Then master will write QUERY_EVENT on binlog with actual alter query . On commit/rollback master will write COMMIT_DDL_EVENT/ROLLBACK_DDL_EVENT. On slave there will be pool of threads(configurable global variable), which will apply these DDLs. On reciving BEGIN_DDL_EVENT slave thread will pass the QUERY_EVENT to one of the worker thread. Worker thread will execute untill ha_inplace_alter_table. Actual commit_inplace_alter will be called by sql thread. If sql thread recieve some kind of rollback event , then it will somehow signal worker thread to stop executing alter. If none of the worker threads are avaliable then event will be enqueued, then If we recieved rollback event the we will simply discard event from queue, If we recieved commit event then SQL thread will syncrolysly process DDL event. |
| Summary | True ALTER LOCK=NONE on slave. | True ALTER LOCK=NONE on slave |
| Fix Version/s | 10.3 [ 22126 ] |
| Fix Version/s | 10.4 [ 22408 ] |
| Epic Link | PT-76 [ 68557 ] |
| Link |
This issue relates to |
| Link |
This issue relates to |
Note MDEV-7974 is actually to provide an infrastructure to replicate the prepare and commit parts of an object not being limited to XA trx.
Specifically crash-safety (recovery) property of the prepare part are common.
| Labels | gsoc18 | gsoc18 gsoc19 |
| Fix Version/s | 10.5 [ 23123 ] |
| NRE Projects | RM_104_others RM_105_CANDIDATE | RM_105_CANDIDATE |
| Fix Version/s | 10.4 [ 22408 ] |
| Epic Link | PT-76 [ 68557 ] |
Hi ralf.gebhardt@mariadb.com
There is no update , because we there was no proposal for this project .
| Link |
This issue relates to |
sachin.setiya.007 I only asked because there are the gsoc labels. I guess that they can be removed, no?
| Labels | gsoc18 gsoc19 |
| Labels | gsoc18 gsoc19 |
No-no, they should not be removed. They mean that the task was offered for GSoC 2018 and GSoC 2019.
It's a historical fact, that it was, so the labels should be there, indicating that fact.
| Link | This issue relates to MDEV-16281 [ MDEV-16281 ] |
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Summary | True ALTER LOCK=NONE on slave | Lag Free Alter On Slave |
| Description |
Currently no true LOCK=NONE exists on slave.
Alter table is first committed on master then it is replicated on slaves. The purpose of this task is to create a true LOCK=NONE *Implementation Idea* Master will write BEGIN_DDL_EVENT in binlog after it hits ha_prepare_inplace_alter_table. Then master will write QUERY_EVENT on binlog with actual alter query . On commit/rollback master will write COMMIT_DDL_EVENT/ROLLBACK_DDL_EVENT. On slave there will be pool of threads(configurable global variable), which will apply these DDLs. On reciving BEGIN_DDL_EVENT slave thread will pass the QUERY_EVENT to one of the worker thread. Worker thread will execute untill ha_inplace_alter_table. Actual commit_inplace_alter will be called by sql thread. If sql thread recieve some kind of rollback event , then it will somehow signal worker thread to stop executing alter. If none of the worker threads are avaliable then event will be enqueued, then If we recieved rollback event the we will simply discard event from queue, If we recieved commit event then SQL thread will syncrolysly process DDL event. |
Desc:- This will split Alter into 2 different commits. START ALTER and COMMIT
/ROLLBACK ALTER , Start Alter will be written in binlog as soon as we get the locks for the table, alter will proceeds as usual and at the time of writing binlog if alter is successful we will write COMMIT Alter other wise ROLLBACK Alter. Implementation details are in develop list https://lists.launchpad.net/maria-developers/msg12067.html |
So currently I am working on issue , when we write START ALTER gtid_slave_pos table is not updated, Which is normal because thread is hanging/waiting in
mysql_alter_table , So we cant call do_update_pos (we are still inside QUery_log_event::do_apply_event)
So I am thinking of calling ::stmt_done inside mysql_alter_table(after writing START ALTER into binlog), I have stored the log_pos in thd (debatable )
So the issue which I am facing is , we call lock_tables in mysql_alter_table (normal table , which we want to change), and after that writing START ALTER into binlog we will write into gtid_slave_pos , but when ::stmt_done calls lock_tables its assert is failing because thd->lock is not NULL
So I am thinking of something like lock gtid_slave_pos when I acquire lock for normal table and release the lock when it is updated , NOt sure if it is possible
| Link |
This issue includes |
| Link |
This issue relates to |
| Link |
This issue includes |
| Link | This issue relates to MDEV-21783 [ MDEV-21783 ] |
| Assignee | Sachin Setiya [ sachin.setiya.007 ] | Andrei Elkin [ elkin ] |
| Status | Stalled [ 10000 ] | In Review [ 10002 ] |
| Fix Version/s | 10.6 [ 24028 ] | |
| Fix Version/s | 10.5 [ 23123 ] |
| Priority | Critical [ 2 ] | Major [ 3 ] |
| Assignee | Andrei Elkin [ elkin ] | Sachin Setiya [ sachin.setiya.007 ] |
| Link | This issue relates to MENT-662 [ MENT-662 ] |
| Comment | [ A comment with security level 'Developers' was removed. ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Status | Stalled [ 10000 ] | Open [ 1 ] |
| Status | Open [ 1 ] | Confirmed [ 10101 ] |
| Link |
This issue relates to |
| Link |
This issue relates to |
| Link |
This issue relates to |
| Link |
This issue relates to |
| Link |
This issue relates to |
| Fix Version/s | 10.6 [ 24028 ] |
| Fix Version/s | 10.7 [ 24805 ] |
| Priority | Critical [ 2 ] | Major [ 3 ] |
| Assignee | Sachin Setiya [ sachin.setiya.007 ] | Andrei Elkin [ elkin ] |
| Fix Version/s | 10.8 [ 26121 ] | |
| Fix Version/s | 10.7 [ 24805 ] |
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Status | Confirmed [ 10101 ] | In Progress [ 3 ] |
| Workflow | MariaDB v3 [ 79004 ] | MariaDB v4 [ 131819 ] |
The about to be created preview branch misses out FTWRL fixes that we've discussed today
and it's just too late night for me to complete with them into the branch.
This will be done tomorrow.
| Assignee | Andrei Elkin [ elkin ] | Brandon Nesterenko [ JIRAUSER48702 ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
I approve the current patch c592a5e. Note that it will still need the FTWRL fixes.
| Assignee | Brandon Nesterenko [ JIRAUSER48702 ] | Andrei Elkin [ elkin ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| Status | Stalled [ 10000 ] | In Testing [ 10301 ] |
| Assignee | Andrei Elkin [ elkin ] | Sergei Golubchik [ serg ] |
| Assignee | Sergei Golubchik [ serg ] | Alice Sherepa [ alice ] |
Confirmed Andrei's approval on my behalf, I had to step away momentarily
| Link |
This issue relates to |
| Link |
This issue relates to |
| Link |
This issue relates to |
| Link |
This issue is blocked by |
| Link |
This issue is part of |
| Link |
This issue relates to |
| Status | In Testing [ 10301 ] | Stalled [ 10000 ] |
| Assignee | Alice Sherepa [ alice ] | Andrei Elkin [ elkin ] |
| Fix Version/s | 10.8.1 [ 26815 ] | |
| Fix Version/s | 10.8 [ 26121 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Labels | gsoc18 gsoc19 | Preview_10.8 gsoc18 gsoc19 |
| Remote Link | This issue links to "Page (MariaDB Confluence)" [ 36217 ] |
| Link | This issue causes MDEV-33057 [ MDEV-33057 ] |
| Remote Link | This issue links to "Page (MariaDB Confluence)" [ 36675 ] |
| Remote Link | This issue links to "Page (MariaDB Confluence)" [ 36748 ] |
| Remote Link | This issue links to "Page (MariaDB Confluence)" [ 36748 ] |
| Remote Link | This issue links to "Page (MariaDB Confluence)" [ 36795 ] |
| Link |
This issue causes |
| Link | This issue relates to MDEV-35474 [ MDEV-35474 ] |
| Link | This issue causes MDEV-35474 [ MDEV-35474 ] |
| Link | This issue relates to MDEV-35474 [ MDEV-35474 ] |
| Link |
This issue causes |
A variation of the same idea is in
MDEV-16223, for initiating ADD INDEX in the background.This solution would be preferred instead of that one (
MDEV-16223).