{
  "schema_version": 2,
  "id": "operate/rs/release-notes/legacy-release-notes/rlec-4-3-aug-2016",
  "title": "RLEC 4.3.0-230 Release Notes (August 2, 2016)",
  "url": "https://redis.io/docs/latest/operate/rs/release-notes/legacy-release-notes/rlec-4-3-aug-2016/",
  "summary": "",
  "tags": [
    "docs",
    "operate",
    "rs"
  ],
  "last_updated": "2026-09-24T14:54:25+01:00",
  "page_type": "content",
  "content_hash": "ccd66eaa9adc10ea569140aadc7379156a19f4bb9cf2ff011cbc4e5af77f5c4b",
  "sections": [
    {
      "id": "overview",
      "title": "Overview",
      "role": "overview",
      "text": "If you are upgrading from a previous version, make sure to review the\n[upgrade\ninstructions](https://redis.io/docs/latest/operate/rs/installing-upgrading/upgrading)\nbefore running through the upgrade process.\n\nYou can upgrade to this version from any 4.2 version. If you have a\nversion older than 4.2 you should first upgrade to 4.2 and only then\nupgrade to this version."
    },
    {
      "id": "new-features",
      "title": "New features",
      "role": "content",
      "text": "- Various improvements to internal performance and stability were\n    implemented.\n- RLEC Flash functionality added. For additional details, refer to\n    [Auto Tiering](https://redis.io/docs/latest/operate/rs/databases/flash)\n    and contact <support@redislabs.com> if you are interested in this\n    functionality.\n- Support for Redis version 3.0 added. When you install or upgrade the\n    cluster the new default version for Redis databases will be 3.0 and\n    when you upgrade the databases they will be updated to this version.\n    If you would like to change the default version to Redis 2.8 refer\n    to the instruction in the [Upgrading\n    databases](https://redis.io/docs/latest/operate/rs/installing-upgrading/upgrading)\n    section. If you would like to upgrade existing databases to the\n    latest 2.8 minor version, refer to the Known Issues section below.\n- Complete cluster failure recovery instructions added. For additional\n    details, refer to [Cluster\n    Recovery](https://redis.io/docs/latest/operate/rs/clusters/cluster-recovery).\n- Major improvements made to database replication performance process\n    by using diskless replication between master and replica shards. The\n    data between the master and replica shards is streamed directly,\n    instead of using the default file-on-disk mechanism. This behavior\n    can be changed for the entire cluster or per database through\n    rladmin.\n- Major enhancements made to rladmin command line interface to add new\n    administration functionalities.\n- rlcheck installation verification utility added to facilitate\n    checking node health. For additional details, refer to [rlcheck\n    installation verification\n    utility](https://redis.io/docs/latest/operate/rs/references/cli-utilities/rlcheck).\n- Added the ability to allow the user to configure how machine IP\n    addresses are used in Node Configuration setup in the management UI.\n    For additional details, refer to [Initial setup - creating a new\n    cluster.](https://redis.io/docs/latest/operate/rs/clusters/new-cluster-setup)\n- Connection to database endpoint can now be encrypted with SSL. For\n    additional details, refer to [Securing client connection with\n    SSL](https://redis.io/docs/latest/operate/rs/security/encryption/tls).\n- Added support for running the cluster on the following operating\n    systems and versions: RHEL/CentOS 6.6, 7.1, 7.2, RHEL 6.7, Oracle\n    Linux 6.5."
    },
    {
      "id": "changes",
      "title": "Changes",
      "role": "content",
      "text": "- Environment configuration profile with name \"default\" has been\n    changed to \"cloud\" and the default value has been changed to\n    \"local-network\". For additional details, refer to [Performance\n    optimization](https://redis.io/docs/latest/operate/rs/clusters/optimize/optimization)\n    section.\n- In the REST API, when creating a database and not setting the\n    database replication parameter to \"true\", the default value assigned\n    by the cluster has changed from \"true\" to \"false\".\n- rladmin syntax updates can affect commands written for prior\n    versions of RLEC. In this version commands that are run directly\n    from the operating system CLI prompt (not through the rladmin\n    prompt) no longer require quotation marks for text with special\n    characters.\n- Option added to the *Replica-of* process that allows gradual\n    \"shard-by- shard\" replication of a sharded database, reducing the\n    load on internal buffers. This optimization setting can be\n    configured on the target database using the gradual_sync_mode\n    parameter in rladmin.\n- The functionality for taking a node offline was removed from the UI."
    },
    {
      "id": "fixed-issues",
      "title": "Fixed issues",
      "role": "content",
      "text": "- RLEC-7110 - node does not recover properly after restart in case\n    ephemeral storage is not available yet\n- RLEC-7502 - log rotate job not working properly on RHEL operating\n    system\n- RLEC-7599 - issues running on a server with no IPv6 kernel support\n- RLEC-7561, RLEC-7597 - issues connecting to database endpoint as\n    result of cluster name containing capital letters\n- RLEC-7245 - on machines with multiple IPs sometimes the wrong IP\n    address is chosen for internal traffic\n- RLEC-6815 - wrong log entry is added when enabling cluster alert\n    regarding database version compatibility\n- RLEC-7652 - database is down in certain failover scenarios only\n    when the database is completely empty\n- RLEC-7737 - issue where in a specific scenario after node restarts,\n    a database with replication both master and replica shards are\n    reported as down\n- RLEC-7712 - in some cases, the Replica Of process may fail when\n    Redis password is set\n- RLEC-7726 - node object \"avg_latency\" statistic is not returned in\n    the REST API\n- RLEC-7358 - install script issue when running on LVM disks\n- RLEC-8086 - port 9443 missing from redislabs-clients.xml\n- RLEC-7281 - rotation of internal log files not working properly\n- RLEC-8279 - updates to a user definition might cause password reset\n    to be required\n- RLEC-8512 - when upgrading an existing cluster that has uppercase\n    letters in the cluster name (FQDN) the cluster might not function\n    properly after the upgrade and attempts to connect to a database\n    might fail\n- RLEC-8371 - email alerts do not work when using Amazon SES service\n- In certain scenarios the node upgrade process may fail if the node\n    is in the offline state"
    },
    {
      "id": "known-issues",
      "title": "Known issues",
      "role": "content",
      "text": "- **Issue**: When upgrading to this version from a previous RLEC\n    version, rladmin status output will show the database status as\n    having an old version. When you upgrade the Redis database (using\n    rladmin upgrade db command) the Redis version will be updated to 3.0\n    even if you updated the cluster's Redis default version to\n    2.8.\n    \n    **Workaround**: If you would like to cancel the old version\n    indication in rladmin status without upgrading the Redis version to\n    3.0 you should first change the cluster default version to 2.8\n    (using rladmin tune cluster command), and then trigger the Redis\n    process to be restarted by migrating the database shards (using\n    rladmin migrate db command).\n\n- **Issue**: RLEC-8486 - On Ubuntu, when uninstalling RLEC using the\n    apt-get purge command, some of the Redis processes on the machine\n    might continue running.\n    \n    **Workaround**: If you encounter this issue\n    you must manually kill the Redis processes.\n\n- **Issue**: RLEC-8283 - The cluster recovery process does not work\n    properly when the cluster that needs to be recovered does not have a\n    node with ID 1.\n    \n    **Workaround**: If you encounter this issue please\n    [contact Redis support](https://redislabs.com/company/support/)\n\n- **Issue**: In the Replica Of process, if the target database does\n    not have replication enabled and it is restarted or fails for any\n    reason, the data on the target database might not be in sync with\n    the source database, although the status of the Replica Of process\n    indicates that it is.\n    \n    **Workaround**: You must manually stop and\n    restart the synchronization process in order to ensure the databases\n    are in sync.\n\n- **Issue**: In the Replica Of process, if the source database is\n    resharded while the Replica Of process is active, the\n    synchronization process will fail.\n\n    **Workaround**: You must manually\n    stop and restart the synchronization process after the resharding of\n    the source database is done.\n\n- **Issue**: In the Replica Of process, high database traffic might restart the Replica Of process due to the \"replica buffer\" being exceeded. In this case\n    you will often see the status of the Replica Of process display as\n    \"Syncing\".\n    \n    **Workaround**: You must manually increase the \"replica\n    buffer\" size through rladmin. In order to find the appropriate\n    buffer size please [contact Redis support](https://redislabs.com/company/support/)\n\n- **Issue**: In a cluster that is configured to support rack-zone\n    awareness, if the user forces migration of a master or replica shard\n    through rladmin to a node on the same rack-zone as its corresponding\n    master or replica shard, and later runs the rebalance process, the\n    rebalance process will not migrate the shards to ensure rack-zone\n    awareness compliance.\n    \n    **Workaround**: In the scenario described\n    above, you must use rladmin to manually migrate the shard, to a node\n    on a valid rack-zone in order to ensure rack-zone awareness\n    compliance."
    }
  ],
  "examples": []
}