Контрольная сумма реплик mysql по ssl

Я никогда не пробовал репликацию мастер-мастер, но я установил SSL-соединения с контрольной суммой pt-table. Надеюсь, мои примечания ниже могут помочь ответить на некоторые из ваших вопросов, связанных с SSL.

В моем случае у меня настроена репликация master-slave с использованием SSL-соединений, и я использую Percona Toolkit 2.1.2. Поскольку способ его настройки был неочевиден, я подумал, что мои заметки помогут сэкономить вам время и силы в вашей ситуации. Ниже приведен пример того, как я получил SSL-соединения, работающие для соединений pt-table-контрольной суммы как с главным, так и с подчиненным серверами баз данных.

Ключ состоит в том, чтобы передать информацию DSN (содержащую настройки SSL) ведомому устройству путем явной передачи файла по умолчанию (например, -F = / etc / my.cnf.percona) ведомому устройству с помощью "--recursion-method dsn "настройка. Из того, что я прочитал на веб-сайте Percona и просмотрев код контрольной суммы pt-table-control, информация DSN не копируется из одного соединения в другое в более поздних версиях Percona Toolkit (начиная с версии 2.0, я полагаю). Итак, вам необходимо настроить ведомое соединение отдельно от ведущего.

Передайте информацию DSN для ведомого соединения, используя:
--recursion-method dsn = "D = percona, t = dsns, F = / etc / my.cnf.percona"

Предположения:
а. Учетная запись базы данных "percona" имеет соответствующие привилегии для контрольной суммы таблицы-pt-таблицы Percona. Я рекомендую использовать "REQUIRE SSL", чтобы убедиться, что учетная запись требуется для использования SSL-соединений.
б. Ведомое устройство и ведущее устройство настроены на использование SSL-соединений.

Примечание. Все описанные ниже действия выполняются на мастере.

(1) Чтобы передать настройки SSL для соединения DBI (т. Е. Конфигурацию DSN), создайте отдельный файл my.cnf специально для программного обеспечения percona.

    /etc/my.cnf.percona
    [client]
    ssl=1
    user=percona
    password=xxxxxxxxx
    ssl-capath=/etc/mysql/ca/crt

    The /etc/my.cnf.percona file will be used to set up the SSL connections to both the master and slave.

    Make sure to set the ownership & permissions on the file since it contains a password:
    chown root:root /etc/my.cnf.percona (if it's not already owned by root or a system account)
    chmod 0600 /etc/my.cnf.percona

(2) Проверьте настройки /etc/my.cnf.percona

  
    # mysql --defaults-file=/etc/my.cnf.percona --host slave.domain.com
    mysql> \s
    --------------
    mysql  Ver 14.14 Distrib 5.5.23, for Linux (x86_64) using readline 5.1

    Connection id:      162
    Current database:   
    Current user:       percona@master.domain.com
    SSL:            Cipher in use is DHE-RSA-AES256-SHA
    Current pager:      stdout
    Using outfile:      ''
    Using delimiter:            ;
    Server version:     5.5.23-log MySQL Community Server (GPL)
    Protocol version:           10
    Connection:             slave.domain.com via TCP/IP
    Server characterset:    latin1
    Db     characterset:    latin1
    Client characterset:    utf8
    Conn.  characterset:    utf8
    TCP port:               3306
    Uptime:         2 days 2 hours 8 min 7 sec


    # mysql --defaults-file=/etc/my.cnf.percona --host master.domain.com
    mysql> \s
    --------------
    mysql  Ver 14.14 Distrib 5.5.23, for Linux (x86_64) using readline 5.1

    Connection id:      581433
    Current database:   
    Current user:       percona@master.domain.com
    SSL:            Cipher in use is DHE-RSA-AES256-SHA
    Current pager:      stdout
    Using outfile:      ''
    Using delimiter:            ;
    Server version:     5.5.23-log MySQL Community Server (GPL)
    Protocol version:           10
    Connection:             master.domain.com via TCP/IP
    Server characterset:    latin1
    Db     characterset:    latin1
    Client characterset:    utf8
    Conn.  characterset:    utf8
    TCP port:               3306
    Uptime:         9 days 3 hours 5 min 49 sec

(3) Настройте таблицу DSN в базе данных percona на главном сервере.

    On the master:
    Create the percona database (if it does not already exist):

    mysql> create database percona;

    If the percona database already exists and you want to redo everything from scratch, drop the checksums & dsns tables if they already exist:

    mysql> drop table percona.checksums;  -- do this only if you are sure you want to start over & redo everything 

    mysql> drop table percona.dsns;   -- ok to drop this, we're recreating it in the next step 


    Create the dsns table in the percona database:


    mysql> use percona;
    mysql> CREATE TABLE `dsns` (
        ->   `id` int(11) NOT NULL AUTO_INCREMENT,
        ->   `parent_id` int(11) DEFAULT NULL,
        ->   `dsn` varchar(255) NOT NULL,
        ->   PRIMARY KEY (`id`)
        -> );

    Insert the slave info into the table:

     mysql> insert into dsns (dsn) values ("h=slave.domain.com");

(4) Запустите контрольную сумму pt-table и явно передайте файл значений по умолчанию (-F = / etc / my.cnf.percona) ведомому устройству, используя параметр "--recursion-method dsn"

    /usr/bin/pt-table-checksum -F /etc/my.cnf.percona h=master.domain.com --recursion-method dsn="D=percona,t=dsns,F=/etc/my.cnf.percona"

    master connection uses "-F /etc/my.cnf.percona h=master.domain.com"
    slave connection uses '--recursion-method dsn="D=percona,t=dsns,F=/etc/my.cnf.percona"'

Это должно создать таблицу контрольных сумм в базе данных percona и подключиться к ведомому (и главному) с помощью SSL-соединений.

Я никогда не пользовался инструментарием percona, но мне кажется, что

(2) pt-table-контрольная сумма не предназначен для «подключения» к ведомому устройству; он предназначен для запуска непосредственно на какой-либо машине и генерирования контрольных сумм на этой же машине (и, при необходимости, подключения к главной машине).

(6) Для файлов в целом рекомендуется использовать реплики контрольной суммы в незащищенных сетях: туннелирование rsync через ssh. а б c d е (Под "rsync" здесь я имею в виду протокол rsync, используемый внутри многих утилит - утилита rsync, duplicity, rsyncrypto, rdiff-backup, dirvish и т. Д.). Я иногда использую rsync --dryrun который просто определяет контрольную сумму, чтобы сказать мне, идентична ли резервная копия / ведомое устройство ведущему. Но чаще я запускаю rsync без опции --dryrun. Без этой опции, если обнаруживаются какие-либо различия, rsync автоматически продолжает обновлять резервную копию / ведомое устройство.

Увы, в базах данных с высокой активностью записи образ базы данных на диске (это все, что может видеть rsync) часто находится в несогласованном состоянии. Чтобы позволить rsync создать полезную резервную копию / реплику, нам обычно нужно ненадолго выключить программное обеспечение базы данных на обоих концах ссылки, чтобы заставить его сбросить все данные из ОЗУ на диск, выполнить обновление rsync и затем перезапустить базу данных. программное обеспечение. Обычно это происходит очень быстро, потому что обычно подавляющее большинство данных не изменяется, а rsync передает только те немногие части данных, которые действительно изменились.

(Насколько я могу судить, единственное преимущество утилит, работающих с базами данных, таких как "pt-table-sync" перед rsync, заключается в том, что эти утилиты, работающие с базами данных, по-видимому, каким-то образом выполняют синхронизацию до согласованного состояния, даже не завершая работу программного обеспечения базы данных. ).