Docs/manual.texi

    replication updates
sql/opt_range.h
    fixed compiler warning
sql/slave.cc
    fixed handling of long usernames
    fixed insert_id + query log event processing atomicity in the case
    of slave death
    fix edcharset coversion to not be global to all threads
sql/sql_class.h
    fix to make insert_id event and the subsequent query event be still processed
    atomically if slave dies in the middle
sql/sql_select.cc
    temp fix to make it compile 
repl-tests/test-auto-inc/run.test@1.1
    New BitKeeper file ``repl-tests/test-auto-inc/run.test''
repl-tests/test-auto-inc/x.master@1.1
    New BitKeeper file ``repl-tests/test-auto-inc/x.master''
parent 1e562819
......@@ -24590,6 +24590,16 @@ master-password=<replication user password>
replacting the values in <> with what is relevant to your system.
Starting in version 3.23.26, you must also have on both master and
slave
@example
server-id=<some unique number between 1 and 2^32-1>
@end example
@code{server-id} must be different for each server participating in
replication
@item Restart the slave(s)
@end itemize
......@@ -24616,6 +24626,13 @@ propogation. @code{LOAD LOCAL DATA INFILE} will be skipped.
@item
Update queries that use user variables are not replication-safe (yet)
@item
Starting in 3.23.26, it is safe to connect servers in a circular
master-slave relationship with @code{log-slave-updates} enabled.
Note, however, that many queries will not work right in this kind of
setup unless your client code is written to take care of the potential
problems that can happen from updates that occur in different sequence
on different servers
@item
If the query on the slave gets an error, the slave thread will
terminate, and a message will appear in @code{.err} file. You should
then connect to the slave manually, fix the cause of the error
......@@ -24649,13 +24666,6 @@ replication (binary) logging on the master, and @code{SET SQL_LOG_BIN =
1} will turn in back on - you must have the process privilege to do
this.
@item
The slave thread does not log updates to the binary log of the slave,
so it is possible to couple two servers in a mutual master-slave
relationship. You can actually set up a load balancing scheme and do
queries safely on either of the servers. Just do not expect to do LOCK
TABLES on one server, then connect to the other and still have that
lock :-) .
@item
Starting in 3.23.19 you can clean up stale replication leftovers when
something goes wrong and you want a clean start with @code{FLUSH MASTER}
and @code{FLUSH SLAVE} commands
......@@ -24668,6 +24678,10 @@ TO }
@item
Starting in 3.23.23, you tell the master that updates in certain
databases should not be logged to the binary log with @code{binlog-ignore-db}
@item
Starting in 3.23.26, you can use @code{replicate-rewrite-db} to tell
the slave to apply updates from one database on the master to the one
with a different name on the slave
@end itemize
@node Replication Options, Replication SQL, Replication Features, Replication
......@@ -24783,6 +24797,22 @@ exclude all others not explicitly mentioned.
to the binary log
(Set on @strong{Master}, Example: @code{binlog-ignore-db=some_database})
@item
@code{replicate-rewrite-db}
@tab Tells the slave to apply updates to a database with a different
name than the original ( Set on @strong{Slave}, Example:
@code{replicate-rewrite-db=master_db_name->slave_db_name}
@item
@code{skip-slave-start}
@tab Tells the slave server not to start the slave on the startup.
The user can start it later with @code{SLAVE START}
@item
@code{server-id}
@tab Sets the unique replicaiton numeric server id. You should pick one to assign.
The range is from 1 to 2^32-1. (Set on both @strong{Master} and
@strong{Slave}. Example: @code{server-id=3})
@end multitable
@cindex SQL commands, replication
......@@ -24888,9 +24918,26 @@ it up from @code{pthread_cond_wait()}. In the meantime, the slave
could have opened another connection, which resulted in another
@code{Binlog_Dump} thread.
Once we add @strong{server_id} variable for each server that
participates in replication, we will fix @code{Binlog_Dump} thread to
kill all the zombies from the same slave on reconnect.
The above problem should not be present in 3.23.26 and later versions.
In 3.23.26 we added @code{server-id} to each replication server, and
now all the old zombie threads are killed on the master when a new replication thread
connects from the same slave
@strong{Q}: How do I upgrade on a hot replication setup?
@strong{A}: If you are upgrading pre-3.23.26 versions, you should just
lock the master tables, let the slave catch up, then run @code{FLUSH
MASTER} on the master, and @code{FLUSH SLAVE} on the slave to reset the
logs, then restart new versions of the master and the slave. Note that
the slave can stay down for some time - since the master is logging
all the updates, the slave will be able to catch up once it is up and
can connect.
We plan to make post 3.23.26 versions to be backwards compatible
for replication down to 3.23.26, so upgrade should be just a matter
of plug and play. Of course, as one joke goes, plug and play works
usually only 50% of the time - just the plug part. We hope to do much
better than that, though.
@cindex replication, two-way
@strong{Q}: What issues should I be aware of when setting up two-way
......@@ -37858,6 +37905,26 @@ though, so 3.23 is not released as a stable version yet.
@appendixsubsec Changes in release 3.23.26
@itemize @bullet
@item
Fixed mutex bug in the binary replication log - long update queries could
be read only in part by the slave if it did it at the wrong time, which
was not fatal, but resulted in a performance-degrading reconnect and
a scary message in the error log
@item
Changed the format of the binary log - added magic number, server
version, binlog version. Added server id and query error code for each query event
@item
Replication thread from the slave will now kill all the stale threads
from the same server
@item
Long replication user names were not being handled properly
@item
Added --replicate-rewrite-db
@item
Added --skip-slave-start
@item
Updates that generated an error code ( such as INSERT INTO foo(some_key)
values (1),(1);) erroneously terminated the slave thread
@item
Added optimization of queries where @code{DISTINCT} is only used on columns
from some of the tables.
@item
source ../include/master-slave.inc;
connection master;
drop table if exists x;
create table x(n int auto_increment primary key);
set insert_id = 2000;
insert into x values (NULL),(NULL),(NULL);
connection slave;
sleep 3;
@x.master select * from x;
......@@ -71,7 +71,7 @@ public:
double read_time;
QUICK_SELECT(TABLE *table,uint index_arg,bool no_alloc=0);
~QUICK_SELECT();
virtual ~QUICK_SELECT(); // fixed by Sasha needs to be virtual
void reset(void) { next=0; it.rewind(); }
virtual int init() { return 0; }
virtual int get_next();
......
......@@ -126,7 +126,12 @@ static void init_strvar_from_file(char* var, int max_size, FILE* f,
if(fgets(var, max_size, f))
{
*(strend(var)-1) = 0;
char* last_p = strend(var) - 1;
if(*last_p == '\n') *last_p = 0; // if we stopped on newline, kill it
else
while( (fgetc(f) != '\n' && !feof(f)));
// if we truncated a line or stopped on last char, remove all chars
// up to and including newline
}
else if(default_val)
strmake(var, default_val, max_size);
......@@ -302,11 +307,11 @@ int init_master_info(MASTER_INFO* mi)
mi->file = file;
if(master_host)
strmake(mi->host, master_host, sizeof(mi->host));
strmake(mi->host, master_host, sizeof(mi->host) - 1);
if(master_user)
strmake(mi->user, master_user, sizeof(mi->user));
strmake(mi->user, master_user, sizeof(mi->user) - 1);
if(master_password)
strmake(mi->password, master_password, sizeof(mi->password));
strmake(mi->password, master_password, sizeof(mi->password) - 1);
mi->port = master_port;
mi->connect_retry = master_connect_retry;
......@@ -635,6 +640,8 @@ static int exec_event(THD* thd, NET* net, MASTER_INFO* mi, int event_len)
}
thd->db = 0;// prevent db from being freed
thd->query = 0; // just to be sure
thd->convert_set = 0; // assume no convert for next query
// unless set explictly
close_thread_tables(thd);
free_root(&thd->mem_root,0);
if (thd->query_error)
......@@ -801,8 +808,7 @@ static int exec_event(THD* thd, NET* net, MASTER_INFO* mi, int event_len)
break;
}
mi->inc_pos(event_len);
flush_master_info(mi);
mi->inc_pending(event_len);
break;
}
}
......
......@@ -45,7 +45,7 @@ typedef struct st_log_info
typedef struct st_master_info
{
char log_file_name[FN_REFLEN];
ulonglong pos;
ulonglong pos,pending;
FILE* file; // we keep the file open, so we need to remember the file pointer
// the variables below are needed because we can change masters on the fly
......@@ -57,11 +57,18 @@ typedef struct st_master_info
pthread_mutex_t lock;
bool inited;
st_master_info():inited(0) { host[0] = 0; user[0] = 0; password[0] = 0;}
st_master_info():inited(0),pending(0)
{ host[0] = 0; user[0] = 0; password[0] = 0;}
inline void inc_pending(ulonglong val)
{
pending += val;
}
inline void inc_pos(ulonglong val)
{
pthread_mutex_lock(&lock);
pos += val;
pos += val + pending;
pending = 0;
pthread_mutex_unlock(&lock);
}
// thread safe read of position - not needed if we are in the slave thread,
......
......@@ -23,7 +23,11 @@
#include "mysql_priv.h"
#include "sql_select.h"
#include "opt_ft.h"
#if 0 // Sergei - remove when fixed
#include "opt_ft.h"
#endif
#include <m_ctype.h>
#include <hash.h>
#include <ft_global.h>
......@@ -5045,6 +5049,11 @@ test_if_skip_sort_order(JOIN_TAB *tab,ORDER *order,ha_rows select_limit)
DBUG_RETURN(0); // Can't use index.
}
// Sergei - remove this one when you have added opt_ft stuff
QUICK_SELECT *get_ft_or_quick_select_for_ref(TABLE *table, JOIN_TAB *tab)
{
return get_quick_select_for_ref(table, &tab->ref);
}
static int
create_sort_index(JOIN_TAB *tab,ORDER *order,ha_rows select_limit)
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment