Release Notes

    Phoenix 5.0.0-alpha is a “preview” release. This release is the first version of Phoenix which is compatible with Apache Hadoop 3.0.x and Apache HBase 2.0.x. This release also is designated an “alpha” release because there are several known deficiencies which impact the production readiness. This release should be used carefully by users who have taken the time to understand what is known to be working and what is not.

    Known issues:

    • Split/Merge logic with Phoenix local indexes are broken (PHOENIX-4440)
    • Apache Tepha integration/transactional tables are non-functional (PHOENIX-4580)
    • Point-in-time queries and tools that look at “old” cells are broken, e.g. IndexScrutiny (PHOENIX-4378)
      The developers would like to encourage users to test this release out and report any observed issues so that the official 5.0.0 release quality may be significantly improved.

    PHOENIX-3164 is a relatively serious bug that affects the deployed with “security enabled” (Kerberos or Active Directory). Due to another late-game change in the 4.8.0 release as well as an issue with the use of Hadoop’s UserGroupInformation class, every “client session” to the Phoenix Query Server with security enabled will result in a new instance of the Phoenix JDBC driver PhoenixConnection (and other related classes). This ultimately results in a new connection to ZooKeeper for each “client session”.

    Within a short amount of time of active use with the Phoenix Query Server creating a new ZooKeeper connection for each “client session”, the number of ZooKeeper connections will have grown rapidly likely triggering ZooKeeper’s built-in denial of service protection (maxClientCnxns). This will cause all future connections to ZooKeeper by the host running the Phoenix Query Server to be dropped. This would prevent all HBase client API calls which need to access ZooKeeper from completing.

    Both and PHOENIX-2120 cause rows to not be ordered correctly for the following types of columns:

    • DECIMAL DESC columns
    • ARRAY DESC columns
    • Nullable DESC columns which are indexed (impacts the index, but not the data table)

    This will look through all tables you’ve defined and indicate if any upgrades are necessary. Ensure your client-side phoenix.query.timeoutMs property and server-side hbase.regionserver.lease.period are set high enough for the command to complete.

    To upgrade the tables, run the same command, but list the tables you’d like upgraded like this:

    This will first make a snapshot of your table and then upgrade it. If any problems occur during the upgrade process, the snapshot of your original table will be restored. Again, make sure your timeouts are set high enough, as the tables being upgraded need to be rewritten in order to fix them.

    This is important, because the PHOENIX-2120 was caused by BINARY columns being incorrectly padded with a space characters instead of a zero byte characters. The upgrade will replace trailing space characters with zero byte characters which may be invalid if the space characters are legitimate/intentional characters. Unfortunately, Phoenix has no way to know if this is the case.

    Upgrading your tables is important, as without this, Phoenix will need to reorder rows it retrieves back from the server when otherwise not necessary. This will have a large negative impact on performance until the upgrade is performed.

    Future releases of Phoenix may require that affected tables be upgraded prior to moving to the new release.