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: CHANGELOG.md
+5-1
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,9 @@
1
1
# UNRELEASED
2
2
3
+
IMPROVEMENETS
4
+
5
+
* Added a flag to skip legacy duplicate telemetry. [GH-630](https://github.com/hashicorp/raft/pull/630)
6
+
3
7
# 1.7.0 (June 5th, 2024)
4
8
5
9
CHANGES
@@ -37,7 +41,7 @@ CHANGES
37
41
38
42
go-msgpack v2.1.1 is by default binary compatible with v0.5.5 ("non-builtin" encoding of `time.Time`), but can decode messages produced by v1.1.5 as well ("builtin" encoding of `time.Time`).
39
43
40
-
However, if users of this libary overrode the version of go-msgpack (especially to v1), this **could break** compatibility if raft nodes are running a mix of versions.
44
+
However, if users of this library overrode the version of go-msgpack (especially to v1), this **could break** compatibility if raft nodes are running a mix of versions.
41
45
42
46
This compatibility can be configured at runtime in Raft using `NetworkTransportConfig.MsgpackUseNewTimeFormat` -- the default is `false`, which maintains compatibility with `go-msgpack` v0.5.5, but if set to `true`, will be compatible with `go-msgpack` v1.1.5.
In terms of performance, Raft is comparable to Paxos. Assuming stable leadership,
111
111
committing a log entry requires a single round trip to half of the cluster.
112
112
Thus performance is bound by disk I/O and network latency.
113
+
114
+
115
+
## Metrics Emission and Compatibility
116
+
117
+
This library can emit metrics using either `github.com/armon/go-metrics` or `github.com/hashicorp/go-metrics`. Choosing between the libraries is controlled via build tags.
118
+
119
+
**Build Tags**
120
+
*`armonmetrics` - Using this tag will cause metrics to be routed to `armon/go-metrics`
121
+
*`hashicorpmetrics` - Using this tag will cause all metrics to be routed to `hashicorp/go-metrics`
122
+
123
+
If no build tag is specified, the default behavior is to use `armon/go-metrics`.
124
+
125
+
**Deprecating `armon/go-metrics`**
126
+
127
+
Emitting metrics to `armon/go-metrics` is officially deprecated. Usage of `armon/go-metrics` will remain the default until mid-2025 with opt-in support continuing to the end of 2025.
128
+
129
+
**Migration**
130
+
To migrate an application currently using the older `armon/go-metrics` to instead use `hashicorp/go-metrics` the following should be done.
131
+
132
+
1. Upgrade libraries using `armon/go-metrics` to consume `hashicorp/go-metrics/compat` instead. This should involve only changing import statements. All repositories in the `hashicorp` namespace
133
+
2. Update an applications library dependencies to those that have the compatibility layer configured.
134
+
3. Update the application to use `hashicorp/go-metrics` for configuring metrics export instead of `armon/go-metrics`
135
+
* Replace all application imports of `github.com/armon/go-metrics` with `github.com/hashicorp/go-metrics`
136
+
* Instrument your build system to build with the `hashicorpmetrics` tag.
137
+
138
+
Eventually once the default behavior changes to use `hashicorp/go-metrics` by default (mid-2025), you can drop the `hashicorpmetrics` build tag.
// log 0..4 are committed after the leader receives
@@ -92,7 +92,7 @@ Therefore, it's possible that a very small window of time exists when all follow
92
92
committed the log to disk, the write has been realized in the FSM of the leader but the
93
93
followers have not yet applied the log to their FSM.
94
94
95
-
7. The peer applies the commited entries to the FSM.
95
+
7. The peer applies the committed entries to the FSM.
96
96
97
97
8. If all went well, the follower responds success (`resp.Success = true`) to the
98
98
`appendEntries` RPC call.
@@ -108,9 +108,9 @@ grouping the entries that can be applied to the fsm.
108
108
109
109
11.`processLogs` applies all the committed entries that haven't been applied by batching the log entries and forwarding them through the `fsmMutateCh` channel to fsm.
110
110
111
-
12. The actual place applying the commited log entries is in the main loop of `runFSM()`.
111
+
12. The actual place applying the committed log entries is in the main loop of `runFSM()`.
112
112
113
113
13. After the log entries that contains the client req are applied to the fsm, the fsm
114
-
module will set the reponses to the client request (`req.future.respond(nil)`). From the
114
+
module will set the responses to the client request (`req.future.respond(nil)`). From the
115
115
client's point of view, the future returned by `raft.Apply` should now be unblocked and
116
116
calls to `Error()` or `Response()` should return the data at this point.
v.errors=append(v.errors, fmt.Sprintf("Node %v sent an appendEnties request for term %d that said the leader was some other node %v", src, term, ldr))
61
+
v.errors=append(v.errors, fmt.Sprintf("Node %v sent an appendEntries request for term %d that said the leader was some other node %v", src, term, ldr))
0 commit comments