Please enable JavaScript.

Coggle requires JavaScript to display documents.

Redis In Action (Data Structures p34 (String (Integer value (can…

- - - - can increment/decrement. Number range is platform-specific
    - - range is limited to IEEE 754
  - - - system reliability - in older version, slow consuming causes buffer out-grown and may crash the system,
        in newer versions, subers are disconnected when buffer reached limit
      - data transmission reliability - if the client is disconnected and a msg is sent before it reconnect, the message is LOST
- - - - save 60 1000
        
        (automatically call BGSAVE if 1000 writes occerred within 60 seconds since the last successful save has started)
      - stop-writes-on-bgsave-error no
      - rdbcompression yes
      - dbfilename dump.rdb
    - - Redis forks a child process to write snapshot to disk in background
  - - - appendonly yes
      - appendfsync everysec
      - no-appendfsync-on-rewrite no
      - auto-aof-rewrite-percentage 100
      - auto-aof-rewrite-min-size 64mb
    - - first, write data to buffer, then OS take the data and write to disk in the future, optionally call file.flush() to request OS write buffered data to disk asap
      - :!: appendfsync always causes frequent appending small data to end of file, which will cause write amplification and reduce the lifetime of SSD significantly in some cases
      - :star: appendfsync everysec is a good balance
      - :!: will cause large backup file size, and upon restart Redis executes all commands in the AOF, can take long time to start up
    - - BGREWRITEAOF
        
        rewrite the AOF by removing redundant commands background in a forked child process
        
        same(worse) impact as snapshotting, fork time, memory usage, system pausing long time while deleting old AOF file
        
        auto-aof-rewrite-percentage 100
        
        rewrite when the size is 100% larger than the last rewritten one
        
        auto-aof-rewrite-min-size 64mb
        
        rewrite when the AOF file is at least 64mb large
  - - - in configuration file or command, run in slave mode and use the given address as the master
    - - slave connects to the master and issues the SYNC command
        
        master starts BGSAVE and keeps a backlog of all write commands received after BGSAVE, slave serves old data it has for the moment
        
        master finishes BGSAVE, start sending the snapshot to slave and keep backlogging new writes, slave discards all old data and load the snapshot from master
        
        finishes sending the snapshot to the slave, start sending the write command backlog to the slave, slave start responding read requests when finished loading snapshot
        
        master finished sending backlog, resume handling write requests, slave executes backlog and handle read requests after that
      - :!:when a slave initially connects to master, all data in slave's memory will be lost, to be replaced by the data coming from the master
      - :!:Redis does NOT support master-master replication
      - if a slave X has its own slave Y, and X is in step 4, X will disconnect Y, causing Y to reconnect and resync
    - - check output of INFO command for aof_pending_bio_fsync, will be 0 if all data the server knows about has been written to disk
- - - - scans thru the AOF looking for incorrect command. Upon finding the first bad command,
        trim the file to just before that bad command would've been executed. (may discard commands after the first bad command)
    - - NO way to repair a corrupted snapshot. Better keep multiple backups of important snapshots,
        and calculate SHA1 / SHA256 hashes to verify content during restoration. (Redis >= 2.6 includes CRC64 checksum as part of snapshot)
        :star: BUT, CRC checksum is useful for network transfer / disk corruption, SHA checksum is much better suited for discovering arbitrary errors