Closed GoogleCodeExporter closed 9 years ago
Please check the post on groups - there's alot of information about the setup,
and troubleshooting:
Posted on groups:
http://groups.google.com/group/tungsten-replicator-discuss/browse_thread/thread/
5093c18784ac728d
Original comment by whitecol...@gmail.com
on 16 Jun 2011 at 4:31
Since your user has the right privileges, there is something fishy in
this problem.
Let's see if we can pin it down.
I would check the following:
* make sure that there is no user 'testuser' on test2 that was created
with different parameters than the ones defined on the master. Please
check the mysql.user table. (this would still be a bgu, but a
different one).
* make sure that user 'tungsten_user' can really create users on host2
* If the above confirms that no user has been created and
tungsten_user on host2 can indeed create users, we need to track down
the changes.
** make sure that the GRANT statement was logged to the binary log
** make sure that the GRANT statement was logged in the master THL
host1 $ ./tungsten-replicator/bin/thl -service master_t1 list |
grep -i grant
** make sure that the same statement has been logged to the slave THL
host2 $ ./tungsten-replicator/bin/thl -service master_t1 list |
grep -i grant
Please also provide the full version for both Tungsten and MySQL servers.
This looks like a bug, and I would like to understand how it happens.
Thanks for your feedback!
Giuseppe
Original comment by g.maxia
on 16 Jun 2011 at 5:39
Have checked everything you mentioned:
- There is no user 'testuser' on host2.
- tungsten_user can create users on host2.
- GRANT statement was loggeed to binary log:
| mysqld_log.000008 | 633 | Query | 1 | 751 | grant all
on *.* to testuser@'%' identified by 'test'
- GRANT statement was logged on master (host1) THL:
- SQL(0) = grant all on *.* to testuser@'%' identified by 'test' /*
___SERVICE___ = [master_t1] */
- GRANT statement was logged on slave (host2) THL:
- SQL(0) = grant all on *.* to testuser@'%' identified by 'test' /*
___SERVICE___ = [master_t1] */
Tungsten version 2.0.3
MySQL-server version 5.5.13
Original comment by whitecol...@gmail.com
on 16 Jun 2011 at 8:39
Thanks.
This is definitely a bug.
We need to find what is the root cause.
As I can't reproduce it, I have to ask you for more information.
If your THL is not to big (if it is, you should repeat the steps with just the
relevant queries), please export it to text using the thl utility:
thl -service master_t1 list > thl_out.txt
Then add the replicator logs (tungsten-replicator/log/*.log), the replicator
configuration file (tungsten-replicator/conf/*.properties), and the MySQL
my.cnf, all in a zip file, and attach it to this issue.
Original comment by g.maxia
on 16 Jun 2011 at 9:10
[deleted comment]
Resolved: Instead of doing ./configure and ./configure-services, followed
instructions on:
http://datacharmer.blogspot.com/2011/06/getting-started-with-tungsten.html
Replication works perfectly!
Users get replicated too.
Might as well close this ticket - surely there was a config problem with my
previous install.
Original comment by whitecol...@gmail.com
on 17 Jun 2011 at 4:06
Glad you solved the issue.
Could you diff the properties file between your first and second installation
and tell us what was the difference?
(static-master_t1.properties)
Original comment by g.maxia
on 17 Jun 2011 at 4:32
diff old new
< replicator.master.connect.uri=thl://localhost:21220/
---
> replicator.master.connect.uri=thl://t1:21197/
< cluster.name=
---
> cluster.name=default
< local.service.name=t1
---
> local.service.name=master_t1
< replicator.resourceLogPattern=mysqld_log
< replicator.resourceLogDir=/var/lib/mysql
---
> replicator.resourceLogPattern=mysql-bin
> replicator.resourceLogDir=/var/log/mysql
... few more.
Complete Diff's attached (remember its diff old new)
Original comment by whitecol...@gmail.com
on 17 Jun 2011 at 5:27
Attachments:
Thank you for your help and feedback on this issue.
While I haven't found what was the problem, I am happy that the new
installation avoids it.
Original comment by g.maxia
on 17 Jun 2011 at 5:52
Update:
Have repeated the same problem again, if service is remote.
How to repeat:
1. Create service master_t1 with Host1 [master] Host2 [slave]
2. Everything works ok if the slave has replicator.service.type=local
3. Problem occurs when change service to 'remote' in slave.
Host2 [slave] in static-master_t1.properties:
replicator.service.type=local <--- with this setting, replication works OK.
replicator.service.type=remote <--- with this setting, user's dont get
replicated!
Am trying to setup 3 servers, with each server as a master and slave of 2 other
servers.
master_t1: Host1 [master] Host2 [slave] Host3 [slave]
master_t2: Host1 [slave] Host2 [master] Host3 [slave]
master_t3: Host1 [slave] Host2 [slave] Host3 [master]
The problem starts when trying to setup 2 slave services as 'local' slave
services.
When doing that, the service doesen't start with an error of 'address is in
use'.
But when making the slave services 'remote' - it works.
However, when making slave service 'remote' - replication doesent replicate
user accounts...
Original comment by whitecol...@gmail.com
on 17 Jun 2011 at 6:17
Attachments:
If you are using multiple masters, the matter is different.
This is a known issue. Every Tungsten instance must have at most one local
service. You can instantiate more than one services, but the next ones must be
remote.
If you want to do multiple masters, then each service with 'master' role must
be local, and then the slaves are remote.
As for the GRANT not being replicated in multi-master setup, this seems to be
the same problem as Issue#81.
Original comment by g.maxia
on 17 Jun 2011 at 6:33
Original issue reported on code.google.com by
whitecol...@gmail.com
on 16 Jun 2011 at 4:29