MySQL Registracia - малко хелп за философията ?
Изчетох мануала, май направих всичко, както го пише, но не ми е ясно:
1. Това репликацията, непрекъснат процес ли е? Като го стартирам с заявка:
stop slave;
reset slave;
change master to Master_host='10.16.1.11',
master_user='ReplNB',
master_password='PassReplNB',
master_log_file='1.004',
master_log_pos=79;
на сървъра се появява процес от съответния хост и юзер, но не става репликация (проверявам, като променям запис в някоя таблица на мастера и чакам да видя промяната на слейва) - не виждам промяната.
Дори да спра и да запусна сървъра на слейва, процесът на мастъра се появява (в списъка с процесите - с нов идентификатор).

Предполагам, че много "ангро" се опитвам да направя всичко с една заявка.
Та ако ме насочите - ще съм благодарен.
Тестовите сървъри: мастера е 4.0.14, а слейва - 4.1.14
Във файла с грешките пише разни работи:

060717 20:02:32 [Note] C:\Program Files\MySQL\MySQL Server 4.1\bin\mysqld-nt: Shutdown complete
060717 20:04:42 InnoDB: Started; log sequence number 0 3454590
060717 20:04:42 [Note] Slave SQL thread initialized, starting replication in log '1.004' at position 79, relay log '.\NOTEBOOK0-relay-bin.000005' position: 4
060717 20:04:42 [Note] Slave I/O thread: connected to master 'ReplNB@10.16.1.11:3306', replication started in log '1.004' at position 79
C:\Program Files\MySQL\MySQL Server 4.1\bin\mysqld-nt: ready for connections.
Version: '4.1.14-nt' socket: '' port: 3306 Official MySQL binary
060717 20:07:47 [ERROR] Error reading packet from server: Lost connection to MySQL server during query (server_errno=2013)
060717 20:07:47 [ERROR] Slave I/O thread killed while reading event
060717 20:07:47 [ERROR] Slave I/O thread exiting, read up to log '1.004', position 204
060717 20:07:47 [ERROR] Error reading relay log event: slave SQL thread was killed
които (най-вероятно) се дължат на повторното стартиране на репликацията.

Съдържаниет е скрито
Влезте за да го видите

"1. Това репликацията, непрекъснат процес ли е?"

Не въпреки, че не съм сигурен, че точно това те интересува.
Репликацията е асинхронна. Slave сървъра взим азаявките от Master-а когато успее и ги изпълнява когато и колкото бързо може.

"..но не става репликация.."

Какво казва SHOW SLAVE STATUS?


"мастера е 4.0.14, а слейва - 4.1.14"

Лошо Седларов, много лошо.
И 4.0.14 и 4.1.14 са много стари версии и се съмнявам, че репликацията между тях въобще има шанс да работи.

На теория репликацията от 4.0 към 4.1 би трябвало да работи обаче .... както се казва в любимиями цитат:
На теория, теорията и практиката са едно и също. На практика обаче се различават.

Съдържаниет е скрито
Влезте за да го видите

Благодаря ти, въпреки кофти "дир-а" - винаги може да се разчита на теб!

В общи линии ми се изясни, а и снощи тръгна репликацията.
Ти винаги си бил предубеден към версиите по-стари от 2 дни :)
Шегувам се.

Впрочем, репликацията явно е процес, който след като се стартира, продължава докато бъде спрян изрично с команда (от потребителя към слейв сървъра). Това не ми беше ясно.

Съдържаниет е скрито
Влезте за да го видите

Виждам,че съм писал регистрация,вместо репликация.
Интересно, сигурно съм мислил за кофти регистрацията в дир-а.

Съдържаниет е скрито
Влезте за да го видите

" продължава докато бъде спрян изрично с команда "

или поради грешка както вече си забелязал

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Има ли (за приложенията) достъпен статус (на репликацията) на слейв сървъра?
Т.е. приложение, конектнато към слейв сървъра, може ли да познае в какво състояние е репликацията?
Прегледах SQL свързан с репликации, но останах с впечетление, че всичко се отнася за мастър сървъра.

ПП
В ProcessList се вижда User с конаманда Bin Log Dump - може би това е един начин?

Съдържаниет е скрито
Влезте за да го видите

Редактирано от NikB на 18.07.06 17:21.

SHOW SLAVE STATUS\G не върши ли работа. Поне при мен на версия 4.1.20 показва доста неща - на колко секунди е slave-а от master-а, дали slave-a въобще работи и последната грешка.
Ако си поиграеш малко можеш да пуснеш mysqlbinlog с текущата позиция на slave-a и да видиш и коя е последната изпълнена заявка.

SHOW SLAVE STATUS\G - върши работа, само през SQL не мога да го пусна с опцията, но и не виждам смисъл.

Благодаря!

Съдържаниет е скрито
Влезте за да го видите

А ти щом се ровиш в репликациите, имаш ли желание да споделиш още?

Какво прави приложението ти, когато по някаква причина прекъсне репликацията?
Приложението прави ли опити да възстанови репликацията или само се оплаква на администратора?

ПП
Навярно имаш в предвид версия 4.0.20, но може и аз да бъркам :)

Съдържаниет е скрито
Влезте за да го видите

Редактирано от NikB на 19.07.06 00:52.

Зависи защо е спряла репликацията. Обикновено ако е някои проблем по мрежата slave-a си се закача сам. Но ако гръмне мастер-а и се получи загуба на синхронизация тогава имам един скрипт който ми праща смси и ходя да го оправям на ръка. Поне засега още предпочитам аз да видя грешката която е върнал slave-a преди да спре, а и когато има грешка не може просто да му пуснеш START SLAVE; щото пак ще гръмне.

Иначе аз за да разбера че ми е паднала репликата използвам точно
SHOW SLAVE STATUS като на по старите версии които нямат seconds_behind_master, проверявах дали са Yes Slave_IO_Running и Slave_SQL_Running и винаги гледам последната грешка. Виж си правата да не би приложението да няма право да изпълнява такива заявки. Иначе с \G сигурно няма да работи :)


MySQL ми е 4.1.20 - това е последния stable преди версия 5 и нагоре (http://dev.mysql.com/downloads/mysql/4.1.html)