You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/command-line-flags.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -125,6 +125,12 @@ Why is this behavior configurable? Different workloads have different characteri
125
125
126
126
Noteworthy is that setting `--dml-batch-size` to higher value _does not_ mean `gh-ost` blocks or waits on writes. The batch size is an upper limit on transaction size, not a minimal one. If `gh-ost` doesn't have "enough" events in the pipe, it does not wait on the binary log, it just writes what it already has. This conveniently suggests that if write load is light enough for `gh-ost` to only see a few events in the binary log at a given time, then it is also light enough for `gh-ost` to apply a fraction of the batch size.
127
127
128
+
129
+
### ignore-over-iteration-range-max-binlog
130
+
131
+
Defaults to false. When binlog unique key value is over `MigrationIterationRangeMaxValues`, and less than `MigrationRangeMaxValues`, the binlog will be ignored. Because the data will be synced by copy chunk. When binlog unique key value is over `MigrationRangeMaxValues` or less than `MigrationIterationRangeMaxValues`, the binlog will be applied. Currently when enabled, this only takes effect for single-column unique index of int type.
132
+
133
+
128
134
### exact-rowcount
129
135
130
136
A `gh-ost` execution need to copy whatever rows you have in your existing table onto the ghost table. This can and often will be, a large number. Exactly what that number is?
Copy file name to clipboardExpand all lines: go/cmd/gh-ost/main.go
+1Lines changed: 1 addition & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -109,6 +109,7 @@ func main() {
109
109
defaultRetries:=flag.Int64("default-retries", 60, "Default number of retries for various operations before panicking")
110
110
cutOverLockTimeoutSeconds:=flag.Int64("cut-over-lock-timeout-seconds", 3, "Max number of seconds to hold locks on tables while attempting to cut-over (retry attempted when lock exceeds timeout) or attempting instant DDL")
111
111
niceRatio:=flag.Float64("nice-ratio", 0, "force being 'nice', imply sleep time per chunk time; range: [0.0..100.0]. Example values: 0 is aggressive. 1: for every 1ms spent copying rows, sleep additional 1ms (effectively doubling runtime); 0.7: for every 10ms spend in a rowcopy chunk, spend 7ms sleeping immediately after")
112
+
flag.BoolVar(&migrationContext.IgnoreOverIterationRangeMaxBinlog, "ignore-over-iteration-range-max-binlog", false, "When binlog unique key value is over MigrationIterationRangeMaxValues, and less than MigrationRangeMaxValues, the binlog will be ignored. Because the data will be synced by copy chunk")
112
113
113
114
maxLagMillis:=flag.Int64("max-lag-millis", 1500, "replication lag at which to throttle operation")
114
115
replicationLagQuery:=flag.String("replication-lag-query", "", "Deprecated. gh-ost uses an internal, subsecond resolution query")
// Compare whether it is less than the MigrationIterationRangeMaxValues boundary value. If it is, it cannot be ignored and the corresponding binlog needs to be applied.
// Since rowcopy is left-open-right-closed, when it is equal to the MigrationIterationRangeMaxValues boundary value, it cannot be ignored.
1262
+
returnfalse, nil
1263
+
}
1264
+
}()
1265
+
iferr!=nil {
1266
+
returnfalse, err
1267
+
}
1268
+
1269
+
if!ignore {
1270
+
returnfalse, nil
1271
+
}
1272
+
1273
+
// Compare whether it is greater than the MigrationRangeMaxValues boundary value. If it is, it cannot be ignored and the corresponding binlog needs to be applied.
0 commit comments