Answers.Body: <p>This is an interesting approach!</p>
  
  <p>As you rightly noted, that bug report was wrong a long while ago and didn't get traction. </p>
  
  <p>As you mentioned you have developers able to help, I would suggest you do a quick evaluation to identify if the install procedure (without installing sample data) breaks still with an autoincrement >1</p>
  
  <p>Obviously, in a separate install that you might end up trashing.</p>
  
  <p>in your install/index.php line 1007 or so alter  requireMySQLAutoIncrementIncrementOne so it's first line is </p>
  
  <pre><code>return; // bypass the test, the sky might fall, but at least we'll know how exactly.
  </code></pre>
  
  <p>I think the general plan for inclusion of a new feature is: if you do the work of identifying the issue and code the fix(or fund the work if needed), it's likely to be accepted ;) </p>
  
  <p>Assuming that it doesn't have any impact for "normal" users that have an increment of 1, I personally would want to try (or at least master-slave for a starting point)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T16:30:56.103Z
Answers.Text: Good idea - will try and let you know soon!
Answers.UserDisplayName: ExGerman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T16:56:28.003Z
Answers.Text: Xavier - indeed this seems to work!
  
  I did not install CiviCRM again but just changed the my.cnf of one of my servers and activated "master replication" with the lines
Answers.UserDisplayName: ExGerman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T17:04:42.507Z
Answers.Text: log-bin = mysql-bin
  server-id = 1
  auto_increment_offset = 2
  auto_increment_increment = 2
  binlog-do-db = civicrm
  replicate-do-db = civicrm
  binlog_format=mixed
  
  I added 6 contacts with multiple addresses and other 1:n data - no error occurred and looking into the database I can confirm that the id's of the new created contacts, adresses etc. were generated in steps of 2 - all equal numbers.
  
  This was not a complete test of all functions, of course.
  
  But the great question is: why the hell the installation requires auto_increment_increment = 1 while auto_increment_increment = 2 seems to work?
Answers.UserDisplayName: ExGerman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T17:05:13.837Z
Answers.Text: Awesome that is passed that first test. Unfortunately, I can't think of anything that I can suggest you to test specifically, but would be good you spend a fair amount of time doing various manipulations and creating various things to see if it doesn't break.
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T17:10:50.550Z
Answers.Text: of course - we'll se what will happen with further tests.
  
  But somebody in the developers team has implemented the check in the installation procedure - probably he had a good reason to do so. How can we find out why this (for PHP/Mysql unusual) check was implemented?
Answers.UserDisplayName: ExGerman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T17:17:37.263Z
Answers.Text: may be somebody should add a reference at https://issues.civicrm.org/jira/browse/CRM-7923 to this thread so in future other users can find the solution?
Answers.UserDisplayName: ExGerman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-30T12:49:06.973Z
Answers.Text: @ExGerman - It would be nice to hear a report on how this went.  Did it continue to work OK?
Answers.UserDisplayName: mc0e
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T16:24:05.577Z
Answers.LastActivityDate: 2015-10-30T16:24:05.577Z
Answers.UserDisplayName: Xavier
Body: <p>For our installation in a "Third World Country" we need 2 replicated Master-Master Mysql-Servers: </p>
  
  <ul>
  <li>one in a European data center to serve the public website and allow access from mobile devices to CiviCRM</li>
  <li>one local server to serve the office staff (as the internet line of the office often does not work and the staff cannot depend on the server in the data center)</li>
  </ul>
  
  <p>We run 2 "master-master-replicated" MySQL-Server </p>
  
  <ul>
  <li>one with auto_increment_offset = 1</li>
  <li>the other with auto_increment_offset = 2</li>
  <li>both with auto_increment_increment = 2</li>
  </ul>
  
  <p>in my.cnf so that one server uses odd ids and the other one even ids when inserting record. This works perfectly in other PHP/Mysql based software we are using. We do not have a problem with the replication of our running servers.</p>
  
  <p>When installing CiviCRM we received the message</p>
  
  <p>"An auto_increment_increment value greater than 1 is not currently supported. Please see issue CRM-7923 for further details and potential workaround."</p>
  
  <p><a href="https://issues.civicrm.org/jira/browse/CRM-7923" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-7923</a> not really is helpful with that issue - it explains how to undergo the configuration of replicated servers which does not help in our case as we need the master-master replication with CiviCRM. This pages also shows that this topic seems to exist since several years without any change.</p>
  
  <p>We googled a lot and did not find any solution for this important feature to use CiviCRM on 2 (or even more) replicated master database servers.</p>
  
  <p>So I address the following questions:</p>
  
  <ol>
  <li>why CiciCRM only supports id increments of 1 when inserting records? Which technical reason defines this limit?</li>
  <li>are there any modules to change this handicap? if not:</li>
  <li>where in the code, where is the point to change this behavior? We have a team of PHP developers to work on this problem if we would know where to start</li>
  <li>is there - may be - a plan to change this problem in the near future e.g. in 4.7?</li>
  <li>what other recommendation do you have for our organizational need of 2 servers - without setting up CiviCRM on 2 database servers with "master-master replication"?</li>
  </ol>
  
  <p>Kind regards and thanks a lot for your answer!</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-03T17:13:44.777Z
