Skip to content

Conversation

lxyu
Copy link
Contributor

@lxyu lxyu commented Jul 21, 2014

The 255 server_id as default easy conflicted each other when multiple binlog streams started following the same server.

Use as random int with high value range to minimize the conflict possibility.

@julien-duponchelle
Copy link
Owner

Perhaps we can detect if someone use this id and use an empty:
http://dev.mysql.com/doc/refman/5.0/en/show-slave-hosts.html

@julien-duponchelle
Copy link
Owner

I totaly agree this is an issue and we should fix it if user doesn't provide a server_id

@bjoernhaeuser
Copy link
Collaborator

I don't like this. The user should provide the server id and we should not take care of it.

@lxyu
Copy link
Contributor Author

lxyu commented Jul 23, 2014

I don't like this. The user should provide the server id and we should not take care of it.

I think if we want the user to provide a server_id, it should be args without default value and let the user know it.

If it has a default value, we should make it right. In this case, user who do not read source code won't know about it, and will come across very strange problems when running multiple daemons.

We used some very tricky hacks to bypass the conflict problem until I realize it's because of the same server_id... = =#

@bjoernhaeuser
Copy link
Collaborator

you are right, than we should possible remove the default value.

@lxyu
Copy link
Contributor Author

lxyu commented Jul 25, 2014

So what's the final thoughts here? currently we have 2 directions:

  1. we random the server_id and detect if it's the same with existing ids.
  2. we remove the default value and users will have to set server_id explictly to use the stream

I still think 1 is the way to go, since most users don't need to worry about server_id and it seems have no side-effects, while if we choose 2, it may break some existing scripts.

@julien-duponchelle
Copy link
Owner

I have another suggestion:

  • We remove default server_id to make it clear and in some use case it's a problem.
  • We add a special value for server_id in order to have an auto assign value for people who want this (for some use case it's a nice to have)
  • We properly document that

server_id = "auto" can do the job but 'm not a big fan of having to kind of type in the same value

@julien-duponchelle
Copy link
Owner

What did you think about that?

@bjoernhaeuser
Copy link
Collaborator

I still think that removing the default value should be the way to go. Users relying on the old behaviour just have to provide an value and users which need random server_ids can provide them.

There are no many different replication setups out there, that I think trying to provide a smart algorithm to guess a good value for all users will he very hard. So just not trying would be the easist thing. :)

@lxyu
Copy link
Contributor Author

lxyu commented Sep 3, 2014

I'm ok with removing the default value, it's better than the current explicit value.

For the 'auto' part, do you like the idea to accept a callable for server_id? for example:

self.__server_id = server_id() if callable(server_id) else server_id

@julien-duponchelle
Copy link
Owner

I'm not sure if callable is not too magic from outside point of views.

lxyu added a commit to lxyu/python-mysql-replication that referenced this pull request Sep 3, 2014
connection_settings was also changed to arg since it's essential and
kwargs default value should not be mutable.
@lxyu
Copy link
Contributor Author

lxyu commented Sep 3, 2014

alright, I'll open another pull request to only remove the server_id default value then.

@lxyu lxyu closed this Sep 3, 2014
@lxyu lxyu deleted the rand_server_id branch September 3, 2014 08:39
julien-duponchelle added a commit that referenced this pull request Sep 10, 2014
remove default server_id as discussed in #80
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants