Paiboon Panusbordee's questions

I used percona server 5.7 as my database on AWS. The problem is there's sometimes rows disappear mysteriously without a clue. My Backend using Node.JS already got inserted id from auto increment but after that, that rows is disappear without a trace. This happened only sometimes but happened everyday. What should I do to start diagnosis the problems?

More info: There's sometimes my auto increment is skipped like from 1000 to 1004 without anyone delete it from phpmyadmin or in my script since it's "user" table. At time registered time between 1000 to 1004, there's no error log at all from mysql and nodejs. However at this time MySQL experience some table Locked issues for unknown reason and sometimes make insert statement to be queued event I do not make alter table or any table level change at all.

I have some backend url that I use for myself in google chrome only. It's not open public. However for some reason, this bot "Google Favicon" ip located at Google call this URL which I do not want. My guess is Google get this URL from my Google Chrome and try to update cache to this URL everyday. What should I do? I'm not sure if I block its ip, there will be called from new ip later or not.

My redis machine's rdb size is about 1 GB. My app use redis heavily and cannot let the master handle bgsave or else, it will slow down all the system in master's machine down. So, I have to prevent master from doing bgsave and only let slave do the persistence job.

The problem come when master need to be restart. It has to copy rdb from slave to load initial data into memory. This process took around 30-60 seconds. If my redis grow larger, time for the process will be increased.

I have tried NFS to let master and slave use the same rdb to read/write but replication process force master to do bgsave on first time the slave connect to master and it cannot do this job because the source rdb (master) and destination rdb (slave) is at the same place.

The question is "Is there a better way to do this initial load rdb into memory job?".

Bgsave command is a command to fork redis a new process and do background saving on a new core of processor. However, my 2GB data on redis (about 1 GB for RDB after save) is slowdown my data transfer from redis to my app. I tested with 4 core machine (2.5 GHz CPU) with no significant CPU usage from other process. After I run bgsave, I run hgetall immediately and it delay about 14-18 seconds before data is showed in redis-cli. Is there a way to handle this problem? Do I need to use replication to another machine just to do a bgsave command and leave main redis with no bgsave?

I used redis with RDB option only. It used 2GB of memory. When it forked, it used about 10 seconds to completely save the file. When I check up with redis.io site, I found this latency stat:

- Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds (12.8 milliseconds per GB).
- Linux running on physical machine (Unknown HW) 6.1GB RSS forked in 80 milliseconds (13.1 milliseconds per GB)
- Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS forked into 62 millisecodns (9 milliseconds per GB).
- Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds (23.3 millisecond per GB).
- Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds (239.3 milliseconds per GB).
- Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns (424 milliseconds per GB).

I used dedicated server Xeon E3-1240 machines. Compare to these results above, it used lots more time to save. Is it because all my keys are hash? What should I do to reduce latency and reduce impact to main Redis process to query?

In redis.io site, it states that RDB is less durable than AOF. Does this mean there is some possibility of database corruption, and complete data loss if power is lost during a save operation?