> Не «мы», а заказчик, это важное отличие. Я же не зря написал «идентичный сервер в боевом контуре». И, соответственно, в случае тотальной невоспроизводимости, выяснения идут на этой реплике на территории заказчика под его контролем.
> Каким образом? Вот у вас есть сервер в продуктиве, на нем ошибка есть. А на любом другом сервере — нет.
Взять эти данные из бэкапа и проверить.
> Как понять, что ошибка в данных, и в каких именно данных, а не в сервере/окружении/фазе луны?
Вообще на тестовой машине желательно иметь такое же окружение как и на рабочей. Не всегда это возможно, правда. Но хотя бы опции (кроме больших буферов) и версию MySQL сервера можно такие же иметь.
> На том уровне выяснения проблем, когда нас волнует статическое распределение записей в БД, «некоторая надежда» — это уже слишком мало. В таких ситуациях обычно просто имеют идентичный сервер в боевом контуре для выяснения проблем.
Если вы можете позволить себе иметь идентичный сервер и самим тестировать — прекрасно. К сожалению, не все могут сами тестировать плюс в некоторых компаниях о сокрытии данных заботятся очень сильно. Я в своей практике встречалась вот именно с такими случаями. Клиент приносит запрос, который либо медленно выполняется, либо неверно. Я пробую повторить со сгенерированным набором данных: безуспешно, прошу дамп. Дамп мне этот дать не могут, потому что в нём секретные данные. Приходится объяснять и как обфускацию делать, и как частичный бэкап без секретных полей.
Правда=) Только есть один нюанс: не все данные нужно анонимизировать при выводе и не всегда данные, которые анонимизируются, — это именно те данные, которые приводят к нежелательным результатам. Потом смотря как анонимизировать. Например, если есть поле varchar, в котором хранятся, например, имена, можно менять их на другие строки с одинаковым числом букв, чтобы все Светы сконверитровались в одинаковую абракадабру, например Ssfec, все Тани в Ledw и т.д. При желании подобную обфускацию, вероятно, можно сломать, но вероятность того, что разработчик шпион всё же реже, чем вероятность того, что он же — раздолбай.
у сгенерированных данных есть один минус. Они слишком структурированы. Это может давать неверные результаты при тестировании. Особенно если речь о производительности.
Про кодировку же можно в общем ответить: как её установить на клиенте, как на сервере и, самое главное, зачем и почему её нужно там устанавливать. Другие вопросы тоже, на мой взгляд, простые. Даже для меня, хотя веб-разработка была в моей жизни достаточно давно.
Не правы. Вы можете не сдать экзамен и прослушав соответствующий курс. Я не зря написала выше, что курс и экзамен напрямую несвязаны. Сравните хотя бы «Exam Topics» и «Course objectives».
Лучше следите вот за этим блогом: mysqlblog.fivefarmers.com/ и Planet MySQL. Тодд пишет статьи, имея в виду именно экзамен, а курс сам по себе.
Oracle RAC — видимо, дорого и сложно, тяжеловесно, да и как его раскидывать по разным материкам?
MySQL cluster — быстрый мастер-мастер, но много подводных камней и ограничений, типа хранения данных только в памяти, но для некоторых кейсов все же неплохо работает
MySQL Cluster уже давно может хранить данные на диске. А вот по разным материкам и даже датацентрам раскидать его даже не то что сложновато: работать-то он будет, но небезопасно и медленно. (Смотрим «Network Hardware» здесь)
</зануда mode off>
Соглашусь. Более того, правило «В таком случае у вас получится «то, что хотел сказать», а не «то, как получилось сформулировать».» не всегда работает, особенно если переводчик не владеет нужной терминологией. Причём по поводу технического перевода я бы тоже не обольщалась: технологии развиваются стремительно и если речь идёт о незнакомой переводчику, он может странные термины употребить.
Я на своём месте близко к сердцу такое не принимаю. Тем не менее я считаю, что пособеседовать человека, чтобы впоследствии пропасть — это неправильно.
Несколько недель — это не отговорка. То есть, с одной стороны, кандидат, скорее всего работу уже нашёл, но с другой — приятно же, что человека не за пустое место принимают.
Это хорошо, когда такое возможно.
Взять эти данные из бэкапа и проверить.
> Как понять, что ошибка в данных, и в каких именно данных, а не в сервере/окружении/фазе луны?
Вообще на тестовой машине желательно иметь такое же окружение как и на рабочей. Не всегда это возможно, правда. Но хотя бы опции (кроме больших буферов) и версию MySQL сервера можно такие же иметь.
> На том уровне выяснения проблем, когда нас волнует статическое распределение записей в БД, «некоторая надежда» — это уже слишком мало. В таких ситуациях обычно просто имеют идентичный сервер в боевом контуре для выяснения проблем.
Если вы можете позволить себе иметь идентичный сервер и самим тестировать — прекрасно. К сожалению, не все могут сами тестировать плюс в некоторых компаниях о сокрытии данных заботятся очень сильно. Я в своей практике встречалась вот именно с такими случаями. Клиент приносит запрос, который либо медленно выполняется, либо неверно. Я пробую повторить со сгенерированным набором данных: безуспешно, прошу дамп. Дамп мне этот дать не могут, потому что в нём секретные данные. Приходится объяснять и как обфускацию делать, и как частичный бэкап без секретных полей.
Ну проверить-то можно перед тем как к секретным данным лезть?
> Распределение/статистика все равно поломаются.
Есть некоторая надежда, что похоже поломается.
А где URL?
Лучше следите вот за этим блогом: mysqlblog.fivefarmers.com/ и Planet MySQL. Тодд пишет статьи, имея в виду именно экзамен, а курс сам по себе.
Это чаще всего так, но не всегда. Особенно в последних версиях. Поэтому стоит добавить ещё один пункт: тестируйте!
MySQL Cluster уже давно может хранить данные на диске. А вот по разным материкам и даже датацентрам раскидать его даже не то что сложновато: работать-то он будет, но небезопасно и медленно. (Смотрим «Network Hardware» здесь)
</зануда mode off>
Несколько недель — это не отговорка. То есть, с одной стороны, кандидат, скорее всего работу уже нашёл, но с другой — приятно же, что человека не за пустое место принимают.