Oplocks

Op Locks

Op locks -- Opportunistic Locking -- is a performance technique used by file sharing which has a record of occasionally causing serious problems with reading MySQL binary logs for ISoft. The SMB/CIFS file sharing standards (i.e. Windows File Sharing) use the technique of opportunistic locking to help facilitate higher performance reading and writing in a "normal" environment. Replikwando's use of the MySQL binary log should not be considered "normal" in terms of file sharing: both MySQL and RPK need to have open file handles to the binary log at the same time. Opportunistic locking usually doesn't handle that situation especially well. When both systems are Windows, usually things are okay, but if one of them is not (like the MySQL server is a Linux system), or is a particularly different version of Windows, Op Locks tend to enter fail states. Usually that means that RPK will believe that it is current in the binary log (and will *appear* to be current in the binary log according to its status values), but will not read any useful information from the binary log. This is because the op lock that MySQL is holding causes the binary log's size to be adjusted, but the actual file contents are not refreshed. (Op locks are less of a "lock" as traditionally understood, and more of a messaging system to indicate between computers that a file in a share has been changed, to better allow for client-side caching. Since the whole point is that the mysql binary log may have changed at any point, )

Even if RPK and MySQL are on the same system, if the binary log is inside a file share, op locks can be invoked which could, at least theoretically, cause conflicts (especially if they run under different users). For that reason alone (and there are other reasons), it is strongly discouraged to share out the MySQL binary log if RPK and MySQL are going to be run on the same computer.

If your MySQL server is Linux and your RPK server is on Windows, Samba advises that op locks definitely be disabled on the Samba server (Linux), since Windows clients and Linux software don't really communicate the op lock data with each other correctly.

Disabling Op Locks

Windows

Per https://support.microsoft.com/en-us/help/296264/configuring-opportunistic-locking-in-windows Oplocking cannot be disabled for SMB2 (and SMB3), but can be disabled for SMB1.

This registry entry will disable op locks HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\OplocksDisabled=1 (REG_DWORD)

This registry entry will disable the granting of oplocks HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\EnableOplocks 0 (REG_DWORD)

Windows will need to be restarted to apply these changes.

Now, since SMB2 cannot have oplocks disabled (in Windows), an option when needing to disable oplocks, is to also disable newer versions of SMB: https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and

The methodology for that depends on the version of Windows somewhat. In Windows 8, 10, and 2k12+ you can run the following from PowerShell: Set-SmbServerConfiguration -EnableSMB2Protocol $false

In Windows 7, Vista, and 2k8, set the following Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SMB2=0 (REG_DWORD)

Linux

On a per-share basis, op locks can disabled, and Samba generally recommends that op locks be disabled in any situation where you have Linux applications on-server interacting with files which are shared to Windows clients.

In smb.conf: [share] oplocks = False level2 oplocks = False

Alternatively, it is possible to empower recent kernels with the ability to emit op lock breaks, which might be able to solve the op lock contention issue while still allowing op locks to exist for files which are not often modified. This is on a per-server basis:

In smb.conf: kernel oplocks = yes