Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set autocommit to 0 #4113

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions modules/mariadb/templates/config/mw.cnf.erb
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,12 @@ bind-address = 0.0.0.0,::
key-buffer-size = 16M
myisam-recover-options = FORCE,BACKUP

# Helps soften the blow of cockups such as T12886 and T12974
# Please, please, please don't reenable unless if there is a substitute
# to easily rolling back bad SQL statements when manually interfacing with
# the database.
autocommit = 0
Comment on lines +20 to +24
Copy link
Contributor

@coderabbitai coderabbitai bot Dec 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Critical: Reconsider global autocommit disable

Based on the PR discussion and configuration analysis, disabling autocommit globally presents significant risks:

  1. As noted by Marostegui, Wikimedia avoids this approach due to performance concerns
  2. The current configuration shows heavy use of connection pooling and optimized thread handling
  3. The real issue appears to be unrestricted direct database access

Recommended approach:

  1. Keep autocommit=1 but implement:

    • Restricted database roles for direct access
    • Mandatory access through MediaWiki's abstraction layer
    • Automated backup before direct SQL execution
    • SQL statement validation proxy
  2. If proceeding with autocommit=0:

    • Start with a subset of connections
    • Monitor performance metrics
    • Implement session timeouts
    • Add transaction monitoring

Would you like help creating:

  1. A restricted database role configuration?
  2. A SQL validation proxy implementation?
  3. Performance monitoring queries?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please suggest more options for how we can deal with bad SQLs, consider something that would allow setting this for only cli sessions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RhinosF1, certainly! Here are some options to help you deal with bad SQL statements and configure autocommit=0 specifically for CLI sessions:

  1. Use init_connect to Disable Autocommit for Non-SUPER Users:

    • Set the init_connect global variable to execute SET autocommit=0; whenever a user connects:

      SET GLOBAL init_connect = 'SET autocommit=0;';
    • Note: init_connect does not apply to users with the SUPER privilege. Ensure that CLI users do not have SUPER privileges to enforce this setting.

  2. Conditional init_connect Based on User or Host:

    • Modify init_connect to conditionally disable autocommit based on the connecting user:

      SET GLOBAL init_connect = "
        IF (CURRENT_USER() = 'cli_user'@'localhost') THEN
          SET autocommit=0;
        END IF;
      ";
    • Replace 'cli_user'@'localhost' with the appropriate user and host for CLI sessions.

  3. Client-Side Configuration in my.cnf:

    • Update the MySQL client configuration to disable autocommit for CLI sessions:

      [mysql]
      init-command=SET autocommit=0
      
    • Add this to the global /etc/mysql/my.cnf or users' personal ~/.my.cnf files under the [mysql] section. This ensures that whenever the mysql CLI is used, autocommit is disabled for that session.

  4. Create a Wrapper Script for the MySQL CLI:

    • Develop a shell script that sets autocommit to 0 upon connection:

      #!/bin/bash
      mysql --init-command="SET autocommit=0;" "$@"
    • Have users invoke this script instead of the mysql command to ensure autocommit is disabled during their sessions.

  5. Restrict Direct Database Access:

    • Limit direct access to the database by:

      • Using application interfaces (like MediaWiki's sql.php) that handle transactions properly.
      • Providing limited privileges to users who require CLI access.
      • Encouraging the use of transactions (START TRANSACTION;) explicitly during manual interventions.
  6. Implement a SQL Proxy with Session Initialization:

    • Utilize a SQL proxy (e.g., ProxySQL or MaxScale) to intercept connections and set session variables like autocommit=0 for specific users or hosts.
  7. Educate and Enforce Best Practices:

    • Train operators on safe SQL practices, emphasizing the importance of transactions and proper commit/rollback procedures.
    • Create guidelines or checklists for performing manual SQL operations.

Additional Suggestions:

  • Audit and Logging:

    • Enable detailed logging for CLI sessions to monitor and audit queries executed directly on the database.
  • Automate Backups Before Manual Changes:

    • Implement scripts that create backups or snapshots before allowing direct SQL execution, providing a safety net in case of errors.
  • Review and Approval Processes:

    • Require review or approval for manual SQL statements that modify data, reducing the likelihood of mistakes.

Feel free to let me know if you'd like assistance implementing any of these options or exploring them further.


max-allowed-packet = 64M
max-connect-errors = 1000000
sql-mode = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE
Expand Down
Loading