problem setting up replica sets

[stever]

Hi,

I made some mistakes trying to setup replica sets, and have reversed
it and gone back to running
a single server. I remove the --replSet at startup and removed all
the local.* files in /data as described.
The single server is working fine, but now when I try to configure
replica sets again, mongod comes
up but doesn't accept connections. When you kill it, it doesn't die
easily and writes this to the console:

0x53f3ae 0x719738 0x7205cc 0x720a5c 0x6b80d2 0x64393f 0x816eec
0x81ce5a 0x81d6c8 0x8243ed 0x3f3f81d994 0x4cd9f9
/usr/bin/mongod(_ZN5mongo11msgassertedEiPKc+0x1de) [0x53f3ae]
/usr/bin/mongod(_ZN5mongo13MongoDataFile12createExtentEPKcibi+0x128)
[0x719738]
/usr/bin/mongod(_ZN5mongo13_userCreateNSEPKcRKNS_7BSONObjERSsPb
+0xb7c) [0x7205cc]
/usr/bin/mongod(_ZN5mongo12userCreateNSEPKcNS_7BSONObjERSsbPb+0xfc)
[0x720a5c]
/usr/bin/mongod(_ZN5mongo11createOplogEv+0x962) [0x6b80d2]
/usr/bin/mongod(_ZN5mongo16startReplicationEv+0xbf) [0x64393f]
/usr/bin/mongod(_ZN5mongo6listenEi+0xac) [0x816eec]
/usr/bin/mongod(_ZN5mongo14_initAndListenEiPKc+0x7aa) [0x81ce5a]
/usr/bin/mongod(_ZN5mongo13initAndListenEiPKc+0x18) [0x81d6c8]
/usr/bin/mongod(main+0x6bcd) [0x8243ed]
/lib64/libc.so.6(__libc_start_main+0xf4) [0x3f3f81d994]
/usr/bin/mongod(__gxx_personality_v0+0x3b1) [0x4cd9f9]

I guess there is still something lingering from my first bothched
attempt to configure replica sets.
Can someone tell me how I can clean things up and try again?

Thanks,

Steve

[Eliot Horowitz]

After you rm local.* and start with --replSet, you have to start the other node and initiate the set.

You won't be able to access the server until the set is initiated.

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[stever]

On Sep 6, 12:26 pm, Eliot Horowitz <eliothorow...@gmail.com> wrote:
> After you rm local.* and start with --replSet, you have to start the other
> node and initiate the set.
> You won't be able to access the server until the set is initiated.

I guess I'm in bigger trouble than I thought... As I said, I messed
up the
configuration, so when I went back to "start from scratch" I nuked the
other
server setup as well. Is there no other way to clean up a prior
replication set
configuration?

[Eliot Horowitz]

You should

1) shut down all severs

2) rm local.*

3) start all servers with --replSet/<server1>,<server2>

4) run rs.initiate

should be all set

--

[stever]

Thanks for the help! I was able to get everything working.

This blog post was a great help:

http://www.snailinaturtleneck.com/blog/2010/08/30/return-of-the-mongo-mailbag/

I now have a cluster setup just a described in that posting. One
question though...

See my shard info. below:

shards:
{ "_id" : "sgm1", "host" : "sgm1/192.168.0.160:30000" }
{ "_id" : "sgm2", "host" : "sgm2/192.168.0.170:30000" }

Is this right? It seems strange that there is only one server IP for
each of the replica sets.
I'm just wondering if this is correct and auto-fail-over would still
happen if 192.16.0.160 or 170 were to go out.

Thanks again for the help and building such a great DB.

Steve

[Eliot Horowitz]

That's not quite correct.

When you add the replica set as a shard, you should add all the hosts  you know about.
Just to understand, you have 4 servers, so 2 shards with 2 servers in each?

--

[stever]

Yes, 4 servers, 2 shards with 2 servers in each.
I just noticed that it seems to currently be behaving read-only as
well...

in Kristina Chodorow's Blog I followed the last steps:

> mongos = connect("server4:30000/admin")
connecting to: server4:30000
admin
> mongos.runCommand({addshard : "foo/server1:27017"})
{ "shardAdded" : "foo", "ok" : 1 }
> mongos.runCommand({addshard : "bar/server3:27017"})
{ "shardAdded" : "bar", "ok" : 1 }

should the final argument list all the servers in the replica set as a
comma separated list?

so like this?
"sgm1:192.168.0.160:30000,192.168.0.165:30000,192.168.0.179:30001"
That last one is the arbiter, should that be listed too?

Again, many thanks!

[Eliot Horowitz]

Yes, comma separated. Don't need the arbiter.

[stever]

> I just noticed that it seems to currently be behaving read-only as
> well...

Ah, this doesn't have anything to do directly with the replica sets or
sharding.
I've discovered this in the logs:

DBException in process: Can't modify shard key's value

I think the problem is that when I update documents I never bothered
to exclude
the key that the DB is sharding on. Easy enough to fix in my
application...

This would be something good to document somewhere though as well if
it isn't already(maybe
it is and I missed it).

[stever]

How do I go about updating this now that it is set?
Can I update it directly in the config db? If I do that, do I have
to update it in each one? Sorry to need so much hand holding...

On Sep 6, 7:27 pm, Eliot Horowitz <eliothorow...@gmail.com> wrote:
> Yes, comma separated. Don't need the arbiter.
>

> On Sep 6, 2010, at 7:17 PM, stever <sritacc...@gmail.com> wrote:

[Eliot Horowitz]

Yes - you should update in config server.

You can connect to all at once

mongo --host configa,configb,configc

[stever]

Does this look healthy?
Anything else I can check?
(In the process of "fixing" this I tried a removeshard which really
did nothing because
there isn't enough data in the db for sharding to happen yet. Anyway,
I think I cleaned everything
up in the config DB now and everything seems to be working fine.
I'm hoping that the removeshard doesn't have any lingering
consequences...)
I guess we learn the most by breaking things and having to fix
them. ;-)

> db.printShardingStatus();
--- Sharding Status ---
sharding version: { "_id" : 1, "version" : 3 }

shards:
{ "_id" : "sgm1", "host" :

"sgm1/192.168.0.160:30000,192.168.0.165:30000" }
{ "_id" : "sgm2", "host" :
"sgm2/192.168.0.170:30000,192.168.0.175:30000" }
databases:
{ "_id" : "admin", "partitioned" : false, "primary" : "config" }
{ "_id" : "sg", "partitioned" : true, "primary" : "sgm1" }
sg.dlp chunks:
{ "href" : { $minKey : 1 } } -->> { "href" : { $maxKey : 1 } } on :
sgm1 { "t" : 3000, "i" : 0 }
sg.dlu chunks:
{ "uid" : { $minKey : 1 } } -->> { "fb_uid" : { $maxKey : 1 } }
on : sgm1 { "t" : 3000, "i" : 0 }
sg.so chunks:
{ "uid" : { $minKey : 1 } } -->> { "fb_uid" : { $maxKey : 1 } }
on : sgm1 { "t" : 3000, "i" : 0 }

[Eliot Horowitz]

That looks good to me.

--