Comments.Text: I stumbled upon this looking at possibilities for clustered HA/Performance. I tried installing with 4.7 with a Galera cluster. Unfortunately the install failed. looks like something requires auto increment value to be one somewhere, at least in 4.7
Comments.UserDisplayName: Jessie Lee
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-03T18:55:08.867Z
Comments.Text: This is more of a comment than an Answer
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-03T19:18:14.843Z
Comments.Text: I unfortunately don't have the reputation to comment on the previous answer
Comments.UserDisplayName: Jessie Lee
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-04T01:56:33.390Z
Comments.Text: sorry - wish that was more obvious to users like me. perhaps i need to learn to start looking at people's reps. will up your comment
Comments.UserDisplayName: petednz - fuzion
Tags: <mysql>
Title: MySQL Master-Master Replication on 2 servers
ThreadText: # MySQL Master-Master Replication on 2 servers
  
  (Asked by: username_0 on 2015-10-30)
  
  For our installation in a "Third World Country" we need 2 replicated Master-Master Mysql-Servers:
  
  * one in a European data center to serve the public website and allow access from mobile devices to CiviCRM
  * one local server to serve the office staff (as the internet line of the office often does not work and the staff cannot depend on the server in the data center)
  
  We run 2 "master-master-replicated" MySQL-Server
  
  * one with auto\_increment\_offset = 1
  * the other with auto\_increment\_offset = 2
  * both with auto\_increment\_increment = 2
  
  in my.cnf so that one server uses odd ids and the other one even ids when inserting record. This works perfectly in other PHP/Mysql based software we are using. We do not have a problem with the replication of our running servers.
  
  When installing CiviCRM we received the message
  
  "An auto\_increment\_increment value greater than 1 is not currently supported. Please see issue CRM-7923 for further details and potential workaround."
  
  <https://issues.civicrm.org/jira/browse/CRM-7923> not really is helpful with that issue - it explains how to undergo the configuration of replicated servers which does not help in our case as we need the master-master replication with CiviCRM. This pages also shows that this topic seems to exist since several years without any change.
  
  We googled a lot and did not find any solution for this important feature to use CiviCRM on 2 (or even more) replicated master database servers.
  
  So I address the following questions:
  
  1. why CiciCRM only supports id increments of 1 when inserting records? Which technical reason defines this limit?
  2. are there any modules to change this handicap? if not:
  3. where in the code, where is the point to change this behavior? We have a team of PHP developers to work on this problem if we would know where to start
  4. is there - may be - a plan to change this problem in the near future e.g. in 4.7?
  5. what other recommendation do you have for our organizational need of 2 servers - without setting up CiviCRM on 2 database servers with "master-master replication"?
  
  Kind regards and thanks a lot for your answer!
  
  **Tags:** mysql
  
  > **Comments:**
  > **username_1**: I stumbled upon this looking at possibilities for clustered HA/Performance. I tried installing with 4.7 with a Galera cluster. Unfortunately the install failed. looks like something requires auto increment value to be one somewhere, at least in 4.7  
  > **username_2**: This is more of a comment than an Answer  
  > **username_1**: I unfortunately don't have the reputation to comment on the previous answer  
  > **username_2**: sorry - wish that was more obvious to users like me. perhaps i need to learn to start looking at people's reps. will up your comment  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2015-10-30. Score: 2
  
  This is an interesting approach!
  As you rightly noted, that bug report was wrong a long while ago and didn't get traction. 
  As you mentioned you have developers able to help, I would suggest you do a quick evaluation to identify if the install procedure (without installing sample data) breaks still with an autoincrement >1
  Obviously, in a separate install that you might end up trashing.
  in your install/index.php line 1007 or so alter  requireMySQLAutoIncrementIncrementOne so it's first line is 
  return; // bypass the test, the sky might fall, but at least we'll know how exactly.
  
  I think the general plan for inclusion of a new feature is: if you do the work of identifying the issue and code the fix(or fund the work if needed), it's likely to be accepted ;) 
  Assuming that it doesn't have any impact for "normal" users that have an increment of 1, I personally would want to try (or at least master-slave for a starting point)
  
  > **Comments:**
  > **username_0**: Good idea - will try and let you know soon!  
  > **username_0**: username_3 - indeed this seems to work!  I did not install CiviCRM again but just changed the my.cnf of one of my servers and activated "master replication" with the lines  
  > **username_0**: log-bin = mysql-bin server-id = 1 auto_increment_offset = 2 auto_increment_increment = 2 binlog-do-db = civicrm replicate-do-db = civicrm binlog_format=mixed  I added 6 contacts with multiple addresses and other 1:n data - no error occurred and looking into the database I can confirm that the id's of the new created contacts, adresses etc. were generated in steps of 2 - all equal numbers.  This was not a complete test of all functions, of course.  But the great question is: why the hell the installation requires auto_increment_increment = 1 while auto_increment_increment = 2 seems to work?  
  > **username_3**: Awesome that is passed that first test. Unfortunately, I can't think of anything that I can suggest you to test specifically, but would be good you spend a fair amount of time doing various manipulations and creating various things to see if it doesn't break.  
  > **username_0**: of course - we'll se what will happen with further tests.  But somebody in the developers team has implemented the check in the installation procedure - probably he had a good reason to do so. How can we find out why this (for PHP/Mysql unusual) check was implemented?  
  > **username_0**: may be somebody should add a reference at https://issues.civicrm.org/jira/browse/CRM-7923 to this thread so in future other users can find the solution?  
  > **username_4**: @username_0 - It would be nice to hear a report on how this went.  Did it continue to work OK?  
  
  ---
  
  