All,
Thanks for your replies and as per the advise I switched to row-based
replication but replication ended with below error.
*Last_Error: Error 'Table 'b.sdefrent' doesn't exist' on query. Default
database: 'b. Query: 'drop table sdefrent'*
above error is due to non existence of database
**On master server I have two databases *A and B*. App team use database B
temporarily for there application to compute calculation and insert the
values on A database.
For certain statements you could start with SET SQL_BIN_LOG=0 so it
doesn't log that statement, and it won't be replicated.
I have setup mysql replication with below scenario
**On master server I have two databases *A and B*. App team use database B
temporarily for there application to compute calculation and insert the
values on A database.
**On Slave Server I replicate database *A alone* and my replication not
On Thu, Jan 27, 2011 at 10:40 AM, Nagaraj S nagaraj@gmail.com wrote:
**On Slave Server I replicate database *A alone* and my replication not
working due to data fetching happen on B database.
Well, yes. Statement-based replication does what it says on the box: it
executes the exact same
I am having problems setting up replication between two 4.0.10
servers.
What I did so far:
- generate a dump of the current state of the server using
'mysqldump' (its a mix of mostly innodb tables and some MyISAM
tables)
- dropped all databases from the slave
- imported the dump into
On Thursday 13 February 2003 16:43, Johannes Ullrich wrote:
I am having problems setting up replication between two 4.0.10
servers.
What I did so far:
- generate a dump of the current state of the server using
'mysqldump' (its a mix of mostly innodb tables and some MyISAM
tables)
-
Check the user 'repl' has REPLICATION SLAVE privilege.
Ah. that fixed it. Actually, the real reason was that I had not
yet updated the mysql tables and the new privileges did not take
effect as a result.
mysql_fix_privilege_tables , followed by the 'GRANT' command
and 'flush privileges' fixed
