zkfan / tungsten-replicator

Automatically exported from code.google.com/p/tungsten-replicator
0 stars 0 forks source link

Tungsten does not replicate users #118

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create 1 master--> slave service: Host1 [master] Host2 [slave]
2. Create a user on Host1 (GRANT ALL ON *.* TO testuser@'%' IDENTIFIED BY 
'test')
3. Try to login to Host2 with this user account - can't login!

What is the expected output?
Tungsten should replicate users from master to slave.

What do you see instead?
Tungsten replicates everything EXCEPT user accounts.

What version of the product are you using?
2.0.3

On what operating system?
Linux (Fedora 15)

Please provide any additional information below.
Posted on groups: 
http://groups.google.com/group/tungsten-replicator-discuss/browse_thread/thread/
5093c18784ac728d

Notes.
We want Moshiach Now: www.moshiach.com

Original issue reported on code.google.com by whitecol...@gmail.com on 16 Jun 2011 at 4:29

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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