Branch: refs/heads/master
Home: https://github.com/mailru/tarantool
Commit: 7659b5676b2b83f7e4c8e9860b4a5703c18340bd
https://github.com/mailru/tarantool/commit/7659b5676b2b83f7e4c8e9860b4a5703c18340bd
Author: Konstantin Osipov <[email protected]>
Date: 2012-05-04 (Fri, 04 May 2012)
Changed paths:
M include/log_io.h
M src/log_io.m
Log Message:
-----------
Clean up recover().
recover() panics if things go wrong: don't
return any value from it (until we fix it to not panic).
In recover() current_wal is always NULL, since we run
it right after start (or after establishing a connection
with a replica). Don't check for current_wal.
Don't produce a stupid error message "can't find WAL
with LSN:" when recovering from a snapshot, and a snapshot
is all we have in the data directory.
We (ab)use recover() and recover_remaining_wals() in
replication and in initial recovery, without doing the
abstraction homework, and this leads to convoluted
code and redundant logic.
diff --git a/include/log_io.h b/include/log_io.h
index b3f27b2..7ff8f9e 100644
--- a/include/log_io.h
+++ b/include/log_io.h
@@ -180,7 +180,7 @@ void recovery_init(const char *snap_dirname, const char
*xlog_dirname,
void recovery_update_mode(const char *wal_mode, double fsync_delay);
void recovery_update_io_rate_limit(double new_limit);
void recovery_free();
-int recover(struct recovery_state *, i64 lsn);
+void recover(struct recovery_state *, i64 lsn);
void recovery_follow_local(struct recovery_state *r, ev_tstamp
wal_dir_rescan_delay);
void recovery_finalize(struct recovery_state *r);
int wal_write(struct recovery_state *r, u16 tag, u16 op,
diff --git a/src/log_io.m b/src/log_io.m
index e7bd3a8..9c84823 100644
--- a/src/log_io.m
+++ b/src/log_io.m
@@ -915,6 +915,12 @@
return i.error;
}
+/**
+ * Read a snapshot and call row_handler for every snapshot row.
+ *
+ * @retval 0 success
+ * @retval -1 failure
+ */
static int
recover_snap(struct recovery_state *r)
{
@@ -1127,7 +1133,7 @@
}
if (result == LOG_EOF) {
- say_info("done `%s' confirmed_lsn:%" PRIi64,
+ say_info("done `%s' confirmed_lsn: %" PRIi64,
r->current_wal->filename,
r->confirmed_lsn);
log_io_close(&r->current_wal);
@@ -1147,60 +1153,59 @@
return result;
}
-int
+void
recover(struct recovery_state *r, i64 lsn)
{
- int result = -1;
-
+ /* * current_wal isn't open during initial recover. */
+ assert(r->current_wal == NULL);
/*
- * if caller set confirmed_lsn to non zero value, snapshot recovery
- * will be skipped, but wal reading still happens
+ * If the caller sets confirmed_lsn to a non-zero value,
+ * snapshot recovery is skipped and we proceed directly to
+ * finding the WAL with the respective LSN and continue
+ * recovery from this WAL. @fixme: this is a gotcha, due
+ * to whihc a replica is unable to read data from a master
+ * if the replica has no snapshot or the master has no WAL
+ * with the requested LSN.
*/
-
say_info("recovery start");
if (lsn == 0) {
- result = recover_snap(r);
- if (result < 0) {
+ if (recover_snap(r) != 0) {
if (greatest_lsn(r->snap_class) <= 0) {
say_crit("didn't you forget to initialize
storage with --init-storage switch?");
_exit(1);
}
panic("snapshot recovery failed");
}
- say_info("snapshot recovered, confirmed lsn:%" PRIi64,
r->confirmed_lsn);
+ say_info("snapshot recovered, confirmed lsn: %"
+ PRIi64, r->confirmed_lsn);
} else {
/*
- * note, that recovery start with lsn _NEXT_ to confirmed one
+ * Note that recovery starts with lsn _NEXT_ to
+ * the confirmed one.
*/
r->lsn = r->confirmed_lsn = lsn - 1;
}
-
- /*
- * just after snapshot recovery current_wal isn't known
- * so find wal which contains record with next lsn
- */
- if (r->current_wal == NULL) {
- i64 next_lsn = r->confirmed_lsn + 1;
- i64 lsn = find_including_file(r->wal_class, next_lsn);
- if (lsn <= 0) {
- say_error("can't find WAL containing record with lsn:%"
PRIi64, next_lsn);
- result = -1;
- goto out;
- }
- r->current_wal = log_io_open_for_read(r, r->wal_class, lsn, 0,
NULL);
- if (r->current_wal == NULL) {
- result = -1;
- goto out;
+ i64 next_lsn = r->confirmed_lsn + 1;
+ i64 wal_lsn = find_including_file(r->wal_class, next_lsn);
+ if (wal_lsn <= 0) {
+ if (lsn != 0) {
+ /*
+ * Recovery for replication relay, did not
+ * find the requested LSN.
+ */
+ say_error("can't find WAL containing record with lsn:
%" PRIi64, next_lsn);
}
+ /* No WALs to recover from. */
+ goto out;
}
-
- result = recover_remaining_wals(r);
- if (result < 0)
+ r->current_wal = log_io_open_for_read(r, r->wal_class, wal_lsn, 0,
NULL);
+ if (r->current_wal == NULL)
+ goto out;
+ if (recover_remaining_wals(r) < 0)
panic("recover failed");
- say_info("wals recovered, confirmed lsn: %" PRIi64, r->confirmed_lsn);
- out:
+ say_info("WALs recovered, confirmed lsn: %" PRIi64, r->confirmed_lsn);
+out:
prelease(fiber->gc_pool);
- return result;
}
static void recovery_follow_file(ev_stat *w, int revents
__attribute__((unused)));
@@ -1231,7 +1236,7 @@
if (result < 0)
panic("recover failed");
if (result == LOG_EOF) {
- say_info("done `%s' confirmed_lsn:%" PRIi64,
+ say_info("done `%s' confirmed_lsn: %" PRIi64,
r->current_wal->filename,
r->confirmed_lsn);
log_io_close(&r->current_wal);
================================================================
Commit: 822a6981094f4ee21c5160b1d88dd20dc168449b
https://github.com/mailru/tarantool/commit/822a6981094f4ee21c5160b1d88dd20dc168449b
Author: Konstantin Osipov <[email protected]>
Date: 2012-05-04 (Fri, 04 May 2012)
Changed paths:
R debian/patches/libev-link-to-rt
R debian/patches/series
Log Message:
-----------
Merge branch 'master' of github.com:mailru/tarantool
diff --git a/debian/patches/libev-link-to-rt b/debian/patches/libev-link-to-rt
deleted file mode 100644
index fb07155..0000000
--- a/debian/patches/libev-link-to-rt
+++ /dev/null
@@ -1,11 +0,0 @@
---- tarantool-1.4.5+20120503.orig/src/CMakeLists.txt
-+++ tarantool-1.4.5+20120503/src/CMakeLists.txt
-@@ -32,7 +32,7 @@ endif()
- #
- # libev uses ceil and floor from the standard math library
- #
--target_link_libraries(ev m)
-+target_link_libraries(ev m rt)
-
- #
- # Build admin.m from admin.rl, but only if admin.rl was changed.
diff --git a/debian/patches/series b/debian/patches/series
deleted file mode 100644
index ad96ef6..0000000
--- a/debian/patches/series
+++ /dev/null
@@ -1 +0,0 @@
-libev-link-to-rt
================================================================
Compare: https://github.com/mailru/tarantool/compare/04a0dca...822a698
_______________________________________________
Mailing list: https://launchpad.net/~tarantool-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~tarantool-developers
More help : https://help.launchpad.net/ListHelp
