Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

expected features #11

Open
shlomi-noach opened this issue Apr 1, 2016 · 12 comments
Open

expected features #11

shlomi-noach opened this issue Apr 1, 2016 · 12 comments

Comments

@shlomi-noach
Copy link
Contributor

Throwing around all ideas, in no particular order, lest we forget.

@shlomi-noach
Copy link
Contributor Author

shlomi-noach commented Apr 1, 2016

  • prefer connecting to replica. Auto detect master
  • automatically converting binlog_format to row
    • unless server has replicas, in which case bail out
  • Catch Ctrl-C to restore settings
  • if binlog_row_image='minimal' the PK may not be changed
  • if PK is changed, will auto convert to binlog_row_image='full'
    • and restore settings upon exit
  • support --test-on-replica, which expects host to be a replica, and converts the table on the replica. This is for experimental alters for gaining trust in the tool. Once the table is altered, no switch take place. The replica can be stopped and the two tables (original & ghost) can be compared and verifies to be identical.
  • accept list of replicas as control servers
  • accept max allowed lag as throttling threshold
  • accept --max-load
  • respect pause-file. When this file exists, the tool pauses
  • respect a terminate-file. When this file is brought to existence, the tool quits in orderly fashion
  • accept --auto-suggest-credentials: the tool generates a GRANT statement with new credentials and a random password, and asks the user to create these credentials, then polls until it is satisfied it can connect with these credentials
  • verify privileges are sufficient via SHOW GRANTS FOR CURRENT_USER()

@shlomi-noach
Copy link
Contributor Author

  • support --exact-rowcount which actually issues SELECT COUNT(*) FROM original_table instead of estimating number of rows in table. This should only be allowed on the replica.

@shlomi-noach
Copy link
Contributor Author

shlomi-noach commented Apr 4, 2016

  • dynamic changing of parameters, such as chunk-size or max-load. This is an essential operational feature.

@shlomi-noach
Copy link
Contributor Author

  • verify no foreign keys exist on table (neither "parent" nor "child")

@shlomi-noach
Copy link
Contributor Author

shlomi-noach commented Apr 4, 2016

  • a --noop flag, or rather the contrary, noop by default and a --execute to actually make things happen (similarly to existing pt-osc)

@jonahberquist
Copy link
Contributor

  • estimates for completion time based on how close the copy job gets to current value of auto-increment

@shlomi-noach
Copy link
Contributor Author

  • multiple max-load conditions. We may wish to throttle on threads_running AND on thread_connected AND on something else...

@shlomi-noach
Copy link
Contributor Author

shlomi-noach commented Apr 6, 2016

  • handle ROLLBACK events in binary log (I think this would be irrelevant on replicas, but relevant on master)

@shlomi-noach
Copy link
Contributor Author

shlomi-noach commented Apr 14, 2016

  • support RENAME COLUMN

@shlomi-noach
Copy link
Contributor Author

  • phase 2: optionally (via config) do not INSERT INTO...SELECT on the master. Read the rows from replica via app, write them onto master. This removes the last coupling of OSC with the master. It removes the last concurrency consideration on the master.

@dozer47528
Copy link

  • support data migrate model (data migrate is similar with the alter table process)

@shlomi-noach
Copy link
Contributor Author

@dozer47528 Sorry, not following; how do you mean "support data migrate model"?

  • Do you wish for gh-ost to issue a large scale UPDATE for you, using chunking and throttling?

Also, please open a new Issue for a new feature request. This Issue was created in the very early days of gh-ost to lay out the general plan.

@github github locked and limited conversation to collaborators Aug 18, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants