Pierre's questions

While trying to delete a directory with "rm -rf", I kept getting "directory not empty". Puzzled, I looked why and I seem to have a "zombie" file stuck in there. I have no idea how to delete it. Is fdisk my only solution?

# rm -rf noc
rm: cannot remove directory `noc/INBOX/#msgs': Directory not empty

# rm -rf noc/INBOX/#msgs/000201E5.eml 

# rm -rf noc
rm: cannot remove directory `noc/INBOX/#msgs': Directory not empty

# rm  noc/INBOX/#msgs/000201E5.eml 
rm: cannot remove `noc/INBOX/#msgs/000201E5.eml': No such file or directory

# cd noc/INBOX/#msgs/
# ls -la
ls: cannot access 000201E5.eml: No such file or directory
total 2248
drwx------ 2 root root 2293760 2013-08-27 21:55 .
drwx------ 3 root root    4096 2013-08-27 21:55 ..
-????????? ? ?    ?          ?                ? 000201E5.eml

# ls -iN | cat -A
6346412 000201E5.eml$

# find . -inum 6346412 -exec rm -i {} \;
find: `./000201E5.eml': No such file or directory

# unlink 000201E5.eml 
unlink: cannot unlink `000201E5.eml': No such file or directory

I have a Mongo DB setup of 4 DB (2 shards of 2 replica) and I noticed that the secondary servers of each shard is not being used for read queries. Both secondary servers received all inserts, updates and deletes from their master but when I look at mongostat, the number under 'query' is always zero.

Do I need to setup something such as 'slaveOk' for my mongos client to be able to use the secondary server of each shard for read queries?

Thanks!

While setting up some collections in a mongo database to be sharded, I entered the name of one of them wrong (typo letter at the end).

When I do db.printShardingStatus(), I see that inexistent collection sitting there and looking dumb. How can I remove it from my sharding config without breaking anything.

Thanks! :)

I currently have a MongoDB replica set configured as such:

{
    "_id" : "ahspy_mongo_set",
    "version" : 13,
    "members" : [
            {
                    "_id" : 0,
                    "host" : "remotedatacenter.in.montreal.dns.com",
                    "priority" : 0
            },
            {
                    "_id" : 1,
                    "host" : "t1.micro.at.ec2.dns.com",
                    "arbiterOnly" : true
            },
            {
                    "_id" : 2,
                    "host" : "m1.xlarge.at.ec2.dns.com"
            }
    ]
}

So basically, one server at EC2 that backups up to another server in Montreal which, for multiple reasons, cannot become master.

I want to change my structure and I'm not sure where to start without causing a lot of trouble. In fact, I'm not even sure what I want to do is possible.

What I want to do is take the main DB server I have at EC2 (m1.xlarge) and turn it into 3 m1.large shards. So basically, go from:

• Replica at EC2 (m1.xlarge)
• Backup Replica in Montreal
• Arbiter

to

• Replica at EC2
  • Shard 1 (m1.large)
  • Shard 2 (m1.large)
  • Shard 3 (m1.large)
• Backup Replica in Montreal
• Arbiter

Is this possible? Can I shard the replica set in EC2 while keeping only one server in the replica in Montreal? If so, what's the proper way to do this? I'm having a real "Chicken and Egg" issue with Replication/Sharding in Mongo so any help would be appreciated.

Thank you very much :).

In the last few months, I've been trying to find the best way to share the content of multiple websites across multiple web servers (12+) all running Apache+PHP. One of the biggest challenge I face is that we need to be able to read and write to the file system at all time, for all kind of good and bad reasons (i.e. app not in our control, wordpress site managed via web interface, etc...).

Here are some of the things I've tried and out it turned out:

• Rsync/duplicity/csync2: Only runs once per minute which means certain changes won't be shared across the cluster fast enough to prevent huge issues.
• inotify/incron: Too complicated considering the huge amount of files and directories to monitor. Also, it wasn't working very well with new files.
• GlusterFS: We had a 4 server gluster backend and the performance, while definitively slow, was tolerable. Unfortunately, the gluster client running on each web server crashed constantly, which then froze one of the 4 file servers for anywhere between 2 and 15 minutes. We reached out to Gluster Inc. to get some of their engineers to help us but they were unable to figure out the problem. We had to give up after 3 months of usage.

General information about our setup:

• Hosted on Amazon EC2
• Running Ubuntu Maverick
• Running Nginx (2) -> Varnish (2) -> Apache (12+)
• .htaccess is disabled for best performance. We add the directives directly to the sites config files
• Most of the websites/apps we run are not ours and unfortunately, a read only environment is not possible
• High-availability with automatic fail-over is very important for us considering the task that these web servers are handling

So I think that covers everything :). Thanks in advance for your time and responses.