правильно дампим базу mysql под нагрузкой
Подходит для innodb. создаётся одна транзакция и всё попавшее в эту транзакцию дампится. Главное - не лочится база.
для остальных типа myisam смотри
#mysql
mysqldump --single-transaction somedb sometable
Подходит для innodb. создаётся одна транзакция и всё попавшее в эту транзакцию дампится. Главное - не лочится база.
для остальных типа myisam смотри
man mysqldump
#mysql
Размер баз в MYSQL
#mysql
-- Всё базы + индексы
SELECT table_schema "Data Base Name", SUM(data_length + index_length) / 1024 / 1024 "Data Base Size in MB" FROM information_schema.TABLES GROUP BY table_schema;
-- Индексы:
SELECT table_schema "Data Base Name", SUM(index_length) / 1024 / 1024 "Index Size in MB" FROM information_schema.TABLES GROUP BY table_schema;
-- Базы:
SELECT table_schema "Data Base Name", SUM(data_length) / 1024 / 1024 "Data Base Size in MB" FROM information_schema.TABLES GROUP BY table_schema;
#mysql
Mysql root password
Если при установке пакета вам не сказали\не спросили пароль от рута, то...
#mysql
Если при установке пакета вам не сказали\не спросили пароль от рута, то...
grep 'temporary password' /var/log/mysqld.log#mysql
mysql, сменяем количество коннектов
изучаем сколько сейчас открыто
изучаем сколько кто занимает соединения (грепаем, смотрим вдумчиво, трогаем палочкой)
изучаем сколько сейчас
увеличиваем
меняем конфиг /etc/mysql/my.cnf
#mysql
изучаем сколько сейчас открыто
mysql> show status;
изучаем сколько кто занимает соединения (грепаем, смотрим вдумчиво, трогаем палочкой)
mysql> show processlist;
изучаем сколько сейчас
mysql> select @@global.max_connections;
увеличиваем
mysql> set @@global.max_connections = 4096;
меняем конфиг /etc/mysql/my.cnf
max_connections = 4096
#mysql
Debezium и некоторые мои исследования
Q: возможно ли переключить коннектор на другой сервер?
A: это делается через удаление коннектора методом delete и создания нового. Можно сделать обновление через PUT, но через delete надёжнее. Подробнее можно смотреть доку к кафка коннекторам. в доке дебезиума этого нихрена нет.
Q: можно ли объединить коннекторы в один топик? в том смысле что мы запускаем 2 дебезиума на разных серверах, например.
А: Как показали тесты, нет. записи в schemas_history начинают дублироваться, а параметры коннектора вообще в случае разнесения на разные группы не могут быть никак в одних топиках, иначе будет работать только один коннектор из двух. В итоге на каждый коннектор должен быть 5 топиков: 3 для хранения параметров коннектора и 2 для хранения схемы базы и истории изменений схемы.
Q: что происходит при ротации binlog, если коннектор был выключен
A: Если бинлог не удалился, но отротировался, то будет запрошен существующий бинлог и продолжит с последнего считанного места. После чего постепенно перейдет на чтение актуального бинлога.
Q: можно ли чтобы изменения с разных коннекторов, которые читаю разные таблицы писать в один топик?
А: да, это делается через трансформации, описывается регулярное выражение источник и из него можно формировать целевое название очереди. Этот же прицип можно использовать для переименования топика. Только у них есть баг что это не работает в некоторых версиях. помимо указанной версии я это еще в 1.1 встретил. в 1.3 всё ок.
Q: добавление новой таблицы "на лету"
A: Схема создается дебезиумом при первом инсерте в таблицу. и далее на лету подхватывается. Если таблица только создана и пустая, то это не поедет в кафку.
Q: как правильно настроить retention на топиках?
А: согласно документации требуется бесконечный или очень долгий только на history топиках Infinite (or very long) retention (no compaction!), partition count of 1. И на всех нужно выставить cleanup.policy=compact
В итоге мы делаем как-то так:
--partitions 1 --replication-factor 3 --config retention.ms=-1 --config min.insync.replicas=1 --config cleanup.policy=compact
Q: Можно ли полностью контролировать имена топиков в кафке?
А: да, вполне.
database.server.name - это просто логическое имя. оно будет использовано по-умолчанию как префикс для именования топика с данными (что не очень удобно), но к счастью все топики с данными через трансформацию можно переименовать.
statuses configs offsets - топики которые мы можем создать с любым именем и при старте дебезиума указать их в env.
схему можно задать в конфиге например так: "database.server.name": "debezium.database_name.logical_connector_name.schema"
историю схемы: "database.history.kafka.topic": "debezium.database_name.logical_connector_name.history"
а затем через трансформацию переименовать целевые топики с данными
Q: возможно ли переключить коннектор на другой сервер?
A: это делается через удаление коннектора методом delete и создания нового. Можно сделать обновление через PUT, но через delete надёжнее. Подробнее можно смотреть доку к кафка коннекторам. в доке дебезиума этого нихрена нет.
Q: можно ли объединить коннекторы в один топик? в том смысле что мы запускаем 2 дебезиума на разных серверах, например.
А: Как показали тесты, нет. записи в schemas_history начинают дублироваться, а параметры коннектора вообще в случае разнесения на разные группы не могут быть никак в одних топиках, иначе будет работать только один коннектор из двух. В итоге на каждый коннектор должен быть 5 топиков: 3 для хранения параметров коннектора и 2 для хранения схемы базы и истории изменений схемы.
Q: что происходит при ротации binlog, если коннектор был выключен
A: Если бинлог не удалился, но отротировался, то будет запрошен существующий бинлог и продолжит с последнего считанного места. После чего постепенно перейдет на чтение актуального бинлога.
Q: можно ли чтобы изменения с разных коннекторов, которые читаю разные таблицы писать в один топик?
А: да, это делается через трансформации, описывается регулярное выражение источник и из него можно формировать целевое название очереди. Этот же прицип можно использовать для переименования топика. Только у них есть баг что это не работает в некоторых версиях. помимо указанной версии я это еще в 1.1 встретил. в 1.3 всё ок.
Q: добавление новой таблицы "на лету"
A: Схема создается дебезиумом при первом инсерте в таблицу. и далее на лету подхватывается. Если таблица только создана и пустая, то это не поедет в кафку.
Q: как правильно настроить retention на топиках?
А: согласно документации требуется бесконечный или очень долгий только на history топиках Infinite (or very long) retention (no compaction!), partition count of 1. И на всех нужно выставить cleanup.policy=compact
В итоге мы делаем как-то так:
--partitions 1 --replication-factor 3 --config retention.ms=-1 --config min.insync.replicas=1 --config cleanup.policy=compact
Q: Можно ли полностью контролировать имена топиков в кафке?
А: да, вполне.
database.server.name - это просто логическое имя. оно будет использовано по-умолчанию как префикс для именования топика с данными (что не очень удобно), но к счастью все топики с данными через трансформацию можно переименовать.
statuses configs offsets - топики которые мы можем создать с любым именем и при старте дебезиума указать их в env.
схему можно задать в конфиге например так: "database.server.name": "debezium.database_name.logical_connector_name.schema"
историю схемы: "database.history.kafka.topic": "debezium.database_name.logical_connector_name.history"
а затем через трансформацию переименовать целевые топики с данными
"transforms": "Reroute",#debezium #mysql #kafka
"transforms.Reroute.type": "io.debezium.transforms.ByLogicalTableRouter",
"transforms.Reroute.topic.regex": "debezium.logical_connector_name.logical_connector_name.schema.<REGEXP>",
"transforms.Reroute.topic.replacement": "my_fucking_awesome_new_name_with_group_capture_$1",
Debezium helm chart
Мы с командой Ситимобил написали helm chart для разворачивания debezium в k8s. К сожалению корпоративного репозитория у нас нет, поэтому выкладываю так (по согласованию с руководством, естественно).
Чарт умеет разворачивать дебезиум, на запуске создавать или обновлять коннектор, дополняет апстримовый контейнер прометеус-метриками, а также создаст все нужные очереди в kafka.
Обратите внимание, в чарте используется подход 1 чарт = 1 коннектор, т.к. для высоконагруженных баз объединение конфигов играет злую шутку и может привести к долгому даунтайму. Приятного использования!
https://github.com/bykvaadm/debezium-helm-chart
З.ы. Дашборд для метрик выложим попозже
#debezium
#helm
#kafka
#mysql
#kubernetes
Мы с командой Ситимобил написали helm chart для разворачивания debezium в k8s. К сожалению корпоративного репозитория у нас нет, поэтому выкладываю так (по согласованию с руководством, естественно).
Чарт умеет разворачивать дебезиум, на запуске создавать или обновлять коннектор, дополняет апстримовый контейнер прометеус-метриками, а также создаст все нужные очереди в kafka.
Обратите внимание, в чарте используется подход 1 чарт = 1 коннектор, т.к. для высоконагруженных баз объединение конфигов играет злую шутку и может привести к долгому даунтайму. Приятного использования!
https://github.com/bykvaadm/debezium-helm-chart
З.ы. Дашборд для метрик выложим попозже
#debezium
#helm
#kafka
#mysql
#kubernetes
GitHub
GitHub - bykvaadm/debezium-helm-chart
Contribute to bykvaadm/debezium-helm-chart development by creating an account on GitHub.