Timeline for Adding wiredtiger nodes to a non-wiredtiger replica set
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 13, 2015 at 14:19 | vote | accept | Jordi | ||
| Jul 7, 2015 at 7:36 | answer | added | Stennie | timeline score: 2 | |
| Jul 6, 2015 at 15:12 | history | edited | Jordi | CC BY-SA 3.0 |
added 671 characters in body
|
| Jul 6, 2015 at 11:27 | comment | added | Stennie |
Setting the tcp_keepalive_time has definitely fixed the problem for other users with the same issue. I don't think you have a choice of not going through the Azure balancer or some other network gear that has the keepalive issue, so it's definitely worth a try. Note: In case you didn't check my profile .. I work for MongoDB ;-).
|
|
| Jul 6, 2015 at 8:03 | comment | added | Jordi | I can try, but my database is not behind Azure load balancer. Looks like I need to put a higher timeout value on Mongodb. | |
| Jul 6, 2015 at 7:10 | comment | added | Stennie |
tcp_keepalive_time should be lowered as to 120 as per the production notes: "The TCP keepalive on the Azure load balancer is 240 seconds by default, which can cause it to silently drop connections if the TCP keepalive on your Azure systems is greater than this value. You should set tcp_keepalive_time to 120 to ameliorate this problem."
|
|
| Jul 6, 2015 at 6:33 | comment | added | Jordi | tcp_keepalive_time 7200, tcp_keepalive_intvl 75, tcp_keepalive_probes 9 | |
| S Jul 4, 2015 at 3:40 | history | suggested | oNare |
Tag added.
|
|
| Jul 3, 2015 at 21:10 | review | Suggested edits | |||
| S Jul 4, 2015 at 3:40 | |||||
| Jul 3, 2015 at 15:25 | comment | added | Stennie |
What is your tcp_keep_alive setting? That's the key one for Azure (especially if you are getting network timeouts). Insufficient ulimits will generally catch you at a later point in the initial sync process.
|
|
| Jul 3, 2015 at 14:20 | history | edited | Jordi | CC BY-SA 3.0 |
added 807 characters in body
|
| Jul 3, 2015 at 13:32 | comment | added | Jordi | that trick worked with environmens with less data. I think it's something related to database size. | |
| Jul 3, 2015 at 13:28 | comment | added | Jordi | My ulimits are: /etc/security/limits.conf mongod soft nproc 64000 mongod hard nproc 64000 mongod soft nofile 64000 mongod hard nofile 64000 It doesn't look like a linux limitation, it looks like mongodb limitation/timeout | |
| Jul 3, 2015 at 13:18 | comment | added | Stennie |
Have you reviewed the production notes for Linux & Azure? In particular I would make sure you have reduced the tcp_keep_alive timing to 120 seconds and increased your ulimits from the default before doing the initial sync.
|
|
| Jul 3, 2015 at 13:09 | comment | added | Jordi | the initial sync starts again and again until consumes the number of attempts. I am using Centos 7.1 on a Azure instance. | |
| Jul 3, 2015 at 12:52 | history | edited | András Váczi | CC BY-SA 3.0 |
deleted 5 characters in body
|
| Jul 3, 2015 at 12:43 | comment | added | Stennie | You have to resync the data because the storage formats on disk are different. Are you getting a specific error during the initial sync? What is your specific O/S version and hosting type (eg AWS, Azure, bare metal, ...)? | |
| Jul 3, 2015 at 12:36 | review | First posts | |||
| Jul 3, 2015 at 12:52 | |||||
| Jul 3, 2015 at 12:32 | history | asked | Jordi | CC BY-SA 3.0 |