Uploaded image for project: 'HBase'
  1. HBase
  2. HBASE-17112

Prevent setting timestamp of delta operations the same as previous value's

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.7, 0.98.23, 1.2.4
    • Fix Version/s: 1.4.0, 1.3.1, 1.2.5, 0.98.24, 1.1.8, 2.0.0
    • Component/s: None
    • Labels:
      None
    • Hadoop Flags:
      Reviewed
    • Release Note:
      Hide
      Before this issue, two concurrent Increments/Appends done in same millisecond or RS's clock going back will result in two results have same TS, which is not friendly to versioning and will get wrong result in slave cluster if the replication is disordered.
      After this issue, the result of Increment/Append will always have an incremental TS. There is no any inconsistent in replication for these operations. But there is a rare case that if there is a Delete in same millisecond, the later result can not be masked by this Delete. This can be fixed after we have new semantics that previous Delete will never mask later Put even its timestamp is higher.
      Show
      Before this issue, two concurrent Increments/Appends done in same millisecond or RS's clock going back will result in two results have same TS, which is not friendly to versioning and will get wrong result in slave cluster if the replication is disordered. After this issue, the result of Increment/Append will always have an incremental TS. There is no any inconsistent in replication for these operations. But there is a rare case that if there is a Delete in same millisecond, the later result can not be masked by this Delete. This can be fixed after we have new semantics that previous Delete will never mask later Put even its timestamp is higher.

      Description

      In delta operations, Increment and Append. We will read current value first and then write the new whole result into WAL as the type of Put with current timestamp. If the previous ts is larger than current ts, we will use the previous ts.

      If we have two Puts with same TS, we will ignore the Put with lower sequence id. It is not friendly with versioning. And for replication we will drop sequence id while writing to peer cluster so in the slave we don't know what the order they are being written. If the pushing is disordered, the result will be wrong.

      We can set the new ts to previous+1 if the previous is not less than now.

        Attachments

        1. HBASE-17112-v2.patch
          3 kB
          Phil Yang
        2. HBASE-17112-v2.patch
          3 kB
          Phil Yang
        3. HBASE-17112-v1.patch
          2 kB
          Phil Yang
        4. HBASE-17112-branch-1-v1.patch
          3 kB
          Phil Yang
        5. HBASE-17112-branch-1-v1.patch
          3 kB
          Phil Yang
        6. HBASE-17112-branch-1.1-v1.patch
          3 kB
          Phil Yang
        7. HBASE-17112-branch-1.1-v1.patch
          3 kB
          Phil Yang

          Activity

            People

            • Assignee:
              yangzhe1991 Phil Yang
              Reporter:
              yangzhe1991 Phil Yang
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: